Agent-Skills.md

Agent Skills: Story Pipeline — Planning, Generation & Sprint Management

Turn a feature idea into INVEST-compliant user stories, epics, PRPs/PRDs, and sprint plans. Use when breaking down a feature for implementation or planning a sprint. Trigger on "write user stories", "break this into stories", "create a PRP", "plan the sprint", "story".

UncategorizedID: matteocervelli/llms/story

Repository

matteocervelli/llms
matteocervelliLicense: MIT
252

Install this agent skill to your local

pnpm dlx add-skill https://github.com/matteocervelli/llms/tree/HEAD/.codex/skills/story

Skill Files

Browse the full folder contents for story.

Download Skill

Loading file tree…

.codex/skills/story/SKILL.md

Skill Metadata

Name
story
Description
Turn a feature idea into INVEST-compliant user stories, epics, PRPs/PRDs, and sprint plans. Use when breaking down a feature for implementation or planning a sprint. Trigger on "write user stories", "break this into stories", "create a PRP", "plan the sprint", "story".

Story Pipeline — Planning, Generation & Sprint Management

Unified workflow from feature idea to ready-to-implement stories. Replaces user-story-generator, story-validator, sprint-planner, and technical-annotator.

TDD note: Do NOT use /story tests. Use /implementation directly — it has TDD built-in and generates tests from acceptance criteria with full codebase context. /story tests is archived: it produces generic stubs that conflict with implementation-generated tests.

Usage

/story                          # Auto-detect project, suggest next action
/story create                   # Feature description -> INVEST-compliant user stories
/story create --epic            # Feature too large for stories -> create EP-XXXX epic
/story create --prd             # Feature description -> PRD (aggregated stories)
/story decompose <EP-XXXX>      # Decompose an epic into child US-XXXX stories
/story prp <story-ids>          # Generate PRP from stories (invokes /prp-generator)
/story plan                     # Sprint/milestone planning from backlog
/story update                   # Create new stories from change request
/story sync                     # Push stories/epics to GitHub issues via gh CLI

Language

Always write in English. All story/epic YAML content, GitHub issue titles and bodies, acceptance criteria, and documentation must be in English. No exceptions — do not detect or adapt to project language.

Epic vs Story — quando usare quale

| Usa --epic quando... | Usa create (storia) quando... | | --------------------------------------------- | ---------------------------------------- | | La feature richiede >3 storie figlie | La feature si implementa in 1-2 sessioni | | Stima > 8 story points | Stima ≤ 8 story points | | Coinvolge nuovo modello dati + UI + notifiche | Tocca un'area già strutturata | | È un deliverable di bando o milestone | È un task di refinement |

Regola pratica: se mentre scrivi le acceptance criteria ti vengono 6+ punti, è un'epica.

Workflow

Step 1: Determine Mode

Parse $ARGUMENTS for explicit subcommand. If no arguments, detect project context:

PROJECT_INFO=$(bash "$HOME/.claude/skills/story/lib/project-detector.sh")

With no arguments:

  • If project has story YAML files -> show backlog summary, suggest validate/plan/implementation
  • If project has PRPs but no stories -> suggest /story create for next PRP
  • If new project -> suggest /story create to start

Step 2: Route to Subcommand

Subcommand: create

Interactive feature-to-stories workflow.

Phase 0: Epic check (NUOVO)

Prima di generare storie, valuta se la feature è troppo grande:

  • Stimi >8 punti totali? → --epic obbligatorio
  • Richiede >3 sotto-funzionalità distinte? → --epic obbligatorio
  • Nuovo modello dati + UI + notifiche + auth? → quasi certamente --epic

Se l'utente non ha passato --epic ma la feature lo richiede, proponi di creare un'epica invece. Non generare storie impossibili da stimare.

Phase 1: Feature Extraction

