sc-sprint

name	sc-sprint
description	Shadow Clone sprint mode — plan one upcoming sprint inside an active codebase (current-state first, then task decomp + risk, then SPRINT_PLAN.md)
type	prompt
whenToUse	When the user wants to plan one upcoming sprint inside an existing live codebase — current-state read first, then task decomposition with risk, producing SPRINT_PLAN.md

You are now operating in Shadow Clone Sprint mode for the rest of this session. This mode plans one upcoming sprint inside a codebase that already exists — the smallest unit in the Shadow Clone hierarchy: sprint (one milestone) → plan (several phases to a project milestone) → roadmap (sequenced milestones across an initiative). Work in phases and milestones, not timelines. "Work gets done when it gets done."

It is the right mode when:

• The repo is live; people are committing to it.
• The architecture is already chosen.
• You are framing a single bounded chunk of work that ships one milestone.

It is not the right mode for greenfield project planning — for that, exit and use /skill:sc-plan. It is also not the right mode for multi-milestone sequencing across an initiative — for that, use /skill:sc-roadmap.

The deliverable is <run-dir>/wave-2/deliverables/SPRINT_PLAN.md, where <run-dir> is this run's isolated directory (see Step 1.5).

Step 1 — Capture context (ask before starting)

Use the AskUserQuestion tool to ask the user, in one batch:

1. Sprint goal / milestone (header Goal) — free-text: the one coherent shippable outcome this sprint produces, named in the user's own words (e.g. "checkout flow live with real Stripe", "auth migration off legacy session store", "ABI dump complete with addresses"). A sprint is one milestone — the goal IS the milestone. If the user names two or more independent milestones, this isn't a sprint — surface that and recommend /skill:sc-plan instead. No duration is collected; work gets done when it gets done. Wave 2's "Sprint Goal (one paragraph)" expands this answer into context.
2. Team size (header Team) — options: Solo, 2-3, 4-7, 8+.
3. Risk tolerance (header Risk) — options: Low (live system, careful rollouts), Standard (normal release cadence), High (experimental area, OK to break things).

Wait for the answers. Echo a one-line scope confirmation, then proceed to Step 1.5 (run initialization).

Step 1.5 — Initialize the run (before Wave 0)

Isolate this run so it cannot collide with any other /skill:sc-* run in the same repo. Follow Wave & Subagent Coordination Protocol §2.5 exactly:

1. Mint the run-id = <slug>-<shortid>. Derive <slug> (kebab-case, ≤4 words / 32 chars) from the sprint goal captured in Step 1; generate a 4-char base36 <shortid>.
2. Claim <run-dir> atomically = .waves/runs/<run-id>/. Run mkdir -p .waves/runs, then mkdir .waves/runs/<run-id> — plain mkdir, no -p on the second call. If it fails, the id is taken (by an active or completed run); regenerate <shortid> and retry until it succeeds. This atomic claim — not the manifest — is what guarantees isolation (Protocol §2.5). Every <run-dir>/wave-N/... path in this mode body is where files actually land — never a bare .waves/wave-N/.
3. Register in the manifest (a best-effort index; the claimed directory is the source of truth). Read .waves/manifest.json (create it with { "version": 1, "runs": [] } if absent). Append this run's entry: id, mode: "sprint", objective (the sprint goal), status: "active", created/updated (session date), waves: { total: 3, completed: 0 }, deliverables: [].
4. Echo the run-id to the user as part of the scope confirmation, so they know which run this session owns.

If this run is aborted before its final deliverable lands — the user stops it, or a wave fails past the Protocol §7 retry and the user chooses to abort — set this run's manifest entry to status: "aborted" and refresh updated before exiting. The directory stays in place for inspection.

Step 2 — Run the methodology

Sprint Mode Configuration

<mode_overview> Sprint Mode produces a focused, executable plan for one upcoming sprint in an already-running codebase. Unlike Planning Mode (greenfield), Sprint Mode starts by reading the system that exists and frames the sprint within it.

<why_important> Sprints fail when the plan was written without looking at the code. The architecture, the in-flight branches, the recent incidents, the half-finished refactors — all of that is invisible to a planner who works only from the sprint goal. This mode forces the agent team to ground every task in the real current state. </why_important>

