npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

stride-cc

v0.7.4

Published

Stride — an adaptive, durable feature workflow with separate implementation and review models across coding runtimes.

Readme

Stride

Stride is a mishmash of things that I enjoyed across my experience of using Get-Shit-Done (GSD) and general Spec-Driven Development, as well as some skills and talks that Matt Pocock has put out in the world. I wanted to take what I liked most across all of these and consolidate them into a more lightweight framework that gives coding agents enough structure to stay on track without turning every feature into a long-form ceremony.

It keeps the important parts of a feature outside the chat: what you are building, what “done” means, the decisions already made across the project, the current plan, and the evidence that the work actually works. Your agent moves through an approved plan with useful autonomy, while you keep control of the decisions that matter.

Humans define and authorize intent. An implementation specialist builds. An independent reviewer checks. Humans authorize shipping.

Attribution

Stride borrows from two sources, and the rest is original:

  • Matt Pocock's skills — four parts of stride are adapted from his skills:

    • stride-debugger + /stride-debug from /diagnose: reproduction-first investigation, root cause before any fix, structured diagnosis instead of speculative changes.
    • /stride-grill + /stride-grill-light from grilling: adversarial stress-testing of design decisions against the user. Mechanics differ (per-branch questions vs. his frontier rounds).
    • .stride/glossary.md (opportunistic glossary capture) from grill-with-docs's shared-language technique: capture terms the user defines mid-conversation as ubiquitous language.
    • /stride-spike from /prototype: throwaway code that answers a question — deliberately rough, no polish, user reacts to the real thing.

    The adaptations to stride's WORK.md context and agent plumbing are project-specific.

  • GSD — the inspiration for the core idea: durable feature state outside the chat, structured phases, and well-placed human gates.

Everything else — the workflow commands, pause/resume session model, verification design, and installer — is original to this project.

Why I built Stride

I used GSD and loved its structure and momentum, but over time its growing phases, artifacts, and gates felt heavier than the work they supported. A few gates are worth keeping — they stop an agent from racing past an unclear requirement or treating “the code is written” as “the feature is done” — but the ceremony around them wasn't.

Also, and potentially most crucially, I wanted to solve session continuity. Most harnesses can reopen an old conversation, but the model pays to reread or re-compact a long transcript. Stride instead allows you to write the current state of the work into a concise, durable feature document: /stride-pause captures it, /stride-resume restores from it. Because that state lives with the project rather than one model's conversation, you can pause a feature with one model and/or harness and resume it with another.

Quick start

1. Install

npx stride-cc

Choose your coding-agent runtime and whether to install globally or only in the current repository. Scriptable examples:

npx stride-cc --global --yes
npx stride-cc --runtime opencode --local --yes
npx stride-cc --runtime copilot --global --yes
npx stride-cc --runtime pi --local --yes

Re-run npx stride-cc to upgrade. Installation never overwrites your active .stride/WORK.md or repository configuration. To uninstall: npx stride-cc uninstall (add --purge to also remove repo-local Stride state).

2. Start a feature

Open your coding agent inside a Git worktree and run:

/stride-start "what you want to build"

Stride initializes the repository when needed, captures what “done” means, and guides the feature through the workflow.

How it works

Define intent and acceptance criteria
            ↓
Research and plan as needed
            ↓
Human approves the plan
            ↓
Build: complete-Plan handoff → one local-check sweep
            ↓
One global closure → independent whole-diff review
            ↓
Human decides whether to ship

Stride adapts rather than asking you to pick a preset: unresolved design choices can trigger a focused grill, UX or feasibility uncertainty can trigger a small evidence-seeking spike, and routine reversible work proceeds without ceremony. At the Plan checkpoint you can let Stride build the approved phase autonomously, work through it collaboratively, or revise the Plan.

Verification and safety

Writing code is not completion evidence. Each task maps to focused local checks which the implementer deduplicates and runs once; the full build/suite then runs once per closure pass before an independent reviewer sees the whole diff. One configured implementation model builds; a separately configured model reviews the diff in fresh, read-only context. Neither is silently swapped for another provider.

Stride never authorizes: commits, pushes, or merges; deployment or publishing; automatic shipping; silently changing accepted intent; or reverting rejected work. Hard process and network isolation still depends on the host coding-agent runtime.

Experimental advisor (Pi)

Pi additionally ships an optional advisor: a turn-end reviewer that runs during Build/Iterate. Every N work-turns (configurable) it critiques the executor's last turn against the feature's acceptance criteria, decisions, and the uncommitted diffstat, and its verdict arrives as a steering message — so drift is caught while it's small, not at the Review checkpoint.