Ask the user these questions in English. Skip if answers are obvious from context.

  1. What does this feature do? (one sentence)
  2. Who benefits? (persona: operator, fatturatore, client-pmi, employee-pmi, admin…)
  3. Why does it matter? (business value, pain it resolves)
  4. What does success look like? (measurable outcome)
  5. What constraints exist? (technical, time, dependencies on existing system)

Always add: Current system state (AS-IS) — what already exists, what is missing. Without this, context is insufficient for implementation.

Phase 1b: Epic Mode (--epic)

Quando --epic è passato, genera un'epica EP-XXXX invece di storie:

  • Leggi templates/epic-yaml.md per lo schema
  • Incrementa .epic_counter (separato da .story_counter)
  • Compila obbligatoriamente: context, problem, personas, goal, success_metrics, current_state, sub_stories, technical_dependencies
  • Il campo sub_stories è una lista di titoli delle storie figlie — verranno create da /story decompose
  • File: stories/yaml-source/EP-XXXX.yaml
  • GitHub issue body: includi il blocco > Questa è un'epica — va decomposta prima dell'implementazione in cima, poi tutte le sezioni in italiano con sub_stories come checklist

Phase 2: Story Decomposition

From the feature, generate 2-6 user stories following INVEST criteria:

  • Each story gets an ID: US-XXXX (increment from .story_counter in project root, create if absent)
  • Format: Read templates/story-yaml.md for the YAML schema
  • Each story MUST have at least 2 acceptance criteria in Given/When/Then format
  • Story points: Fibonacci (1, 2, 3, 5, 8). If >8, split the story
  • Include context field with: da dove viene questa storia (epica parent, bando, discovery), riferimenti a documenti, stato AS-IS del sistema. Senza contesto il YAML è inutile.
  • Se la storia ha un'epica parent, imposta parent_epic: EP-XXXX e aggiorna child_stories nell'epica

Phase 3: Quick Validation

For each generated story, check INVEST inline (no external scripts):

| Criterion | Pass if... | | ----------- | -------------------------------------- | | Independent | No circular deps, minimal blocking | | Negotiable | Describes outcome, not implementation | | Valuable | Has clear "so that" benefit | | Estimable | Has story points + acceptance criteria | | Small | <=8 points | | Testable | Has Given/When/Then criteria |

Fix any failures before presenting to user.

Phase 4: Write Story Files

  • YAML source: stories/yaml-source/US-XXXX.yaml
  • Markdown doc: stories/generated-docs/US-XXXX.md

Create stories/ directories if they don't exist in the project.

Phase 5: Present Summary

Show table of generated stories with: ID, title, points, persona, acceptance criteria count. Ask user to approve, modify, or regenerate.

PRD Mode (--prd)

When --prd flag is present, wrap stories into a Product Requirements Document:

  • Read templates/prd.md for the PRD format
  • PRD aggregates related stories into a product-level document
  • Includes: executive summary, user personas, story map, success metrics, timeline
  • Save to: docs/development/prds/PRD-XXXX.md

Subcommand: decompose

Decompone un'epica EP-XXXX nelle sue storie figlie US-XXXX.

Process

  1. Leggi stories/yaml-source/EP-XXXX.yaml (ID passato come argomento)
  2. Per ogni voce in sub_stories, genera una storia US-XXXX:
    • Imposta parent_epic: EP-XXXX
    • Imposta blocked_by in base alle dipendenze logiche tra le storie figlie
    • Copia context dall'epica e aggiungi la specifica della singola storia
    • Compila acceptance_criteria (Given/When/Then) specifici per questa storia
    • Stima story_points (Fibonacci 1-8)
  3. Scrivi i file stories/yaml-source/US-XXXX.yaml
  4. Aggiorna il campo child_stories nell'epica con i nuovi ID
  5. Aggiorna il campo status dell'epica a decomposed
  6. Presenta la tabella delle storie figlie generate con ID, titolo, punti, dipendenze
  7. Chiedi conferma prima di creare le GitHub issue
  8. Dopo aver creato le issue figlie, chiudi l'issue epica su GitHub: 
    gh issue comment <epic_issue_number> --body "Decomposed into: US-XXXX #NNN, US-XXXX #NNN, ..."
