Sprint plan

Sprint Plan Report

Read the start.canvas snapshot for a sprint and produce a planning markdown report. Read-only on Jira (the canvas is already a frozen snapshot — no fresh fetch needed). Writes one report file into the sprint folder.

This skill is the Claude port of the user's "Sprint Plan" prompt template. It expects sprint-snapshot has already produced a start.canvas for the target sprint. If it hasn't, the skill prompts to invoke sprint-snapshot first.

Quick start

/sprint-plan                                    → Aurora, current sprint (auto-detect newest)
/sprint-plan Borealis                               → single team
/sprint-plan Aurora --inc 28 --sprint 2         → explicit sprint
/sprint-plan Aurora --no-council                → skip clarity-council, LLM-only analysis

Parameters

Param	Default	Notes
Team	from memory or prompt	Same reference_default_scrum_team.md source as sprint-snapshot
Inc	latest from Scrum 📅/INC <N>/	Scan vault for newest
Sprint	latest from INC <N>/Sprint <N>/	Scan vault for newest
Personas	statistics-expert,scrum-master,product-owner,infographics-expert	Comma-separated; --no-council disables. infographics-expert is included by default per the always-add-charts feedback; their output drops Mermaid charts directly into the report body.

Workflow

- [ ] Phase 1: Resolve config (vault, team, inc/sprint, sprint config, team rules)
- [ ] Phase 2: Locate and load start.canvas + _snapshots.jsonl (start row)
- [ ] Phase 2.5: Locate previous sprint's end.canvas → derive carry-over set
- [ ] Phase 3: Convert canvas to structured markdown (issue table by status + by member, carry-over annotated)
- [ ] Phase 4: Apply team rules (overhead, wedge, in-review overhead, carry-over) to derive effective capacity
- [ ] Phase 5: Run clarity-council (observations + risks, with carry-over context) unless --no-council
- [ ] Phase 6: Render and write the report (date-stamped per run)
- [ ] Phase 7: Console summary

Phase 1 — Config

Resolve {{vault_root}}, {{jira_project}}, {{default_team}}, {{output_root}}, {{sprint_config}}, and {{team_rules}} per the contracts in sprint-snapshot/SKILL.md and sprint-snapshot/REFERENCE.md. Bootstrap missing files via the same AskUserQuestion patterns.

Phase 2 — Locate the start canvas

