Sprint Document Update
Update the sprint doc at docs/plans/<date>_Sprint.md (or the most recent sprint file).
Sprint doc structure
The sprint doc uses per-persona queues (not wave tables). Each persona (Alice, Bob, Cindy, Dan, Elsa) has their own section with three tables:
## <Persona> — <Domain>
### Active
| Status | Issue | Repo | Description | Handoff |
### Queue
| # | Priority | Issue | Repo | Description |
### Completed
| Issue | Repo | PR | SHA | Wave |
What to update
1. Move merged items: Active → Completed
When a PR merges, move its row from the persona's Active table to Completed:
### Completed
| Issue | Repo | PR | SHA | Wave |
|-------|------|----|-----|------|
| ~~#NNN~~ | repo | #PR | sha7 | — |
Get merge SHAs:
gh pr view <num> --repo wrfcoin/<repo> --json mergeCommit --jq '.mergeCommit.oid'
2. Promote next queue item: Queue → Active
After clearing an Active slot, move the top Queue item to Active with status next:
### Active
| Status | Issue | Repo | Description | Handoff |
|--------|-------|------|-------------|---------|
| next | #NNN | core4 | Description | [handoff](path.md) |
Re-number the remaining Queue rows starting from 1.
3. Header counts
Update the top-line counts:
- Total PRs merged
- Open PRs (check all repos)
- Approximate open issues
4. Velocity table
Update the sprint row with new PR count and key milestones.
5. Launch readiness
Update "What's working" and "What's blocking launch" if merges changed the picture.
6. Dispatch Prompt Patterns (always include)
After updating counts and tables, generate themed dispatch prompt patterns for each persona that has queued work. These go into the sprint doc as a new subsection under each persona, right after their Queue table and before Completed:
### Dispatch Prompts
<!-- Auto-generated by sprint-update. Copy-paste to launch agents. -->
**Round 0 — Revisions** (if any Active items are changes-requested):
> fix the N changes-requested Dan PRs on their existing branches: ...
**Round 1 — [Theme]** (N agents, M issues):
> launch N agents on Dan's [theme] [priority]: ...
**Round 2 — [Theme]** (N agents, M issues):
> launch N agents on Dan's [theme] [priority]: ...
Rules for generating prompts
- Sizing: 2-3 issues per agent, max 4 agents per round, 8-12 issues per round
- Grouping: Group by repo + theme (e.g., "infra Docker", "backend resilience"), NOT by batch number ("infra batch 1")
- Priority order: Work top-down by priority — P0 first, then P1, then P2, etc. Don't mix priorities in a single round unless they share a theme.
- Revision round first: If any Active items have status
changes-req, generate a Round 0 that lists the specific fixes needed per PR (from review comments). - Name each round: Use a descriptive theme name, not a number. E.g.:
- "backend integration wiring" not "backend round 1"
- "infra Docker hardening" not "infra P2 batch"
- "core4 consensus fixes" not "Alice round 2"
- Include issue numbers: Every prompt must list the specific issue numbers.
- Estimate rounds: Show how many rounds it would take to clear the queue. Only generate detailed prompts for the next 3-4 rounds. Summarize the rest.
- All 5 personas: Generate prompts for every persona that has queued work, not just the one the user is currently focused on.
Example output for a persona section
### Dispatch Prompts
**Round 0 — Revisions** (fix 2 changes-requested PRs):
> fix changes-requested PRs: backend#509 (target enhanced_unified_api_optimized.ts),
> infra#301 (add CORS to expose-lan.sh + docker-compose.lan.yml)
**Round 1 — backend integration** (2 agents, 6 issues):
> launch 2 agents on Dan's P2 backend integration issues:
> - backend security/config: #486 dev key fallback, #487 CORS 8080, #493 health→core4
> - backend performance: #367 pg.Pool exhaustion
**Round 2 — infra integration + compose** (2 agents, 6 issues):
> launch 2 agents on Dan's P2 infra items:
> - infra integration: #291 onboarding secrets, #297 missing depends_on, #253 ZFS overrides
> - infra Docker: #259/#261 single-stage, #266 wrf limits, #224 PAYMASTER_CHAIN_ID
When to regenerate
Regenerate dispatch prompts every time sprint-update runs. Old prompts are replaced entirely — they reflect the queue state at update time, not historical plans.
After updating
Update the sprint progress memory file:
/home/tony/.claude/projects/<project-slug>/memory/project_sprint_progress.md