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
$ day-shift slice new --spec-id tic-tac-toe-demo
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 the answer pages, concept, comparisons, demo, and FAQ without leaving the site.
Search by a problem, workflow step, or tool boundary.