| name | refine |
| description | Rewrite an existing spec so it matches what the codebase does now: drop shipped items, update partially-done ones, fix stale paths and names, remove obsolete scope. Takes optional feedback after the path to steer the rewrite. Use when a spec no longer describes reality; use create when there is no spec yet. |
Refine Spec
Update a spec file so it accurately reflects the current state of the project.
Remove work that is already done, update partially-done items, and revise
descriptions to match what actually exists in the codebase.
Step 0: Parse arguments
$ARGUMENTS has the form: <spec-file.md> [feedback...]
- The first token is the spec file path (e.g.,
specs/windows-support.md).
- Everything after the first token is feedback — free-form instructions from
the user that guide the refinement. Feedback may request specific changes such
as: removing certain sections, rewriting scope, changing priorities, splitting
or merging items, adding new items, or adjusting tone/structure.
If feedback is present, apply it in addition to the standard codebase audit
below. Feedback takes precedence over the default rules when they conflict
(e.g., if feedback says "keep the done items as a checklist", do that instead
of removing them per rule 3a).
Step 1: Read the spec
Read the spec file identified in Step 0. Parse YAML frontmatter to extract
title, status, depends_on, affects, effort, created,
updated, author, dispatched_task_id.
Note the current lifecycle state — this guides the refinement:
vague → focus on fleshing out design, adding detail
