From ctx
Scaffolds feature specs from project template by guiding through sections like Problem, Approach, Happy Path, Edge Cases. Use for planning non-trivial features or missing design docs.
npx claudepluginhub activememory/ctx --plugin ctxThis skill uses the workspace's default tool permissions.
Scaffold a new spec from `specs/tpl/spec-template.md` and walk through
Creates or updates SPEC.md documents from requirements, notes, or interview output, structuring into sections for goals, design, edge cases, security, testing, and success criteria. Use for feature specs.
Generates structured feature specifications with demoable units, functional requirements, and proof artifacts. Invoke when starting new features to define scope before coding.
Conducts multi-round interviews to refine rough SPEC.md into complete, implementation-ready specifications with tasks. Use for new features, requirements refinement, or ideas to actionable specs.
Share bugs, ideas, or general feedback.
Scaffold a new spec from specs/tpl/spec-template.md and walk through
each section with the user to produce a complete design document.
specs/X.md" and the file does not exist/ctx-brainstorm has produced a validated design that needs
a written artifact/ctx-brainstorm first)/ctx-spec
/ctx-spec (session checkpointing)
/ctx-spec (rss feed generation)
If not provided as an argument, ask:
"What feature should this spec cover?"
Derive the filename: lowercase, hyphens, no spaces.
Target path: specs/{feature-name}.md
If the file already exists, warn and offer to review it instead.
Read specs/tpl/spec-template.md to get the current structure.
Work through each section one at a time. For each section:
Section order and prompts:
| Section | Prompt |
|---|---|
| Problem | "What user-visible problem does this solve? Why now?" |
| Approach | "High-level: how does this work? Where does it fit?" |
| Happy Path | "Walk me through what happens when everything goes right." |
| Edge Cases | "What could go wrong? Think: empty input, partial failure, duplicates, concurrency, missing deps." |
| Validation Rules | "What input constraints are enforced? Where?" |
| Error Handling | "For each error condition: what message does the user see? How do they recover?" |
| Interface | "CLI command? Skill? Both? What flags?" |
| Implementation | "Which files change? Key functions? Existing helpers to reuse?" |
| Configuration | "Any .ctxrc keys, env vars, or settings?" |
| Testing | "Unit, integration, edge case tests?" |
| Non-Goals | "What does this intentionally NOT do?" |
Spend extra time on Edge Cases and Error Handling. These are where specs earn their value. Push for at least 3 edge cases and their expected behaviors. Do not accept "none" without challenge.
After all sections, ask:
"Anything unresolved? If not, I'll remove the Open Questions section."
Write the completed spec to specs/{feature-name}.md.
"Want me to break this into tasks in TASKS.md?"
Not every spec needs every section. If a section clearly does not apply (e.g., no CLI for an internal refactor), the user can say "skip" and the section is omitted entirely: not left with placeholder text.
Before writing the file, verify:
... text remainsspecs/{feature-name}.md