Spec-driven development

Spec-driven development means the work item is the source spec for implementation. A person, coding tool, or agent starts from the same initiative, bug, or todo that the team plans, reviews, and measures.

What counts as the spec

An initiative, bug, or todo can act as a spec when it has enough context to guide the next action. Use Initiatives for planned work, Bugs for defects or incidents, and Todos for simple personal work.

The spec can include the title, description, status, owner, assignees, comments, linked documents, taxonomy, source links, and a clear done signal. For synced issue trackers, the source issue can remain the execution record while an initiative carries the roadmap context above it.

Write enough to start

A useful spec names the problem or outcome, the constraints, the expected result, the links people need, and any open decisions. It should be clear enough for someone else to pick up the work without asking where the context lives.

Do not create tiny initiatives for every follow-up. Keep the bigger brief in an initiative, use bugs for repair work, and keep todos small. Connected commits, pull requests, completed tasks, and agent activity can capture the execution details.

Shape rough work

When planned work is rough, use Writer Mode to turn notes about the problem, scope, constraints, proposal, and risks into an initiative brief.

Use Documents for supporting context that should stay attached to the work, such as requirements, diagrams, demos, or handoff notes. Documents support the spec; they do not replace the work item people assign, review, and measure.

Launch from the spec

AI Handoff and Send to app build the prompt from the source work: title, description, status, linked initiative, taxonomy, comments, documents, and source links when available.

For queued execution, Agent Sessions keep the run attached to the original initiative, bug, or todo. The worker can report progress, plans, URLs, completion, failure, or blockers back to the same source work.

Keep delivery attached

Pull requests, commits, comments, completed tasks, and agent sessions should point back to the spec they came from. That lets Recaps, Roadmap, and Insights reflect delivery without rewriting the same update in another tool.