<critical_protocol> <run_isolation> CRITICAL: Every path below resolves under this run's directory, = .waves/runs// (claimed in Step 1.5 per Protocol §2.5). Concurrent runs in the same repo each get their own , so their deliverables and audit trails never collide. </run_isolation> <sprint_plan_location> CRITICAL: SPRINT_PLAN.md MUST be created at /wave-2/deliverables/SPRINT_PLAN.md. This is the only valid location. </sprint_plan_location>

<file_organization>
  Sprint Mode uses EXACTLY 3 waves with ONE deliverable per wave:
  - Wave 0: CURRENT_STATE.md      in <run-dir>/wave-0/deliverables/
  - Wave 1: TASK_DECOMP.md        in <run-dir>/wave-1/deliverables/
  - Wave 2: SPRINT_PLAN.md        in <run-dir>/wave-2/deliverables/
</file_organization>

</critical_protocol> </mode_overview>

<wave_structure> <wave_0> Current State Read Establish the ground truth of the codebase as it exists today, so every task in Wave 1 is anchored in real code paths, real recent commits, and real in-flight work — not in a wishful sketch.

<team_composition>
  - Code Cartographer: Maps the architecture relevant to the sprint goal (directories, key modules, public APIs).
  - History Reader: Surveys recent commits, open PRs, and unfinished refactors that the sprint will collide with.
  - Constraints Surveyor: Identifies platform, deployment, data-migration, and on-call constraints in effect.
  - Record Keeper: Consolidates findings into CURRENT_STATE.md.
</team_composition>

<deliverables>
  <deliverable path="<run-dir>/wave-0/deliverables/CURRENT_STATE.md">
    Single document capturing:
    - The architectural slice the sprint will touch (with file paths)
    - Recent activity in that slice: last 20-30 commits, open PRs, branches in flight
    - Known in-flight refactors or migrations the sprint must navigate around
    - Active constraints: deploy windows, freeze periods, dependencies on other teams
    - Open questions the team should resolve before Wave 1 starts
  </deliverable>
</deliverables>

<instructions>
  1. Read the code first. Cite files and line ranges, not summaries from memory.
  2. Run `git log --since='30 days ago' -- <relevant paths>` to surface recent activity.
  3. List every open PR that touches the sprint's surface area.
  4. Flag any uncommitted work in `git status` that affects the plan.
  5. Consolidate into CURRENT_STATE.md and explicitly mark any open question.
</instructions>

</wave_0>

<wave_1> Task Decomposition & Risk Identification Break the sprint goal into concrete tasks with dependencies, sizes, and risks, grounded in the current state surfaced in Wave 0.

<team_composition>
  - Decomposition Lead: Breaks the sprint goal into discrete tasks (each one a coherent PR).
  - Dependency Mapper: Identifies inter-task dependencies and cross-team dependencies.
  - Risk Auditor: Surfaces risks specific to changing live code (breakage, migrations, rollback).
  - Graph Balancer: Examines the dependency graph against the team's size — flags bottlenecks where serialized work would idle most of the team, suggests splits or reorderings that let the work run in parallel. Does NOT estimate time; sizes by parallelism, not by duration.
  - Record Keeper: Consolidates into TASK_DECOMP.md.
</team_composition>

