| name | sprint-plan |
| description | Convert the start-of-sprint canvas into a planning markdown report — sprint goal summary, committed scope, capacity vs commitment (split into carry-over from previous sprint vs new commit), key observations, and risks. Assumes all unclosed items from the previous sprint's end snapshot are carried into this sprint and surfaces them as a dedicated section with WIP-saturation risk. Reuses sprint-snapshot's `_sprint.md`, `_team-rules.md`, current `start.canvas`, and previous sprint's `end.canvas`. Auto-runs a clarity-council session (statistics-expert + scrum-master + product-owner) for the observations/risks block. Output is date-stamped (`sprint-plan-YYYY-MM-DD.md`) — same-day re-runs silently refresh today's file, prior days are preserved as historical record; a `sprint-plan-latest.md` pointer always wikilinks the newest. Use when user says "sprint plan", "sprint planning report", "convert sprint plan to markdown", or invokes /sprint-plan. |
| related-agents | ["scrum-master","product-manager"] |
| related-skills | ["sprint-snapshot","clarity-council"] |
| loop-eligible | false |
| recurrence-hint | on-demand |
| allowed-tools | ["Read","Write","Edit","Glob","Bash","AskUserQuestion","Skill"] |
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
- Look for
{{output_root}}\start.canvas.
- If missing,
AskUserQuestion: Run /sprint-snapshot --phase start now (recommended) / Pick a different phase canvas / Cancel. Don't fabricate.
- 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).
- 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.
- 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
- 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.
- Parse issue cards from the previous-sprint canvas the same way as
start.canvas (key, status, points).
- 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.
- Sub-classify carry-over by previous-sprint end-status:
carry_over.in_progress — was IN PROGRESS at previous end; resume work, expect faster closecarry_over.in_review — was IN REVIEW at previous end; should close early this sprintcarry_over.todo — was TO DO at previous end; full sprint of work still ahead
- 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"). |
