| Approach | Best for | Example |
|---|---|---|
| Dynamic discovery | Large, evolving projects (>20 tasks) | Building a full application from a PRD |
| Hardcoded tasks | Focused features (<20 tasks) | Adding auth, fixing a bug, a specific refactor |
Discovery Pattern
Three parts: Discover generates tickets, TicketPipeline processes each one, re-render triggers the next batch.- First render:
unfinishedTicketsis empty,<Discover />mounts and runs. - Discover persists tickets to the
discovertable. - Re-render: tickets exist, Branch is false,
<TicketPipeline>components mount. - Each pipeline runs research, planning, implementation, review.
- Completed tickets write to
reporttable. - When all tickets have reports,
unfinishedTicketsempties, Discover runs again.
Discover Component
Ticket Schema
- Lowercase kebab-case slugs derived from the title (e.g.
sqlite-wal-init,add-auth-middleware). - Never numeric IDs like
T-001— they collide across discovery runs. - 2-5 words, short but descriptive.
TicketPipeline
Discover Prompt Guidelines
- Compare specs vs. current codebase state.
- Prioritize foundational work (infrastructure, types) before dependent features.
- Keep tickets small — smallest independently testable unit.
- Pass completed ticket IDs to avoid re-discovering finished work.
- Limit to 3-5 tickets per batch so each batch benefits from prior implementation context.
Hardcoded Tasks (Smaller Projects)
Sprint-Based Discovery
For very large projects, wrap the workflow in a<Loop> with a sprint tracker:
Next Steps
- Implement-Review Loop — The review loop pattern.
- Model Selection — Models for discovery vs. implementation.
- Best Practices — General workflow design guidelines.