spec-writerlisted

# Spec Writer Skill ## Intent Use this skill to turn a rough repo change, feature idea, cleanup effort, or migration into a numbered spec folder with practical planning documents. The goal is to create a working spec package that another engineer can pick up and execute without guessing what the work means. ## Use When - The user wants a new spec for a repo change, feature, refactor, migration, or workflow - A project needs structured `requirements.md`, `plan.md`, and `tasks.md` documents - The repo already uses numbered spec folders and new work should follow that pattern - The request is large enough that ad hoc notes would be too loose ## Do Not Use When - The change is tiny and does not need formal planning - The repo has no spec workflow and the user only wants direct implementation - The user wants a README, assessment, or changelog instead of an execution spec - The available context is too thin to produce honest requirements and next steps ## Workflow 1. Read the repo context first. 2. Confirm where specs live and how numbering works. 3. Pick the next available spec number unless the user provided one. 4. Create a short kebab case spec folder name tied to the actual work. 5. Write the core documents: - `requirements.md` - `plan.md` - `tasks.md` 6. Keep each file practical: - requirements explain the problem, scope, constraints, and success criteria - plan explains the implementation approach, touched areas, risks, and validation path - tasks