gh issue close <epic_issue_number> --reason "not planned"
    Rationale: l'epica è un contenitore di planning, non un work item. Una volta decomposta, il lavoro reale vive nelle storie figlie. L'issue epica rimane visibile (non cancellata) con il commento che linka le figlie.

GitHub issue per storie figlie

Usa il titolo formato: [MILESTONE|NN] [PP] US-XXXX feat: titolo Nel body: includi link all'epica parent (Part of EP-XXXX #NNN) e i criteri Given/When/Then.

Subcommand: prp

Bridge stories to PRP generation.

Process

  1. Load story YAML files from $ARGUMENTS
  2. Read templates/prp-bridge.md for mapping rules
  3. Compose PRP input:
    • Stories -> Requirements section (acceptance criteria become requirements)
    • Story points -> Complexity assessment
    • Personas -> User context
    • Dependencies -> Architecture constraints
  4. Invoke /prp-generator skill with composed input
  5. PRP saved to project's PRP directory (detected by project-detector.sh)

Subcommand: plan

Sprint/milestone planning from story backlog.

Process

  1. Scan stories/yaml-source/ for stories with status: backlog or ready
  2. Show eligible stories sorted by priority (critical > high > medium > low), then by points
  3. Ask for sprint parameters:
    • Capacity (story points, default: 40)
    • Duration (default: 2 weeks)
    • Buffer % (default: 20%)
  4. Greedy-fit stories into capacity (priority order, skip if story exceeds remaining)
  5. Check dependency constraints (blocked_by must be in same or earlier sprint)
  6. Present sprint plan using templates/sprint-report.md format
  7. On approval:
    • Update story YAML status -> sprint: "Sprint YYYY-NN"
    • Optionally create GitHub milestone via gh api

Subcommand: update

Create new stories from a change request or user feedback.

Process

  1. Ask user: what changed? (new requirement, bug found, scope change, feedback)
  2. Load existing stories from stories/yaml-source/
  3. Generate new stories or modify existing ones
  4. Validate INVEST inline
  5. Write updated YAML + Markdown

Subcommand: sync

Push stories and epics to GitHub issues.

Process

  1. Load all YAML files from stories/yaml-source/ (both EP-XXXX and US-XXXX)
  2. For each file without github_issue:
    • Epic: gh issue create --title "[MILESTONE|NN] [P0] EP-XXXX epica: titolo" --body <body con header epica + sub_stories checklist>
    • Story: gh issue create --title "[MILESTONE|NN] [PP] US-XXXX feat: titolo" --body <body con AC Given/When/Then + link parent epic>
  3. Update YAML with github_issue: <number>
  4. For files with existing issues, update body if content changed
  5. For stories with parent_epic: add comment linking to parent issue

Template Locations

| Template | Purpose | File | | ----------------- | ------------------------------ | ---------------------------- | | Epic YAML format | Schema per file epica EP-XXXX | templates/epic-yaml.md | | Story YAML format | Schema per file storia US-XXXX | templates/story-yaml.md | | PRP bridge | Story -> PRP section mapping | templates/prp-bridge.md | | PRD format | Product requirements document | templates/prd.md | | Sprint report | Sprint plan output | templates/sprint-report.md | | GitHub issue | Issue body template | templates/github-issue.md | | GitHub issue | Issue body template | templates/github-issue.md |

Progressive Disclosure

  1. Start lean — show story summaries, not full YAML dumps
  2. Read templates on demand — use Read tool, don't memorize content
  3. User drives depth — "show details", "show YAML", "show criteria" trigger deeper output
  4. One subcommand at a time — don't chain create+tests+prp unless user asks for full pipeline