writing-speclisted

Use when a design discussion is ready to be written into a spec document, before any implementation planning. Synthesizes the conversation into a spec, runs a fresh-eyes self-review subagent, and gates on user approval before handing off to writing-plans.
pgoell/pgoell-claude-tools · ★ 0 · Testing & QA · score 70

Install: claude install-skill pgoell/pgoell-claude-tools

# Writing a Design Spec Take a design discussion and synthesize it into a written spec document. Run a fresh-eyes self-review, fix issues inline, gate on user approval, then recommend `workbench:writing-plans` as the next step. ## When to Invoke After a design discussion (typically a `workbench:brainstorming` session) where the user has approved the design verbally or in scratch notes. The discussion must be far enough along that the spec is a synthesis, not another round of questions. If the user is still asking questions or exploring approaches, return them to `workbench:brainstorming` first. ## Steps You MUST create a task for each of these items and complete them in order: 1. **Resolve the spec path** based on profile or session context. 2. **Draft the spec document** at the resolved path. 3. **Dispatch the self-review subagent** with the prompt template in `spec-document-reviewer-prompt.md`. 4. **Apply the reviewer's findings inline.** No re-review. 5. **Present to the user for approval.** 6. **Commit the spec** if the path is committable. 7. **Recommend `workbench:writing-plans`** as the next skill. ## Path Resolution `<paths.specs>` resolves in order: 1. `.workbench/autopilot.md` `Specs:` heading. 2. Project `CLAUDE.md` or `AGENTS.md` spec-path convention. 3. `.workbench/specs/` (default). If the resolved value is `don't commit`, write the spec to `/tmp/<project-name>-autopilot/YYYY-MM-DD-<topic>-design.md` and skip the commit step. Otherwise write to `<paths