Small, composable skills for aligning intent, implementing from a stable spec, and proving the result. Each skill has one responsibility; chain only the ones the task needs.
Upstream of any spec — for when the work is still an idea.
| Skill | Responsibility |
|---|---|
/talk-about-an-idea |
Develop a fuzzy product idea in conversation until it is crisp — or honestly dead. |
/research |
Chase a question to wherever the answer is observable first-hand, with cited evidence. |
/debate |
Two agents build the strongest evidenced case for and against an idea; rule on the whole. |
They chain naturally: /talk-about-an-idea surfaces open questions, /research settles them, /debate gives a big idea an adversarial go/no-go, and a surviving idea flows into /grill-me → /to-spec.
| Skill | Responsibility |
|---|---|
/grill-me |
Surface unresolved human decisions in rounds, one frontier of the design tree at a time. |
/to-spec |
Turn the agreed context into a task contract with Acceptance Criteria and a Verification Plan. |
/spec-review |
Challenge a spec before implementation for necessity, completeness, and feasibility. |
/spec-verify |
Verify the final implementation against every Acceptance Criterion using concrete evidence. |
/code-review |
Find defects, quality cost, and design cost in the changed code; fix applies the safe ones, simplify = quality-only fix. |
/arch-review |
Survey the codebase for the few architecture changes worth making — state, structure, seams. |
Implementation is intentionally not a skill:
Implement @spec-file and complete its Verification Plan.
Clear, small feature:
/to-spec → commit spec → implement → /spec-verify
Feature needing alignment:
/grill-me → /to-spec → commit spec → implement → /spec-verify
Full feature:
/grill-me → /to-spec → /spec-review
→ /grill-me → /to-spec @spec-file → commit spec
→ implement → /code-review fix → /spec-verify
Commit the spec before implementing: that commit is the diff baseline /spec-verify checks against. After implementing, run /code-review (for substantial or high-risk changes; add fix to have it apply the safe quality and design fixes) and /spec-verify. With fix, /code-review changes code, so it runs first; without it, both are read-only and run in parallel when available capacity permits. After fixes, re-review the changed behavior and re-verify affected acceptance criteria. Reuse evidence that still applies to the final implementation; repeat or broaden checks when new changes, failures, or unresolved concerns invalidate it. Finish when required checks pass and every acceptance criterion has current evidence, or report the specific blocker and unverified criteria.
When /spec-verify or /code-review finds something the spec missed, ask one question: does the failure fall into an edge category /to-spec already sweeps? If it does, nothing to record — the list held, the application slipped. If it does not, add the category to /to-spec's sweep, one line. Categories converge; cases never would.
Tiny changes do not need this pipeline: describe the change, implement it, run the smallest relevant check, and inspect the diff.
| Skill | Responsibility |
|---|---|
/conventional-commit |
Group and commit changes with focused conventional commits. |
/create-pr |
Push the current work through the repository's pull-request workflow. |
Inspired by Matt Pocock's skills. Thanks for open-sourcing the concise, composable approach that helped shape this workflow.