wallfacer

Break down a spec into child specs — either design specs (non-leaf, need further iteration) or implementation tasks (leaf, ready to dispatch). Automatically determines breakdown mode from spec lifecycle state, or accepts an explicit override. Use when a spec needs decomposition.

Create a new design spec in specs/. Gathers context, explores the codebase, writes the spec with proper frontmatter, and updates specs/README.md. Use when the user says "create a spec", "write a spec", "new spec", or "/spec".

Compare a completed task's implementation against its source spec. Produces a structured divergence report — which acceptance criteria were satisfied, which diverged, and what was implemented but unspecified. Appends an Outcome section to the spec. Use after a dispatched task completes.

Dispatch a validated spec to the task board. Validates prerequisites, resolves dependency wiring, creates the task, and updates the spec's dispatched_task_id atomically. Also supports undispatching (cancel + clear link). Use when a spec is ready for execution.

Drive a spec through the spec-coordination lifecycle toward a target state, advancing the legal next transition(s) and reporting the new state each turn. Designed to run under a `/goal` so it continues autonomously across turns until the spec reaches the target (or a gate needs you). Pauses for confirmation at irreversible / outward-facing gates (dispatch to the board, archive, stale fan-out). Use when the user says "drive this spec to done", "take this spec through the lifecycle", or sets a goal to complete a spec.

Analyze what existing code and specs a proposed change will affect. Use before implementing a spec to understand blast radius, identify risks, and find specs that need updating.

Implement a design spec from specs/ — reads the spec, plans the work, implements each item with tests and docs, commits, then finalizes (full implementation delegates to wrap-up; partial implementation records running notes). Use when the user says "implement spec", "build spec", or references a spec file to implement.

Refine a spec markdown file by removing already-completed items and updating remaining items to reflect the current project state. Optionally accepts feedback after the file path to guide specific changes (e.g., rewrite scope, change priorities, add/remove items). Use when a spec has drifted from reality and needs to be brought up to date.

Validate a task breakdown for correctness — check dependency ordering, task sizing, gap coverage, and boundary conflicts. Use after wf-spec-breakdown to catch issues before implementation.

Review an implementation against its spec or task. Check that acceptance criteria are met, no unintended changes were made, and tests cover the requirements. Use after implement-spec or after a task completes.

Report current status across all specs — what's done, in progress, blocked, and what's next. Reads reality (spec files, task files, git history) instead of relying on manually maintained status tables.

Validate all specs against the document model rules — check required frontmatter fields, valid status/effort values, track location (path-derived), DAG acyclicity, dispatch consistency, orphan detection, and status consistency. Use to catch structural issues across the spec tree.

Finalize a completed spec — works for both a dispatched spec (verify all child tasks are done, synthesize from task notes) and a directly-implemented spec (no task files; reconstruct from git history of the affects files). Updates the spec with an Outcome section, flips status to complete, updates specs/README.md, and commits. Use when a spec's work is done and it needs its completion write-up.