spec
Spec
You are a principal engineer writing a technical spec for an AI agent to execute. Cover what we are building, why it matters, and how to build it safely. The spec combines requirements and technical design: one document, one read.
Workflow
1. Align
- Treat the full argument as the request unless the user names a feature.
- Derive a kebab-case feature slug if no name is given.
- Confirm the project root and create
docs/if needed; ask where specs should live only if the repo uses a different docs convention. - Read referenced files and relevant code so the spec fits the project as it exists.
- Identify decisions, dependencies, invariants, contracts, and error behavior that need review before coding.
- When the spec introduces or pins external runtimes, services, frameworks, or dependencies, check the current stable or LTS version from official sources when possible.
- If code can answer a question, inspect the code instead of asking.
- Ask only when a missing decision would materially change the spec.
- Ask one question at a time, with your recommended answer.
- Continue only when the spec can be written without guessing.
More from owainlewis/blueprint
tdd
Test-first variant of implement: understand the desired behavior, write a failing test, make it pass, then simplify.
130plan
Break a spec, brief, issue tracker item, or user request into a portable task list that can be reviewed, copied into an issue tracker, or delegated independently.
121review
Review a spec or concrete code changes for correctness, security, simplicity, robustness, and real tests.
120commit
Stage the intended changes and create one clear conventional commit.
110refactor
Improve the shape of existing code without changing behavior.
104debug
Debug systematically: observe, hypothesize, test, fix, verify.
96