teammate-flow

Teammate Flow

Consumers: /kon:team.

Teammate-flow defines the shared workflow skeleton for the kon team — from exploration to implementation to review. Each agent owns their segment; the orchestrator strings them together.

Orchestrator context: follow skills/orchestrator-context — artifacts hold full output; orchestrator routes by file pointer only.

Core principles (always): follow skills/core-principles — first principles (don't hide the issue); simplest, most concise correct solution.

When anything is unclear: ask the user — do not guess or hallucinate. Follow skills/ask-dont-guess. Orchestrator must not advance to the next stage until material uncertainty is resolved.

Shared flow (Full pipeline)

These steps are required in order for /kon:team:

1. Plan reuse check — if .kon/plan-<SESSION_ID>.md exists (or the most recent .kon/plan-*.md for cross-session reuse after /kon:design), read it and ask the user once: reuse or re-plan? Skip Azusa, pre-plan gate, and Mugi on reuse (unless user chooses re-plan). See commands/team.md.
2. 🎸 Azusa + optional 📚 Jun (parallel when task needs external docs) — see skills/external-research. Jun writes .kon/research.md.
3. Pre-plan gate (MANDATORY) — orchestrator runs skills/pre-plan-gate: ask high-level + implementation questions; write sessions/<SID>/understanding.md; do not spawn Mugi until understanding is sufficient and user has answered.
4. 🍰 Mugi — structure the work into .kon/plan-<SESSION_ID>.md (read understanding.md, .kon/research.md, explore.md).
5. User confirms plan (MANDATORY) — After Mugi finishes:
   • Orchestrator presents the plan summary to the user
   • If ## Decisions needed section exists, present each decision with its default
   • STOP and wait for explicit user approval — do NOT spawn Yui automatically
   • Only proceed to step 5 after user says "go", "approved", "proceed", or similar confirmation
   • This applies even in --yolo mode — plan approval is always required
   • Update session (required — dashboard shows ⏸ waiting):

     python3 $KON_ROOT/scripts/kon_session.py wait-for-user --id "$SID" \
       --after plan --summary "Plan ready — approve to start milestone 1?"
     

   • After user confirms:

     python3 $KON_ROOT/scripts/kon_session.py user-continued --id "$SID" \
       --summary "Approved plan"
     

6. Milestone loop — For each milestone in the plan (or all steps if no milestones):
   • 🎶 Yui — implement this milestone only. "Working on Milestone X..."
     • Execute steps for current milestone
     • Stop after completing milestone (don't continue to next milestone)
   • 🧹 Sawako — garbage collect the implementation (runs immediately after Yui — no user gate here)
     • Remove dead code: unused functions, variables, imports
     • Remove redundant comments that just restate what code does
     • Simplify over-complex logic, remove duplicate logic
     • Verify before removing — use grep to confirm nothing is referenced
     • No behavior changes — tests should still pass
   • 📝 Mio — review changes for this milestone only
     • Follow skills/strict-review on the diff from this milestone
     • If BLOCKED/NEEDS_CHANGES → Yui fixes → Sawako cleans → Mio re-reviews (repeat until approved)
     • If APPROVED → keep Task ids across milestones (do not clear here). User gate (MANDATORY) before the next milestone or summarize:
       • Present milestone summary: what changed, Mio verdict, open issues if any
       • STOP — do NOT spawn the next milestone or Nodoka until the user approves
       • Update session (dashboard shows ⏸ waiting):

         python3 $KON_ROOT/scripts/kon_session.py wait-for-user --id "$SID" \
           --after milestone --milestone N \
           --summary "Milestone N approved by Mio — proceed to milestone N+1?" 
         

         (Last milestone: summary text like "Milestone N approved — proceed to summarize?")
       • After user confirms: user-continued, then next milestone or step 6
   • Repeat until all milestones complete (each followed by user gate)
7. Manual testing — After the last milestone gate, user runs tests themselves.
   • User verifies the implementation works in their environment