1. Look for {{output_root}}\start.canvas.
2. If missing, AskUserQuestion: Run /sprint-snapshot --phase start now (recommended) / Pick a different phase canvas / Cancel. Don't fabricate.
3. Read the canvas as JSON. Filter nodes to issue cards (id matches ^issue-); parse the markdown body for KEY, Summary, Assignee, Points, Type, Status (status comes from the column the card is in — derive from x-coord using the column constants in REFERENCE.md or, simpler, from the card's color field).
4. Also read _snapshots.jsonl and grab the row where phase == "start" for the totals (matches what's already on the canvas; faster to use directly).

Phase 2.5 — Previous sprint's end → carry-over set

Carry-over from the previous sprint is the planning skill's most load-bearing context — the team didn't get to choose all of this sprint's scope; they inherited part of it. Compute the carry-over set so the council, capacity math, and report all reflect reality.

1. Locate the previous sprint folder. {{output_root}} is …\INC <Inc>\Sprint <Sprint>\. The previous sprint is:
   • …\INC <Inc>\Sprint <Sprint - 1>\ if Sprint > 1
   • …\INC <Inc - 1>\Sprint 4\ (or the highest Sprint N folder in the prior INC) if Sprint == 1
2. Load the previous sprint's end.canvas. If it's missing, fall back in this order: latest week 3.canvas, latest week 2.canvas, latest week 1.canvas. If none exists, skip carry-over derivation and surface a console warning + a frontmatter flag (carry_over: unavailable). Do not invoke sprint-snapshot from here — the previous sprint is closed; if the SM forgot to capture an end snapshot, that's a process gap to surface, not silently paper over.
3. Parse issue cards from the previous-sprint canvas the same way as start.canvas (key, status, points).
4. Carry-over set = tickets present in both current_start.canvas and previous_end.canvas whose previous_end.status ∉ {Done, Won't Fix, Duplicate}. Per the user's planning convention: all unclosed items from the previous sprint are assumed to carry into this one. If a ticket was in the previous sprint, was unclosed at end, and isn't in this sprint's start, surface a console warning — that's an unusual planning decision the SM should confirm wasn't a mistake.
5. Sub-classify carry-over by previous-sprint end-status:
   • carry_over.in_progress — was IN PROGRESS at previous end; resume work, expect faster close
   • carry_over.in_review — was IN REVIEW at previous end; should close early this sprint
   • carry_over.todo — was TO DO at previous end; full sprint of work still ahead
6. Carry-over points = sum of points of carry-over tickets at current sprint start (use the new estimate if it changed). Track separately as carry_over_points.

State the result in one short sentence: "Carry-over from Sprint 1: 4 tickets (11 pts) — 1 in-progress, 2 in-review, 1 to-do."

Phase 3 — Canvas → markdown

Build the structured backbone before any narrative. Two views:

By status (kanban cross-section). Annotate carry-over rows with a 🔄 glyph in the leading column and a (carry-over: <prev-status>) suffix in the Summary cell so the SM can scan-find them:

## Committed Scope by Status

### TO DO (Unassigned) — N tickets, P pts
| | Key | Summary | Type | Points |
| :-: | :--- | :--- | :--- | --: |
| | JIRA:PROJ-1234 | Summary | Story | 3 |
| 🔄 | JIRA:PROJ-1100 | Summary (carry-over: in-review) | Story | 2 |

### TO DO (Assigned) — N tickets, P pts
…
### IN PROGRESS — N tickets, P pts
…
### IN REVIEW — N tickets, P pts
…
### DONE — N tickets, P pts (typically 0 at sprint start)
…

By member (workload view):

## Committed Scope by Member

### [[@First Last]] — N tickets, P pts (effective capacity: C pts)
| Key | Summary | Status | Points |
| :--- | :--- | :--- | --: |
| JIRA:PROJ-1234 | Summary | TO DO | 3 |

### Off-team
…
### Unassigned
…

Use JIRA:KEY on its own table cell so the Obsidian Jira plugin auto-links each row.

Phase 4 — Apply team rules

Compute the derived numbers the report depends on:

• Overhead-adjusted capacity per member = nominal_capacity × (1 - overhead_pct/100). For overhead members listed in _team-rules.md, surface both nominal and effective.
• In-review overhead identification — scan IN REVIEW issues; flag any whose summary matches a _team-rules.in_review_overhead.title_patterns entry. Tag these in the by-status table with a (overhead) suffix and a footnote: "Excluded from velocity; counted toward capacity."
• Wedge ticket detection — find the wedge ticket in the canvas (key matches _team-rules.wedge.ticket_key); record its starting points. Used by sprint-sos-report later to detect scope creep.
• Velocity-relevant points = committed - in_review_overhead_points. This is the number the team is actually expected to deliver.
• Carry-over capacity math — split velocity_relevant_points into carry_over_points and new_commit_points = velocity_relevant_points - carry_over_points. The headline numbers in the report should make both visible: a sprint that committed 60 pts of which 25 are carry-over has very different planning implications than 60 pts of fresh work. Surface carry-over as a percentage of velocity-relevant commit (carry_over_points / velocity_relevant_points).
• Carry-over WIP risk — count carry_over.in_progress + carry_over.in_review tickets. If this is > 30% of total committed tickets, the sprint starts already-WIP-saturated; flag for the council.

Phase 5 — Clarity-council

Unless --no-council, invoke clarity-council via Skill with the personas list. Pass:

• The Phase 3 markdown view (both by-status and by-member, with carry-over annotations)
• The Phase 4 derived numbers (effective capacity, velocity-relevant points, carry-over points + percentage, carry-over WIP risk)
• The Phase 2.5 carry-over set (full list with JIRA:KEY and previous-end status)
• The _sprint.md frontmatter (capacity, last_sprint_velocity, avg_velocity_last_3)
• Their assignment: "Produce three short markdown sections: ## Key Observations (3-7 bullets), ## Risks (3-7 bullets, each with severity High/Med/Low and a one-sentence mitigation), and ## Infographics (3-5 Mermaid charts that visualize the headline numbers). The statistics-expert weighs commitment vs velocity history and explicitly addresses carry-over: how much of the committed velocity is already-spoken-for, and what that implies for new-work throughput (with a prediction interval). The scrum-master weighs team load distribution, carry-over WIP risk (sprint starts WIP-saturated?), and re-planning signals. The product-owner weighs scope coherence, dependency surface, and whether carry-over items are still the right priorities or stale. The infographics-expert produces the chart block — see Required charts below. Strict rule: cite issue keys (JIRA:KEY format) for any specific claim — including every carry-over item the council references. No fluff."

Charts required (## Infographics section) {#charts-required-section}

The infographics-expert persona must produce at minimum these Mermaid charts, each with a one-line caption. (don't ship reports as numbers-only narratives when a chart would land it faster).

#	Chart	Type	Series
1	Capacity vs commit	Mermaid xychart-beta (bar)	Capacity (line/reference), gross committed, velocity-relevant, last-sprint velocity, 3-sprint avg velocity
2	Carry-over share of velocity-relevant commit	Mermaid pie showData	carry-over points vs new-commit points
3	Per-member workload (% of capacity)	Mermaid xychart-beta (bar)	one bar per assigned member, sorted desc; flag any >25% with a marker note in the caption
4	Status mix at sprint start	Mermaid pie showData	Done / In Review / In Progress / To Do points
5	Velocity trend	Mermaid xychart-beta (line)	S1, S2, S3 (assumed/actual), S4 commit (point), with a horizontal reference at capacity

Only skip a chart if the underlying data is genuinely empty (e.g. no carry-over → skip chart #2 with a note "no carry-over data"). Never skip silently. If the persona claims a chart can't be drawn, render the same data as a markdown table and label it "fallback (chart unavailable)."

If --no-council skips clarity-council entirely, the skill MUST still render the Infographics section directly via inline LLM rendering — the chart requirement is independent of the council orchestration.

If clarity-council is unavailable or --no-council, render a simpler ## Key Observations and ## Risks block from a direct LLM analysis using the same input — but flag in the console summary that the council was skipped.

Phase 6 — Render and write

Output path: {{output_root}}\reports\sprint-plan-{{YYYY-MM-DD}}.md (Pittsburgh local date). Create reports/ if missing.

Re-run semantics:

• Same-day re-run → overwrite today's sprint-plan-YYYY-MM-DD.md silently. The newer run reflects the latest snapshot data; the user expects this to "refresh today's report." No prompt.
• Different-day re-run → write a new dated file. Prior days' reports stay untouched on disk — they are the historical record of how the plan looked at that point in time.
• Symlink-style "latest" pointer → after writing, also update (overwrite) {{output_root}}\reports\sprint-plan-latest.md to be a single-line pointer file containing [[sprint-plan-{{YYYY-MM-DD}}]]. This gives the SM a stable wikilink target for dashboards and bases without chasing the date.

This per-day cadence pairs with sprint-snapshot's per-phase cadence: snapshot is what the board looked like at this phase, sprint-plan is how I interpreted the plan on this date — both are point-in-time records that shouldn't be silently overwritten across days. Within a day, however, the planning report just gets refreshed.

Template:

---
team: {{team}}
increment: {{inc}}
sprint: {{sprint}}
report_type: sprint-plan
generated: {{YYYY-MM-DD HH:mm}}
source_canvas: "[[start.canvas]]"
sprint_config: "[[_sprint]]"
team_rules: "[[../../_team-rules]]"
total_tickets: {{n}}
total_points: {{n}}
velocity_relevant_points: {{n}}
carry_over_points: {{n}}
new_commit_points: {{n}}
carry_over_pct: {{0.xx}}
capacity: {{n}}
prior_sprint_end_canvas: "[[../../Sprint {{prev_sprint}}/end.canvas]]"
council_personas: [{{persona list or "none"}}]
---
# Sprint {{sprint}} Plan — {{team}} (INC {{inc}})

> Captured from `start.canvas` at {{snapshot_at}}. Generated {{generated}}.
> Carry-over derived from `Sprint {{prev_sprint}}/end.canvas` ({{prev_end_snapshot_at_or_"unavailable"}}).

## Sprint at a glance

| Metric | Value |
| :--- | --: |
| Capacity | {{capacity}} pts |
| Committed | {{committed}} pts |
| Velocity-relevant (excl. in-review overhead) | {{velocity_relevant}} pts |
| ↳ Carry-over from Sprint {{prev_sprint}} | {{carry_over_points}} pts ({{carry_over_pct}}%) |
| ↳ New commit this sprint | {{new_commit_points}} pts |
| Last sprint velocity | {{last_velocity}} pts |
| 3-sprint avg velocity | {{avg_velocity}} pts |
| Tickets committed | {{n}} ({{carry_over_ticket_count}} carry-over 🔄) |
| Unassigned | {{n}} ({{n}} pts) |

{{capacity_warning_if_committed_>_avg_velocity_*_1.2}}

## Carry-over from Sprint {{prev_sprint}}

> All unclosed items from the previous sprint are assumed to carry into this one.

| | Key | Summary | Prev. status | Now | Owner | Pts |
| :-: | :--- | :--- | :--- | :--- | :--- | --: |
| 🔄 | JIRA:PROJ-1100 | … | IN REVIEW | IN REVIEW | [[@First Last]] | 2 |
| 🔄 | JIRA:PROJ-1107 | … | IN PROGRESS | TO DO (Assigned) | [[@First Last]] | 5 |
…

**Carry-over WIP risk:** {{carry_over_in_progress + carry_over_in_review}} of {{total_tickets}} tickets ({{xx%}}) start the sprint already-WIP. {{flag_if_>30%}}

**Stale-priority check:** the council has flagged carry-over items that may no longer be the right priority (see Risks).

{{Phase 3 by-status block}}

{{Phase 3 by-member block}}

## Wedge & Overhead

- Wedge ticket: `JIRA:{{wedge_key}}` ({{wedge_points}} pts reserved)
- Overhead members: {{list with effective vs nominal}}
- In-review overhead items (excluded from velocity): {{list}}

{{Phase 5 Infographics block — Mermaid charts per "Charts required" spec}}

{{Phase 5 Key Observations block}}

{{Phase 5 Risks block}}

## Next snapshots

This report covers the **start** snapshot. Recommended cadence:
- `/sprint-snapshot {{team}}` at end of each sprint week (auto-detects phase)
- `/sprint-sos-report {{team}}` at end of weeks 1, 2, 3
- `/sprint-review {{team}}` at sprint close

If extending the template with callouts, dataview blocks, or embeds, delegate to obsidian-markdown via Skill.

Phase 7 — Console summary

=== Aurora Sprint 2 (INC 28) — Sprint Plan ===
Source:           Sprint 2/start.canvas (snapshot_at 2026-04-01T09:14:00-04:00)
Carry-over base:  Sprint 1/end.canvas (snapshot_at 2026-03-31T17:42:00-04:00)
Tickets / Points: 24 / 62.5  (4 tickets / 11 pts carry-over 🔄)
Capacity:         80.8 (committed 62.5; velocity-relevant 47.5 after 15 pts in-review overhead)
Carry-over share: 11 / 47.5 = 23% of velocity-relevant commit
Carry-over WIP:   3 of 24 tickets start already-WIP (12%) — within tolerance
Council:          statistics-expert + scrum-master + product-owner + infographics-expert ✅
Charts rendered:  5 Mermaid blocks (capacity-vs-commit, carry-over share, per-member workload, status mix, velocity trend)
Saved:            [sprint-plan-2026-04-01.md](Scrum Teams/Aurora/Scrum 📅/INC 28/Sprint 2/reports/sprint-plan-2026-04-01.md)
                  [sprint-plan-latest.md] → updated pointer

If this is the second run today: Saved: refreshed sprint-plan-2026-04-01.md (silent overwrite — same-day re-run).

Rules

• Read-only. Read the canvas, the JSONL, the sprint config, and the team rules. Don't modify any of them. Don't call Jira directly — the canvas is the snapshot.
• Never fabricate ticket data. If a card's metadata is malformed, surface the parse failure in the console summary; don't invent values.
• Council citations are mandatory. Personas must reference JIRA:KEY for any claim about a specific ticket. Reject council output that fails this rule and re-prompt.
• Carry-over assumption is unconditional. All unclosed items from the previous sprint's end.canvas (or best-available fallback snapshot) are treated as carried into this sprint. The skill does not negotiate with the user about which items carried — that is already reflected in start.canvas. Surface, don't decide.
• Same-day re-runs overwrite silently; cross-day runs create new dated files. This is the opposite of sprint-snapshot's overwrite-prompt rule because the planning report is a daily refresh, not a phase-locked snapshot. Prior days' planning reports are historical record and never touched.
• The sprint-plan-latest.md pointer is the canonical wikilink target for dashboards and bases. Always update it on every run.
• Prefer the JSONL row over re-counting from the canvas for headline totals — it's the canonical record. Use canvas parsing only for the per-issue table.
• Wikilink team members only when the vault note exists. Same Glob("{{vault_root}}/🤼 Team/**/@*.md") rule as sprint-snapshot.
• Charts are mandatory. Every sprint-plan report MUST contain the ## Infographics section with the Mermaid charts spec'd in Charts required. This applies whether the council ran or not. Numbers-only narratives are a regression.
• _team-rules.md lookup search order: (1) {{output_root}}/_team-rules.md (sprint-level override, rare), (2) {{output_root}}/../_team-rules.md (INC-level, also rare), (3) {{vault_root}}/Scrum Teams/<Team>/_team-rules.md (canonical team-root location, where Pyrite's lives). Do not declare team-rules missing without searching all three.

Edge cases

• No start.canvas — prompt to run sprint-snapshot --phase start first; do not fall back to week 1 or invent a start state.
• No previous sprint end.canvas — fall back to week 3.canvas, then week 2.canvas, then week 1.canvas from the previous sprint folder. If none exist, set carry_over: unavailable in the frontmatter, render the report without a Carry-over section but with a > ⚠️ Carry-over could not be derived — previous sprint had no captured snapshots. callout near the top, and surface in the console summary. The council should be told carry-over data is unavailable so it doesn't hallucinate one.
• First sprint of a new INC (Sprint 1) with no prior INC — same as "no previous sprint" — set carry_over: not_applicable and skip the section entirely (no warning, this is expected).
• Carry-over ticket present in previous-end but not in current-start — surface as a console warning: "⚠️ JIRA:PROJ-1100 was unclosed at end of Sprint 1 but is not in Sprint 2 start.canvas. Confirm with PO this was intentional (de-scoped, moved to backlog) and not a planning oversight." Don't fail; record in the report's "Stale-priority check" footnote.
• Carry-over ticket re-estimated between sprints — use the start.canvas (current sprint) point value, not the previous-end value. Note the change in the carry-over table: prev: 3 pts → now: 5 pts.
• Same-day re-run — third+ run — same as the second: silent overwrite of today's file. The sprint-plan-latest.md pointer doesn't need re-updating (it already points to today) but rewrite it anyway for idempotency.
• Run on a day spanning a date boundary (after midnight) — Pittsburgh local date determines the filename. A run started 11:55 PM ET that finishes 12:05 AM ET writes to the date the run started — same convention daily-briefing uses, prevents off-by-one filenames.
• _team-rules.md missing — only declare missing after exhausting all three lookup paths (sprint folder, INC folder, team root Scrum Teams/<Team>/). The team-root location is canonical for Pyrite; sprint/INC overrides are rare. If genuinely missing across all three, prompt to bootstrap (per sprint-snapshot/REFERENCE.md). Run anyway with empty overhead/wedge if the user picks "Skip"; flag in the console that the report is less accurate.
• Wedge ticket key in _team-rules.md doesn't appear on the canvas — surface a warning ("Wedge ticket PROJ-9999 not in sprint — wedge accounting will be skipped this sprint"); continue.
• Council unavailable / --no-council — degrade to direct-LLM observations + risks; mark council_personas: [none] in the frontmatter so consumers can filter.
• Sprint with 0 committed points — render the report; the observations section will (correctly) flag it.
• Multi-team run is not supported in v1 — single team only. (Multi-team would loop the workflow per team and write one report per team. Add later if needed.)

Related skills

Skill	Use it for
sprint-snapshot	Produces the start.canvas this skill consumes. Run first if it's missing.
sprint-sos-report	Sibling — weekly comparison report. Reads the same _team-rules.md and snapshots.
sprint-review	Sibling — end-of-sprint stakeholder report. Reuses the same scaffolding.
clarity-council	Phase 5 delegates to it for the observations + risks analysis. statistics-expert is the load-bearing persona for capacity-vs-velocity reasoning; scrum-master for team-load and re-planning signals; product-owner for scope coherence. Add infographics-expert to the council when the report needs embedded visuals (carry-over Sankey, capacity-vs-commit bar, per-member workload small-multiple) — they consult statistics-expert for uncertainty rendering and produce the SVG/Mermaid that drops into the report body.
obsidian-canvas	Use if extending the report with embedded canvas snippets or sub-canvases.
obsidian-markdown	Use when extending the report template with callouts, dataview, embeds.
obsidian-vault	Use for batch wikilink verification (>15 names).
obsidian-bases	Use when the user wants a .base aggregating sprint plans across an INC (e.g. "show committed vs avg velocity for every Aurora sprint in INC 28").

Quality Loop

Before returning the artifact, evaluate it and refine if it falls short.

1. Generate the artifact via the workflow above.
2. Self-evaluate against these criteria:
   • Carry-over vs new-commit split is explicit and the numbers reconcile to total committed points
   • Capacity-vs-commitment is stated with the WIP-saturation risk called out when over capacity
   • Observations and risks come from the council pass, not filler
   • Output is date-stamped and the -latest pointer updated
3. Loop — if two or more criteria fail, revise and re-check.
4. Exit when all criteria pass, or after two refinement passes (then note which criteria still fall short).

Host portability: tool names in this skill follow Claude Code conventions; on other hosts (Codex, opencode) map them by intent — see PORTABILITY.md.

<!-- self-evolve:start -->

Self-Evolve Loop

This skill learns across invocations — the full contract is SELF-EVOLVE.md. Start: read the learnings journal — ~/.ink-and-agency/learnings/sprint-plan.md and/or the workspace-local .ink-and-agency/learnings/sprint-plan.md — if present, and apply its guidance. End: self-evaluate the results; optionally ask the user for feedback (never block on it); append signal-bearing learnings to the journal (user-global when the sandbox allows writing there, workspace-local otherwise); route skill-improvement ideas per the contract's tiers — edit the canonical source when one is present, never the plugin cache.

<!-- self-evolve:end -->