capstone

architecture

Use when designing a new/greenfield project's architecture - exhaustive persisted one-question-at-a-time interview, then the full prescriptive reference.

Data & Documents Listed

changelog

Use when asked how the architecture changed since a commit - appends an architecture-level entry to docs/capstone/changelog.md.

Data & Documents Listed

check-docs

Use when asking if the architecture docs (DESIGN.md/docs/capstone) are still current - read-only staleness and pointer-drift report.

Internal to the capstone suite - carries the shared rules (references/) and scripts every capstone subcommand reads; it exists so npx-skills installs ship them alongside the command skills. Not meant to be invoked directly; when invoked anyway, run references/../scripts/help.sh and output its stdout verbatim.

Data & Documents Listed

docs

Use when asked to generate, update, or refresh a codebase's architecture reference docs (DESIGN.md plus docs/capstone/ topic files), map the architecture, or document the data models, typing conventions, and module boundaries so AI sessions read docs instead of re-exploring the repo. Descriptive only; refreshes just the topics whose covered paths changed since their commit stamps.

feature

Use when the user wants one feature taken from idea to working code - "add a feature", "build X end to end", "take X from idea to shipped" - runs the feature chain groom -> plan -> implement consecutively, detecting the feature's stage and resuming at the first incomplete one. For the whole-product greenfield pipeline use start; to execute an already-approved plan use implement.

Code & Development Listed

guides

Use when asked for how-to runbooks (run locally, deploy, project workflows) written to docs/capstone/guides/.

help

Use when asked what the capstone plugin can do - prints the usage block.

implement

Use when an approved feature plan is ready to become code - executes plan.md task by task with verification, in subagents or inline as you pick, reviews the diff recursively until no new findings survive, then refreshes the affected reference chapters.

review

Use when asked for an opinionated review of the codebase - architecture/backend findings, UI findings against the project's own design docs, or both - severity-ranked with evidence, written to docs/capstone/review.md. Bare "review" does both sides; "review backend" or "review frontend" does one. Opt-in judgment; never edits code.

standards

Use when capturing how code must be written in this project - typing strictness, library-vs-build posture, paradigm, error handling, testing style, git and commit discipline, and what an AI assistant must never do here - via an interview, producing a normative standards doc that outranks generic best practice. Binding rules you decided, not a description of what the code currently does; the observed conventions live in the reference's own conventions chapter.

start

Use when the user says just "capstone" with nothing else, or asks to start or continue the capstone pipeline - runs the greenfield chain one stage at a time (mockup -> logic -> uiux -> architecture -> standards -> stack -> build), detecting completed stages and resuming at the first incomplete one.