rcode-sprint-planning

Generate sprint-status.yaml from epic files and capacity inputs.

2|1|Updated Apr 10, 2026
One-click install
npx skills add https://github.com/hanzlahabib/rcode --skill rcode-sprint-planning
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: rcode-sprint-planning
Source: https://github.com/hanzlahabib/rcode/tree/main/rcode/skills/actions/4-implementation/rcode-sprint-planning
Command: npx skills add https://github.com/hanzlahabib/rcode --skill rcode-sprint-planning

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

It removes the manual work of turning epics into a valid sprint plan, while enforcing capacity checks so stories are not committed without enough team data.

Core Features & Use Cases

  • Capacity-Gated Planning: Stops and asks for dev count, PTO, meetings, and velocity before committing any stories.
  • Epic and Story Parsing: Reads epic files, extracts all epics and stories, and preserves existing status values without downgrading work.
  • Sprint Status Generation: Writes a complete sprint-status.yaml with ordered epic, story, and retrospective entries plus validation rules.
  • Use Case: A Scrum Master needs to sequence the next sprint from project epics and produce a reliable status file for tracking progress across implementation workflows.

Quick Start

Use the rcode-sprint-planning skill to read the epic files, ask for capacity numbers, and generate the next sprint-status.yaml.

Frequently Asked Questions about rcode-sprint-planning

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I generate a sprint plan from epic files while checking team capacity?

Sprint plan generation from epic files validates team capacity inputs, blocking story commitment until developer count, PTO, meetings, and velocity are confirmed. It then writes a sprint-status.yaml file with ordered epics and stories.

What is capacity-gated sprint planning and how does it protect against overcommitment?

Capacity-gated sprint planning stops the sequencing process to ask for dev count, PTO, meetings, and velocity before committing any stories. This prevents sprint overcommitment by enforcing strict capacity validation against available team data.

How do I preserve existing story statuses when regenerating a sprint-status.yaml file?

Preserving existing story statuses during sprint-status.yaml regeneration is handled by parsing epic files and extracting current status values without downgrading work. It synchronizes state after file updates to maintain progress tracking accuracy.

Can I use this sprint planning approach for Scrum Master workflows that need retrospective tracking?

Scrum Master workflows are fully supported, sequencing stories while tracking epics, stories, and retrospectives. It generates a complete sprint-status.yaml with ordered retrospective entries alongside epic and story validation rules.

Does sprint status tracking require full epic discovery before generating the YAML output?

Full epic discovery is required before generating sprint-status.yaml output. The capacity validation blocks story commitment until all epics are parsed, ensuring complete sprint plan generation with accurate status tracking and validation rules.

Why does my sprint planning workflow block before committing stories to the sprint?

Sprint planning blocks before committing stories because capacity validation requires dev count, PTO, meetings, and velocity data upfront. This capacity-gated approach ensures stories are never committed without sufficient team availability data.