Commits:
# Start the lesson — /prd-to-issues skill added
pnpm reset 08.02.01
pnpm cherry-pick 08.02.01
I've always had some discomfort when it comes to multi-phase plans with AI. The issue is that human developers don't work that way.
When we understand the destination, we don't rigidly plan everything out in a single document. Instead, we create a Kanban board with different issues, some of which are blocked by others.
Think of it like this: some issues might have dependencies. For this issue to be completed, three other issues must be completed first.
This dependency structure means that two developers can work on independent issues at the same time. Once those are done, they can both grab the next set of issues independently, and then one developer works on the final issue.
<TableWrapper>
| Aspect | Multi-Phase Plan | Kanban Board |
|---|---|---|
| Flexibility | Rigid, hard to modify | Easy to add new issues |
| Parallelization | Sequential phases | Independent parallel work |
| QA Integration | Requires scheduling | Grows naturally |
| Scalability | Hard to extend | Infinitely extensible |
| </TableWrapper> |
A Kanban board is much less prescriptive than a multi-phase plan. If you want to add another issue, you just describe a blocking relationship. You haven't needed to change any other part of the plan.
In my experience, editing multi-phase plans is much harder. It's also really easy to QA because you just mark an issue as done, QA it, and add all the feedback as a separate issue. The graph grows naturally instead of forcing it into a plan.
/prd-to-issues SkillIn the repo, I've gotten rid of the /prd-to-plan skill and added my own /prd-to-issues skill. This breaks a PRD (which is probably already in GitHub) into independently grabbable GitHub issues using Vertical Slices and Tracer Bullets.
