Feature Proposal: Phase 4 Story Cycle Orchestrator (Automated Create → Dev → Code Review)

[DmitriyZhorov]

Context

The Workflow Map reference notes under Phase 4:

*Coming soon, full phase 4 automation

The build cycle is currently manual — each step (create-story, dev-story, code-review) must be invoked in a separate fresh chat. This is the right design (fresh context prevents bleed), but the human is the orchestrator shuffling between sessions.

Proposal

A story-cycle orchestrator skill that automates the implementation loop by dispatching each phase as a separate subagent with its own fresh context window:

Sprint Status → Create Story (subagent) → Dev Story (subagent) → Code Review (subagent) → next story

Key Design Points

1. Each phase runs as a subagent — completely fresh context, no bleed between create/dev/review. This preserves the isolation that fresh-chat-per-step provides.
2. The orchestrator is lightweight — it only reads sprint-status.yaml between subagent calls, relays findings, and coordinates user decisions. It does NOT implement or review code.
3. Code review decisions stay human-in-the-loop — CR findings are relayed back to the orchestrator, where the user decides on decision-needed items. Only patch items get auto-applied (after approval) via a fix subagent.
4. Two modes: single (one story, then stop) and continuous (loop through all remaining stories, confirming between each).
5. Fix cycle cap — max 3 fix→review iterations before halting to prevent infinite loops.

Workflow

1. Read sprint-status.yaml, find next processable story
2. Present plan to user, confirm mode (single/continuous)
3. For each story:
   a. If backlog       → spawn create-story subagent
   b. If ready-for-dev → spawn dev-story subagent
   c. If review        → spawn code-review subagent
   d. Relay CR findings to user for decisions
   e. If patches approved → spawn fix subagent, re-run CR
   f. Mark done, commit, proceed to next (if continuous)

Cross-Platform Consideration

Different IDEs have different subagent mechanisms:

• VS Code Copilot: runSubagent tool
• Claude Code: subprocesses / tool use
• Cursor: composer agents

The skill would need to describe the subagent dispatch abstractly enough that each platform can interpret it through its native mechanism — or ship platform-specific variants.

Proof of Concept

I built a working version of this as a custom skill (bmad-story-cycle) in my project. It follows the drops-deep-run pattern (which already uses subagent dispatch for LLM prompt processing). Happy to share the full SKILL.md as a starting point.

The skill:

• Reads sprint-status.yaml to find the next processable story
• Dispatches create-story, dev-story, and code-review as separate subagents, each loading the full SKILL.md of the target skill
• Instructs each subagent to skip greeting and run fully automatically
• Relays code review findings back for user decisions
• Handles fix cycles with a 3-iteration cap
• Supports single and continuous modes

Questions for the Maintainers

1. Is this aligned with your planned approach for Phase 4 automation?
2. Should it integrate with the customize.toml surface (activation hooks, persistent facts)?
3. Should it be a standalone skill or part of an existing agent (e.g., Amelia)?
4. Any preference on how to handle platform-specific subagent dispatch?

[bmadcode]

@DmitriyZhorov quickdev already does what you describe and will soon replace the normal dev and create story workflows

[DmitriyZhorov]

awesome, thanks, really looking forward to it!