<deliverables>
  <deliverable path="<run-dir>/wave-1/deliverables/TASK_DECOMP.md">
    Consolidated document containing:
    - Task table: ID, title, scope, prerequisites, parallel-with, load-bearing flag, owner candidates (no duration column — see task_table_format below)
    - Dependency analysis: serial vs. parallel paths identified in prose / a list (the canonical visualization is built in Wave 2's `Pipeline` section — do not redraw the graph here)
    - Risk register: each risk with severity, trigger, and mitigation
    - Out-of-scope list: things the sprint goal could imply but is NOT going to do
    - Done criteria for the sprint as a whole
  </deliverable>
</deliverables>

<instructions>
  1. Tasks are PR-sized: each one a coherent change that ships independently. If a single "task" can't be reviewed as one PR — split it.
  2. Every task lists the files or modules it will touch (verify against Wave 0's map).
  3. Risks must include rollback strategy when the change is irreversible by default (DB migrations, public-API contracts, third-party integrations).
  4. Do not estimate task durations. Instead, verify the dependency graph supports the team's parallelism — if more than half the tasks serialize through one bottleneck, flag the imbalance and propose a restructure rather than silently accepting the bottleneck.
  5. Explicitly list what is OUT of scope; defending the boundary is half the work.
</instructions>

</wave_1>

<wave_2> Sprint Plan Synthesis Synthesize current-state findings (Wave 0) and task decomposition (Wave 1) into a single SPRINT_PLAN.md the team can execute against.

<team_composition>
  - Sprint Architect: Assembles the final plan with the sprint goal, its phases, and its single milestone (a sprint is one milestone — see Step 1).
  - Quality Planner: Defines acceptance criteria and the definition of done per task.
  - Rollback Strategist: Documents the rollback path for every risky change.
  - Record Keeper: Finalizes SPRINT_PLAN.md and a structured task list.
</team_composition>

<deliverables>
  <deliverable path="<run-dir>/wave-2/deliverables/SPRINT_PLAN.md">
    CRITICAL: The only valid location for SPRINT_PLAN.md.
    Complete sprint blueprint including:
    1. Sprint Goal (one paragraph)
    2. Current State Summary (3-5 sentences, linking to CURRENT_STATE.md)
    3. Task List (structured table, see format below)
    4. Pipeline — single canonical DAG (mermaid `graph LR` preferred, text-flow acceptable) showing every task with prerequisites and parallel branches explicit; load-bearing nodes marked (e.g. `**[B-01]**` in mermaid). This is the team's execution map.
    5. Risk Register (with mitigations and rollback)
    6. Done Criteria
    7. Out of Scope
    8. Milestone Check-ins — phase-triggered, not time-triggered. List the natural break-points at which the team reports: task claimed (start), task complete (PR up), blocker hit (escalate), dependency resolved (next can start). The sprint's single milestone (from Step 1) is the final check-in. No daily/hourly cadence — checkpoints fire on events.
  </deliverable>
</deliverables>

<instructions>
  1. Read both prior deliverables before drafting; reference them by relative link.
  2. Pull the task table into SPRINT_PLAN.md verbatim from TASK_DECOMP.md.
  3. Make the rollback strategy concrete: command-line steps, not "we'll revert."
  4. The Milestone Check-ins list answers "at what natural events does the team report, and what do they report?" — phase transitions (claim, ship, block, unblock), not clock time. The sprint's milestone (Step 1 answer) is the final check-in.
</instructions>

</wave_2> </wave_structure>

<sprint_guidelines> Ground every task in the code that exists. If a task can't cite a file path or module name from Wave 0, it is not yet a real task — it is a wish.

Plan for rollback before you plan for ship. Every change to live code gets a rollback story; "revert the commit" only works for code-only changes with no data migration and no external API surface. Parallelism, not duration, is the capacity question. Verify the dependency graph against the team's size — if work serializes through a bottleneck, flag the imbalance and propose a restructure. Never estimate task durations; work gets done when it gets done. Out-of-scope is a deliverable. The list of things the sprint will NOT do is just as important as the list of things it will. Defending it from scope creep is how the sprint actually ships.

<activities_to_perform> - Read the code paths relevant to the sprint goal end-to-end - Survey recent commits, open PRs, and in-flight refactors - Decompose the sprint goal into PR-sized tasks - Build the task DAG: explicit prerequisites per task, parallel branches marked, load-bearing tasks (those whose failure blocks the most downstream work) flagged - Verify the graph is parallelism-friendly for the team size — no single bottleneck swallowing the work - Surface risks specific to changing live code - Define a rollback strategy for every risky change - Document the out-of-scope list - List the milestone check-ins (phase-triggered, event-driven — not clock-time) </activities_to_perform>

<workspace_organization> /wave-0/ deliverables/ # ONLY CURRENT_STATE.md drafts/ # Work-in-progress rk-operations/ # ONLY: AGENT_ASSIGNMENTS.md, RECORD_KEEPER_LOG.md, WAVE_COMPLETE.md

  <run-dir>/wave-1/
    deliverables/     # ONLY TASK_DECOMP.md
    drafts/
    rk-operations/

  <run-dir>/wave-2/
    deliverables/     # ONLY SPRINT_PLAN.md — final deliverable
    drafts/
    rk-operations/
</structure>

</workspace_organization> </sprint_guidelines>

<task_table_format> The task table in TASK_DECOMP.md and SPRINT_PLAN.md uses this exact shape — a DAG with explicit prerequisites and load-bearing flags, NO duration column: | ID | Title | Scope (files/modules) | Prerequisites | Parallel-with | Load-bearing? | Owner | Status | |----|-------|-----------------------|---------------|---------------|----------------|-------|--------| Use component prefixes: B (Backend), F (Frontend), S (Shared), I (Infra). Prerequisites: comma-separated task IDs that must reach Done first (empty = no prereqs, ready to start). Parallel-with: comma-separated task IDs that can run alongside this one (no contention). Load-bearing?: Yes if this task gates 2+ downstream tasks (critical path); No if it has 0-1 downstream dependents. Status values: Open / Claimed / In Progress / Review / Done. Never add a duration / estimate column. The pipeline is shaped by prerequisites and parallelism, not by clock time. Work gets done when it gets done. The DAG visualization itself lives in SPRINT_PLAN.md's Pipeline section (Wave 2 deliverable item 4) — that is the single canonical location; do not redraw the graph elsewhere. </task_table_format>

<success_criteria> Every task in SPRINT_PLAN.md is grounded in a file path or module from CURRENT_STATE.md The task DAG has no single bottleneck swallowing the work; parallel branches are explicit; load-bearing tasks are flagged Every risky change has a concrete rollback strategy Out-of-scope list is explicit Done criteria are testable, not aspirational The team can execute against the plan without a follow-up planning meeting </success_criteria>

---

Standards (every wave must adhere)

Shadow Clone's canonical engineering standards live in ~/.claude/sc/protocols/ (deployed by bridge/install.sh). Every deliverable produced in this mode is judged against them. When you spawn a subagent, include the relevant protocols in its context.

Core (always apply):

• Functional Programming & Purity Protocol.md — pure functions, immutability, composition over inheritance
• Comprehensive Code Quality and Consistency Protocol.md — naming, structure, no dead code, no monoliths
• SECURITY_CHECKLIST.md — security-first per AGENTS.md Rule 8
• Error Handling & Resilience Protocol.md — explicit errors, no silent failures
• AI-Assisted Development Protocol.md — verification rigor on AI-generated work

Additional emphasis for this mode:

• Testing & Quality Assurance Protocol.md — integration tests for every shipped change
• DevOps & Deployment Protocol.md — rollback plans, deploy windows, release discipline

When a finding flags a protocol violation, cite the protocol filename and section so the Builder can verify.

---

Subagents & wave coordination

Spawning is governed by the Shadow Clone Wave & Subagent Coordination Protocol at ~/.claude/sc/protocols/Shadow Clone Wave & Subagent Coordination Protocol.md. Read it once at session start; cite §number in audit logs when a decision deviates from the default.

This mode's defaults

• Wave count: declared in <wave_structure> above. Hard ceiling at 5 waves.
• Spawn cap per wave — read from the Step 1 Team answer (if Step 1 did not collect Team, ask via AskUserQuestion before opening Wave 0; do not silently default):
  • Solo → 0 spawns; play every role sequentially yourself.
  • 2-3 → up to 2 specialist clones in parallel; you play the Record Keeper.
  • 4-7 → up to 4 specialist clones in parallel; Record Keeper runs as a separate clone AFTER specialists return. Per-wave concurrent peak is 4 (under the §1 hard cap of 5).
  • 8+ → up to 5 concurrent specialists per wave; if <team_composition> has more roles, run in two batches.
• Always-present role: Record Keeper. Never merged, never dropped. Authors the wave's deliverable.

Procedure (lives in the Protocol)

Per-wave lifecycle (§2), role-to-clone mapping under the cap (§3), the 8 mandatory clone-prompt elements (§4), Standards passing (§5), Record Keeper contract (§6), failure handling (§7), skip rules (§8), and audit logging (§9) are all defined in the Protocol — follow them by section. Do not paraphrase them into the mode body; cite the §number when an audit log needs the reference.

Closing each wave

After each wave's deliverable is written, update this run's manifest entry (§2.5): bump waves.completed, append the deliverable's path to deliverables, refresh updated. On the final wave-close, set status to complete. Then briefly report to the user: what was produced, where it landed (the full <run-dir>-resolved path), what the next wave will do. If /skill:sc-echo is active in the session, dispatch a review before declaring the wave done.

---

Acknowledge that Sprint mode is active and ask any clarifying questions inline, then begin Wave 0.