matt-to-spec
Before using this method, read the knowledge and team rules: project knowledge comes from team-knowledge (tw brief).
This skill takes the current conversation context and codebase understanding and produces a spec. Do NOT interview the user; just synthesize what you already know.
Use the project tracker and labels already configured. If absent, retain a local task draft.
Process
-
Explore the repo to understand the current state of the codebase, if you haven't already. Use the project's domain glossary vocabulary throughout the spec, and respect any ADRs in the area you're touching.
-
Sketch out the seams at which you're going to test the feature. Existing seams should be preferred to new ones. Use the highest seam possible. If new seams are needed, propose them at the highest point you can. The fewer seams across the codebase, the better - the ideal number is one.
Use already agreed interfaces and acceptance criteria. Ask only about a material unresolved testing choice.
- Write the spec using the template below, sized to the actual task. Publish it and apply project labels only when that external action is authorized; otherwise retain a reviewable local draft.
For a team task, use the versioned section format as the shared plan: define the real starting state, actor, business steps, observable outcome, negative cases and acceptance owner before splitting work; investigate affected operations and cross-service data producers/consumers. Then assess complexity and risk separately, give acceptance and tasks stable IDs, and declare their actual dependencies. Record unresolved business choices with their affected sections. Parent and child assessments are separate; simple tasks need a short plan before implementation and may use combined plan/code review. Record each unresolved question with a stable ID, affected sections and a responsible person; scope changes and constraints remain pending until actually resolved. Carry forward existing approval and publish only within authorization. Standalone use keeps the prose template below. Name the entry-level API, RPC or UI seam the acceptance tests will drive.