Keep the spec visible
Planning should retain a clear link to the original desired outcome and constraints. That makes it easier to see when a task solves a local problem but drifts from product intent.
Answer page
Trace the specification through planning, then create tasks that have a single verifiable outcome, bounded paths, and explicit validation.
Direct answer
Break a product specification into ordered tasks that each deliver one reviewable behavior. Every task should preserve the spec trace, limit implementation paths, name dependencies and acceptance criteria, and include a validation command that proves its own outcome.
Practical guidance
Planning should retain a clear link to the original desired outcome and constraints. That makes it easier to see when a task solves a local problem but drifts from product intent.
A task should be small enough that a reviewer can recognize its result and validation. Split work when the task combines unrelated behavior, risks, or code ownership boundaries.
Place enabling work before the behavior that relies on it. This gives agents a clear sequence and prevents them from improvising around missing prerequisites.
Verified demo evidence
Repository-writing command
Prompt: "Create the next slice from the selected specification."
outcome: Created slice: 01-tic-tac-toe-demoAuthorship and sources
Keep exploring
The objective, scope, acceptance criteria, and validation a coding agent needs before changing code.
Read nextA safe, evidence-led way to begin coding-agent work in an existing repository.
Read nextCoordinate multiple agents through task boundaries, dependencies, and shared repository evidence.
Read nextFind your answer
Search practical answer pages and product context, then follow each result to the canonical workflow or reference owner.
Search by a problem, workflow step, or tool boundary, or choose a filter.