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. See feedback memory: always-add-charts for the rationale (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 — see the always-add-charts feedback memory.
• _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. See reference memory.

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").