Two guardrails keep critiques from looping:

  • Dismissals — evidence-backed rebuttals recorded in .stride/advisor-dismissals.md are fed back to the advisor, which must not re-raise a dismissed finding without new diff evidence.
  • Dedup — an identical critique against an unchanged diff is fingerprinted and silently suppressed. Silence after an unchanged diff means dedup fired, not that the advisor died.

Configure its model and effort via /stride-config (stored under runtimes.pi.advisor); inherit turns it off, and touch .stride/advisor-mute silences it for the session. Medium effort is recommended for most models — low-effort advisory review produced confident but wrong flags in field testing. This is stride's own advisor, experimental and Pi-only for now.

Upgrading

  • No action needed to upgrade — just re-run npx stride-cc.
  • Coming from a version older than 0.7.0? Codebase mapping (/stride-codebase-map and .stride/CODEBASE.yml) has been removed. It produced stale, bloated structural summaries that agents inconsistently trusted, and modern runtimes expose better alternatives anyway (codebase-intelligence tools, or live Grep/Glob). Your existing .stride/CODEBASE.yml is left in place and can be deleted; it is no longer read or refreshed. All other .stride/ state is unaffected.

Crash recovery

If a session dies mid-turn, a lifecycle hook (never the model) writes your last prompt to an inflight marker under ~/.stride/state/<key>-<branch>.inflight. The next session — or /stride-resume — detects the marker and surfaces a banner naming the interrupted prompt and any unrecorded edits, so you can pick up cleanly. A successful turn clears the marker; crashes, kills, and terminal closes preserve it. Set STRIDE_INFLIGHT=0 to opt out entirely. Prompt text (truncated to ~500 chars) is stored only under ~/.stride/state/, never in the repo.

Persistent state

The active feature lives in one gitignored file, .stride/WORK.md: intent, acceptance criteria, plan, decisions, current task, verification evidence, open questions, and touched files. Repository configuration lives in .stride/config.yml; completed, abandoned, and paused work is archived under ~/.stride/archive/.

On ship, the git: block in config.yml controls branch closeout (squash, rebase + fast-forward into the base branch, push-only for PR workflows), and the worktree: block controls where new worktrees are created (sibling by default, or nested). Never commits or pushes without your command; a closeout failure never unships the feature.

Stride allows one active feature per worktree. For concurrent features, use separate worktrees and /stride-switch. Archives are local unless you sync them yourself.

Project-level memory accretes across features in three gitignored files: .stride/decisions.md (architectural decisions you promote at Ship — binding on future features, so plans can't accidentally re-litigate them), .stride/lessons.md (tagged gotchas from prior features), and .stride/glossary.md (the project's shared vocabulary, as captured mid-grill).

Commands

| Command | Purpose | |---|---| | /stride-start "<idea>" | Start a feature and enter the adaptive Define → Ship workflow (runs one-time repo setup when needed). | | /stride-status | Show the active feature, current phase, completed work, and next action. | | /stride-config | View or change user-local Stride preferences, starting with implementer/reviewer models. | | /stride-pause | Refresh persistent state and create a local archive for later continuation. | | /stride-resume | Choose from concurrent strides when needed, then restore the selected feature. | | /stride-switch | List features across worktrees and hand off safely to the selected worktree. | | /stride-finish | Ship, abandon, or pause the active feature. Shipping closes Stride state; it does not deploy or publish. |

Supported runtimes

| Runtime | Integration | |---|---| | Claude Code | Native commands, subagents, and lifecycle hooks. | | OpenCode | Native command/agent equivalents; state loading and scope guarding use behavioural fallbacks. | | GitHub Copilot CLI | Commands as skills, custom agents, and native hooks; checkpoint and scope-guard behaviour still pending live validation. | | Pi | Prompt templates with a TypeScript bridge for hooks and in-TUI worktree switching. With a community subagent extension, implementer/reviewer roles dispatch as isolated subagents with configured models. |

Implementer and reviewer model preferences are user-local and runtime-specific in ~/.stride/models.json (prompted on first /stride-start, changeable via /stride-config). Neither role's model is ever committed into a repository.

See Experimental advisor (Pi) for the optional turn-end drift reviewer and its guardrails (dismissals, dedup, effort guidance).

Requirements

  • Node.js 18 or newer
  • Git and a Git worktree
  • macOS or Linux (Windows via WSL; native Windows paths not yet supported)
  • One of the supported coding-agent runtimes above

Contributing

Clone the repository and use install.sh for live development installs:

git clone https://github.com/GKemi/stride.git
cd stride
./install.sh             # Claude Code (or --opencode / --copilot / --pi / --all)

Run the full test suite with npm test. See docs/DESIGN.md for the workflow contract, state model, verification design, safety invariants, and deliberate non-goals.

License

MIT — see LICENSE.