spec

Plugin spec from marketplace spec-workflow in kamioj/spec-workflow. Commands read from the repo's manifest — yesterday.

Skills (1)

• core

  Spec-driven development workflow overview. Load this skill ONLY when the user explicitly asks for the spec flow — says "spec this first / draft a proposal / design first / write a proposal", or invokes a /spec:x command. NEVER self-activate on task size or complexity: size is at most grounds for a o

Slash commands (18)

• /spec:apply

  Implement the code, advancing by proposal/tasks. A pre-command hook checks that proposal.md carries the APPROVED marker. Verification model: cheap self-run working checks per node while implementing; ONE independent spec-verifier pass at the end (never dispatch verification subagents mid-implementat

• /spec:archive

  Archives the current change to spec/archive/YYYY-MM-DD-<name>/. Only invoked when the user explicitly says "archive". Writes an archive-stage retrospect, mines the change for recurring lessons (fresh-context spec-reflector agent) and applies the ones the user selects to project skills / rules files,

• /spec:ask

  Interrogates preference-driven decision points. Derives questions from the candidate sets research minted into each [TBD] (options are citations, not inventions), asks via AskUserQuestion (multiSelect for pick-several), and moves answered items to ## Decided. Inside /spec:workflow it switches to aut

• /spec:chat

  Discussion mode. Everything said during this mode is treated as thinking material only — no documents are touched. Use for brainstorming directions, or to talk through concerns about a proposal before deciding how to change it.

• /spec:design

  Technical design elaboration. Trigger on demand — use when the architecture is complex, there are more than 3 interfaces, sequence/data-flow diagrams are needed, or a decision requires more than 300 words of deep argumentation. Produces design.md.

• /spec:fix

  Streaming light tier for bug fixes and small changes (user-explicit only, never model-initiated). Appends F-N entries to today's daily batch under spec/changes/fixes/<date>/ — locate & confirm before touching code, fix directly when confident or research candidates when not, self-check evidence per

• /spec:knowledge

  Tidies the project knowledge base on demand — the way an assistant tidies its own experience notes. Audits every fact (dead file / symbol anchors get a suspect mark, duplicates and contradictions listed), applies the reversible tidying automatically (merge duplicates, compress wording, newest eviden

• /spec:loop

  Goal-driven autonomous round loop. Give it a goal + acceptance checklist + round budget (touchpoint 1), then it researches, implements, self-checks, and retrospects round after round — driven by a Stop-event hook, not by prompt discipline — until the final acceptance audit (touchpoint 2, the loop's

• /spec:propose

  Write or fully rewrite proposal.md (## Why / ## What / ## How / ## Risk). A pre-command hook forces research.md's [TBD] list to be empty. On completion, emit the HARD GATE and wait for user approval

• /spec:research

  Researches the change — always maps the codebase status quo; dispatches a @researcher web-survey sub-agent ONLY when the decision space is external (new dependency / tech choice / unfamiliar domain), never for internal refactors or fix batches. Findings go into research.md (single file; Open[TBD]/De

• /spec:resume

  Switches the current change (writes the spec/changes/.current pointer) and, when the target is paused, deletes its .paused marker — then reports where the work left off so re-entry is instant. The switcher for parallel changes; no argument lists what there is to switch to.

• /spec:revise

  Edit a single proposal.md section (why / what / how / risk). A full rewrite goes through /spec:propose. After editing, the HARD GATE must run again

• /spec:ship

  Closes one fix batch — ONE independent audit over the batch's accumulated diff (F-N entries are the claim anchors; the shipping conversation audits directly when it wrote none of the entries, a subagent only when it did), writes the audit into fix.md, and archives that batch dir on pass; on fail the

• /spec:stash

  Parks a change deliberately — writes a .paused marker (date + reason) so it stops counting as active and status shows it as set aside, with every artifact (ledger, index, proposal) staying warm for /spec:resume. Optional bookkeeping, not a switching ritual — switching lives in /spec:resume <name>. R

• /spec:status

  Reports where the current SDD change stands, what artifacts exist, and which commands can be run next. Use when returning after an interruption and unsure where things left off.

• /spec:verify

  Verifies the current change by dispatching the independent spec-verifier agent (fresh context — the implementing conversation never audits itself) across four dimensions (Completeness / Correctness / Coherence incl. the charter sub-audit / Reuse & Conformance); --codex adds a heterogeneous Codex pee

• /spec:view

  Renders the current change's artifacts into self-contained HTML views for human reading — research, ask, design, proposal (gate), verify — in a standard tier (faithful render) or an advanced tier (stage-specific layout; the ask and proposal pages are interactive and produce a reply line to paste bac

• /spec:workflow

  Full SDD workflow, end to end, requirement fully delegated. Open decisions are digested internally (auto triage — no mid-flight questions); MUST stop at exactly two points — the HARD GATE and acceptance/archive. The user participates as an evaluator; evaluation rounds are unlimited. Also accepts the

Subagents (3)

• spec-dev

  Use when /spec:apply dispatches implementation work — cross-stack changes (TWO spec-dev instances in parallel, one scoped frontend one scoped backend, against the contract in design.md ## Interfaces), or a single-scope change whose main conversation is low on context budget. Builds frontend (Vue / R

• spec-reflector

  Use when /spec:archive runs its lesson-mining step. Fresh-context agent that mines one finished change — its verification ledger, gate evaluations, stuck self-checks, retrospect divergences, loop Lessons, git history, and (best-effort) the session transcripts — for recurring problem classes, and rou

• spec-verifier

  Use PROACTIVELY when /spec:verify runs. Independent verification agent with a deliberately fresh context — never the conversation that implemented the change. Audits the diff against proposal.md's verify: clauses, the change's index.md (R-N requirement quotes + A-N assets), design.md contracts, and

Hooks (5)

• UserPromptSubmit

  sh "$CLAUDE_PLUGIN_ROOT/hooks/check-tbd.sh"

• UserPromptSubmit

  sh "$CLAUDE_PLUGIN_ROOT/hooks/check-gate.sh"

• UserPromptSubmit

  sh "$CLAUDE_PLUGIN_ROOT/hooks/check-archive.sh"

• Stop

  sh "$CLAUDE_PLUGIN_ROOT/hooks/loop-driver.sh"

• Stop

  sh "$CLAUDE_PLUGIN_ROOT/hooks/check-verify-reminder.sh"

Similar plugins