A discipline layer for Claude Code. Hooks at every tool boundary, a workflow that runs from intake to commit, and a small constitution the agent cannot bypass.
Review the auto-extracted candidates in .claude/memory/pending.md and commit keepers to the canonical memory files (landmarks.md, libraries.md, decisions.md, landmines.md, conventions.md, pending-questions.md, backlog.md). Invoke at session start when the SessionStart hook reports pending candidates, or any time…
Run an org-team workflow — a flat pod of up to four peer Claude Code sessions claims lane-tagged slices of an approved spec over the baseline MCP channel and implements them concurrently, each in its own git worktree. Each peer DECIDES its own in-lane implementation choices in its own main context (Article X); only…
Power batch-sprint helper — hosts the two behaviours that distinguish the power workflow track from spec-entry. (1) Per-ticket iteration: security runs once PER TICKET over workflow.json.tickets[] while the mechanical phases run once for the batch. (2) Commit split: at the commit phase, group the batch's working tree…
Draft or revise English prose for any brief — documentation body, intake problem statements, spec context, RCA summaries, marketing copy, README sections, PR descriptions. Mandatorily invokes Skill(humanizer) as the final pass on every draft. Conditionally invokes copywriting for persuasive register, documentation for…
Draft a Root Cause Analysis for an incident, outage, or repeated test failure. Unlike intake/spec/brd, RCA is not a workflow phase — it's a standalone postmortem artifact that often precedes a bugfix intake. Output lives at docs/rca/ .md.
Bring documentation prose down to a high-school reading level without losing precision. Runs after the content is written and before humanizer. Targets grade 9 on four measures — sentence length, vocabulary, clause load and jargon density — and carries the rewriting moves that actually shift them.
Workflow Phase 3 — Research and Solution Exploration. Surfaces 2–4 candidate solution approaches with concrete tradeoffs, grounded in current library docs (fetched through the provider named in .claude/docs-provider.json) — never in training-data recall. Output lives at docs/research/ .md. Candidate ranking and the…
Cycle-end retrospective converting recurring judgment failures into durable enforcement. Reviews the cycle's friction — repeated user corrections, guard trips, RCA themes, integrate failures — and turns each recurring one into a landmines.md entry, then proposes graduation candidates up the enforcement funnel…
Derive an execution roadmap from a project's vision/spec docs by first principles, then diff that fresh derivation against the existing roadmap to prove the task ORDER is correct. Use this whenever the user wants to review, validate, re-derive, or sanity-check an execution roadmap or delivery plan; asks whether the…
Phase 10.6 — sync the project's execution roadmap (project.json → roadmap.path, default docs/roadmap-execution-plan.md) to the just-landed work. Flips the tasks named in workflow.json → roadmaptasks[] from ⬜ to ✅ and promotes their epic headings ⬜→🟡→✅, preserving the standup parser format contract. On the epic track…
Read-only view of the execution roadmap. Lists every epic with its per-status tallies, nests the still-open rows beneath their epic, collapses wholly-finished epics into one rollup line, and closes by naming the next planned task in file order. Four verbs — list (the reader's view), tasks and epics (filterable row and…
Write executable failing tests from a recipe handed to you by the main context. Used by /tdd Step 2 and ad-hoc when a phase needs tests-first to drive implementation. Decisions about which scenarios to cover, which categories matter, and which fixtures to use are made by the caller — this skill executes that recipe…
Workflow Phase 2 — Codebase Scouting and Constraint Discovery. Maps the relevant slice of the codebase for a given task. Produces a scout report at docs/scout/ .md naming the files, modules, and patterns the proposed work touches or constrains. Report decisions execute in main context with full conversation…
Workflow Phase 7 — Mechanical cleanup pass over the branch diff, followed by a code-structure review pass and a verify re-stamp. Shadows the global simplify skill at project scope; the cleanup pass is performed inline rather than via Skill self-call.
Cross-consistency review of a drafted spec's diagrams. Verifies that C4 components appear in the dependency graph, class-diagram changes have matching DDL, every AC resolves to a concrete sequence, and the dependency graph is acyclic. Read-only. Run after /spec-lint passes and before implementation.
Preflight a spec draft without saving. Runs the same checks as the write-boundary hooks — PlantUML syntax, required diagram presence, AC-to-sequence traceability, Design calls quality floor, and System delta row resolution — and prints a compact pass/fail table. Use while iterating so the hooks don't bite on save.
Extract every PlantUML block from docs/specs/ .md and render each to SVG under docs/specs/rendered/ /, with an index.md listing them in order. Run this before /approve-direction so the reviewer sees pictures instead of raw PlantUML.
Oracle-bound spec-review check that every structured Rollout prerequisite binds to an enforcement-type acceptance criterion. A prerequisite whose enforced-by is missing, dangling, or points at a non-enforcement AC is a BLOCKER (hard-blocks implementation entry via the checker fan-out verdict); a prerequisite left in…
Dev-only check that a drafted spec for THIS baseline repo won't ship dev-tree references to consumer installs. Catches three failure modes — shipped SKILL.md prose that references paths under src/, tests/, scripts/, obj/ as runtime invocations (in OR inline backticks, plus shipped .mjs/.js/.sh/.py helper-file…
Fixture SKILL.md that intentionally contains a dev-tree runtime reference inside a bash fence. Used by tests/shipped-skill-md-shippability.test.mjs to verify scan-shipped-skills.mjs emits a BLOCKER DEVTREERUNTIMEREF finding.
Bootstrap the central system spec at docs/system/ for a repository that has never had one. Scans the governed surface, proposes a concept map clustered by directory, and materializes elements + shards ONLY after a human confirms that map. Use when adopting the baseline on an existing project, or when the corpus needs…
Traceability review — every spec AC must trace to a resolvable upstream AC in the intake (and BRD if present), and no upstream AC is silently dropped. Read-only. Run alongside spec-diagram-review before implementation.
Draft a Workflow Phase 4 technical spec from an intake (and optionally a BRD + scout + research memo). The spec defines how the system will change: design (C4 + UML + dependency graph in PlantUML), data, APIs, tests, rollout, rollback. Output lives at docs/specs/ .md. Never self-approves — approval happens via…
At most 3 mods per repository are shown here, and a mod shipped inside a plugin is left to that plugin's page — the rest are on their repository pages: