Sprint plan

Skill srg-sphynx/MDForge/Sources/MDForge/Resources/SkillLibrary/Development/sprint-plan

Capacity-gated sprint planning — runs capacity math, carry-over check, and a definition-of-ready gate before committing scope. Usage: /sprint-plan <goal> [capacity]From its SKILL.md

Install

npx -y skills add srg-sphynx/MDForge --skill sprint-plan

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.5 KB, 764 tokens by cl100k_base, as published. Nobody here has run it

/sprint-plan

Create a sprint plan for $ARGUMENTS with explicit capacity math, a carry-over check, and a definition-of-ready gate. The first token(s) of $ARGUMENTS are the sprint goal; a trailing number is treated as team capacity (story points or person-days). If no capacity is given, compute it in Phase 1 — never invent it.

Usage

/sprint-plan <goal> [capacity]
# e.g. /sprint-plan "Checkout v2 ready for beta" 34

Phase 1 — Capacity Math (do the arithmetic, show it)

Raw capacity = team size × working days in sprint × focus factor (default 0.7; ask if unknown)
Deductions — subtract, explicitly and line by line: holidays/PTO, on-call/support rotation, ceremonies (~10%), known interrupts
Velocity cross-check — compare against the rolling average of the last 3 sprints' completed (not committed) points. If computed capacity exceeds trailing velocity by >15%, plan to trailing velocity and say so.

Output a small table: raw → deductions → net capacity → trailing velocity → planning number.

Phase 2 — Carry-Over Check (before adding anything new)

List every item carried over from the last sprint (not Done at sprint close)
Re-estimate remaining effort — never carry the original estimate
Carry-over consumes capacity first; new scope only gets what is left
If carry-over exceeds ~30% of capacity, flag it as a systemic over-commitment signal and recommend a smaller commitment this sprint, not a bigger push

Phase 3 — Definition-of-Ready Gate (per story)

A story may enter the committed scope only if all of these hold — otherwise it goes to "needs refinement", not the sprint:

User story has a clear actor, action, and outcome (INVEST-compliant)
Acceptance criteria written and testable
Estimated by the team (not by the planner alone)
Dependencies identified and either resolved or scheduled
Small enough to finish within the sprint (split if not)

Generate INVEST-checked stories from an epic with:

python3 product-team/agile-product-owner/skills/agile-product-owner/scripts/user_story_generator.py

Phase 4 — Output Structure

Sprint goal — one sentence; everything committed must serve it
Capacity table — from Phase 1
Carry-over — from Phase 2, listed first in committed scope
Committed scope — stories that passed the DoR gate, summing to ≤ planning number
Stretch scope — clearly separated; pulled only if committed scope finishes
Risks and dependencies — with named owners
DoR exceptions — empty if the gate was honored; otherwise justify each

Repo Assets (verified paths)

Skill: product-team/agile-product-owner/skills/agile-product-owner/SKILL.md
Sprint planning template: product-team/agile-product-owner/skills/agile-product-owner/assets/sprint_planning_template.md
Sprint planning guide: product-team/agile-product-owner/skills/agile-product-owner/references/sprint-planning-guide.md
Story generator: product-team/agile-product-owner/skills/agile-product-owner/scripts/user_story_generator.py

/sprint-health — mid-sprint health check
/user-story — single-story generation with INVEST checks

What ships with it

Read from the repository

Just SKILL.md. No reference files, no scripts.