Engineering
Spec to Task Shards
Make the agent split the work before it starts swinging a hammer.
Use when
The request is too large or vague for a single coding-agent prompt but not large enough to justify a full project plan ceremony.
Cadence
Before multi-file feature work or migrations
Verification
A written spec, non-goals, acceptance checks, and ordered task shards exist before implementation begins.
Advanced specStructured loop spec
| Field | Value |
|---|---|
| Name | Spec to Task Shards |
| Category | Engineering |
| Trigger | Before multi-file feature work or migrations |
| Objective | Make the agent split the work before it starts swinging a hammer. |
| Allowed inputs | Relevant files, source notes, logs, tests, screenshots, metrics, or task state for this loop |
| Allowed actions | Read the relevant code, docs, tickets, and constraints before proposing implementation.; Write a short spec with goal, non-goals, affected files, risks, and acceptance checks.; Break the spec into small task shards that can each be implemented and verified independently.; Order shards by risk: scaffold, tests, smallest behavior, integrations, cleanup, docs.; Stop and ask for approval if the spec exposes ambiguous product behavior, data migration risk, or security impact. |
| Verification | A written spec, non-goals, acceptance checks, and ordered task shards exist before implementation begins. |
| Stop condition | Stop when the verifier passes, the budget is exhausted, no progress is made, a blocker appears, or approval is required. |
| Budget | Set a time, turn, token, retry, file, or dollar cap before running the loop. |
| Approval boundary | Human approval required before publishing, sending, deleting, spending, changing accounts, touching production, or making reputational/legal/financial commitments. |
| Safe output | Pull request, patch, report, or evidence log |
| Works with | Claude Code, OpenAI Codex, Cursor, Gemini CLI, any tool-using coding agent |
RunbookSteps
- Read the relevant code, docs, tickets, and constraints before proposing implementation.
- Write a short spec with goal, non-goals, affected files, risks, and acceptance checks.
- Break the spec into small task shards that can each be implemented and verified independently.
- Order shards by risk: scaffold, tests, smallest behavior, integrations, cleanup, docs.
- Stop and ask for approval if the spec exposes ambiguous product behavior, data migration risk, or security impact.
Copy promptPrompt
Run the Spec to Task Shards loop. Inspect the relevant code and docs, then write a concise spec with goal, non-goals, affected files, risks, and acceptance checks. Split it into independently verifiable task shards ordered by risk. Do not implement until the spec and shard list are coherent. Stop for approval if product behavior, data migration, billing, or security scope is ambiguous.