@hanzlaa/rcode 3.6.16 → 4.1.0

package/rcode/skills/actions/4-implementation/rcode-scaffold-project/SKILL.md

@@ -0,0 +1,91 @@
+---
+name: rcode-scaffold-project
+internal: true
+description: >
+  Scaffold a new project for rcode users using the official rcode template repo.
+  Activates when the user says "scaffold project", "create project", "new project",
+  "initialize project", "setup new project", "scaffold from template", "create from template",
+  "rcode new project", or "start a new rcode project". Do NOT use for generating
+  project context files (use rcode-generate-project-context) or cloning websites
+  (use rcode-clone-website).
+triggers:
+  - "scaffold project"
+  - "create project"
+  - "new project"
+  - "initialize project"
+  - "setup new project"
+  - "scaffold from template"
+  - "create from template"
+  - "rcode new project"
+  - "start a new rcode project"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Workflow
+
+
+# Scaffold Project from rcode Template
+
+## Overview
+
+This skill bootstraps a new rcode project by cloning the official rcode template
+repository (`https://github.com/rcode-om/template`) into a target directory.
+
+It always clones fresh from GitHub — nothing is stored locally — so if the template
+is updated, the next scaffold automatically picks up the latest version.
+
+The workflow enforces safety: it never overwrites an existing non-empty directory
+without explicit user consent.
+
+## On Activation
+
+Load config from `{project-root}/.rcode/config.json` and resolve:
+- `{user_name}` for greeting
+- `{communication_language}` for all agent communication
+
+Greet the user as `{user_name}` in `{communication_language}`.
+
+Then proceed to `./steps/step-01-target.md`.
+
+## Stages
+
+| # | Stage | Purpose | File |
+|---|-------|---------|------|
+| 1 | Target Directory | Get + validate destination path | `steps/step-01-target.md` |
+| 2 | Safety Check | Verify folder is empty or get new path | `steps/step-02-safety.md` |
+| 3 | Clone | Clone template repo fresh from GitHub | `steps/step-03-clone.md` |
+| 4 | Post-Setup | Rename, init git, suggest next steps | `steps/step-04-post-setup.md` |
+
+## Design Decisions
+
+- **Always clone fresh** — never cache template locally. Template updates are free.
+- **No local template copy** — single source of truth is `https://github.com/rcode-om/template`.
+- **Safety first** — never touch a non-empty directory without user approval.
+- **Minimal assumptions** — ask before acting on any ambiguity.
+
+## Output Format
+
+- New project directory scaffolded at the specified path
+- Fresh git history (template history stripped, new `git init` applied)
+- `.rcode/config.json` initialized with project name and user preferences
+- Console summary: path created, files scaffolded, next steps
+
+## Examples
+
+### Happy Path
+**Input:** "scaffold a new project called my-app"
+**Expected:** Ask for target path (default: `./my-app`), verify empty, clone template, strip git history, init fresh repo, summarize.
+
+### Edge Case: Non-empty Directory
+**Input:** Target directory already has files
+**Expected:** "This folder isn't empty. Should I create a new folder `my-app-1` instead, or would you like to empty it first? (I won't delete anything without your go-ahead.)"
+
+### Edge Case: No Name Given
+**Input:** "scaffold project"
+**Expected:** Ask for project name before proceeding.
+
+### Negative Test
+**Input:** "scaffold my existing repo" (existing non-empty dir provided)
+**Expected:** Safety check triggers. Never overwrites. Offers alternatives.

package/rcode/skills/actions/4-implementation/rcode-scaffold-project/steps/step-03-clone.md

@@ -0,0 +1,50 @@
+# Step 3: Clone Template
+
+## Goal
+Clone the official rcode template repository fresh from GitHub into `{target_path}`.
+
+## Template Source
+```
+https://github.com/rcode-om/template
+```
+
+This is the single source of truth. Never use a cached local copy.
+
+## Execution
+
+Run the following commands in sequence:
+
+```bash
+# 1. Clone the template repo
+git clone https://github.com/rcode-om/template "{target_path}"
+
+# 2. Remove template's git history (fresh start for the new project)
+rm -rf "{target_path}/.git"
+
+# 3. Initialize a clean git repo
+cd "{target_path}" && git init
+
+# 4. Stage everything
+git add .
+
+# 5. Initial commit
+git commit -m "chore: scaffold from rcode template"
+```
+
+## Error Handling
+
+### Clone fails (network / auth)
+- Report: "Couldn't reach GitHub. Please check your internet connection or GitHub access, then tell me to try again."
+- Do NOT retry automatically.
+
+### git not available
+- Report: "Git isn't installed or not in PATH. Please install git and try again."
+
+## Progress Updates
+Narrate each step to the user as it runs:
+- "Cloning from rcode-om/template..."
+- "Stripping template history..."
+- "Initializing fresh git repo..."
+- "Done! Proceeding to post-setup..."
+
+Then proceed to `step-04-post-setup.md`.

package/rcode/skills/actions/4-implementation/rcode-scaffold-project/steps/step-04-post-setup.md

@@ -0,0 +1,44 @@
+# Step 4: Post-Setup
+
+## Goal
+Finalize the scaffolded project and guide the user on next steps.
+
+## Actions
+
+### 1. Rename placeholders (if template has them)
+- Check if template has a placeholder project name (e.g., `my-app`, `project-name`, `template` in package.json, README, etc.)
+- If found: offer to replace with `{project_name}` automatically.
+- Ask: "I found placeholder names in package.json and README.md. Want me to replace them with `{project_name}`?"
+- Only replace if user confirms.
+
+### 2. Install dependencies (if applicable)
+- Check if `package.json` exists.
+- If yes, ask: "Should I run `pnpm install` to install dependencies?"
+- Use **pnpm** always (never npm or yarn).
+- Run only if user confirms.
+
+### 3. Summary
+Print a clean summary:
+
+```
+✅ Project scaffolded successfully!
+
+📁 Location:  {target_path}
+📦 Template:  github.com/rcode-om/template (latest)
+🔀 Git:       Fresh repo initialized with initial commit
+
+Next steps:
+  cd {target_path}
+  pnpm install       ← if not done already
+  pnpm dev           ← to start development server
+```
+
+### 4. Suggest next rcode skills
+Offer relevant follow-up actions:
+> "What would you like to do next?
+> - **Generate project context** → `rcode-generate-project-context`
+> - **Create a PRD** → `rcode-create-prd`
+> - **Set up architecture** → `rcode-create-architecture`"
+
+## Done
+Skill execution complete.

package/rcode/skills/actions/4-implementation/rcode-source-truth/SKILL.md

@@ -0,0 +1,79 @@
+---
+name: rcode-source-truth
+internal: true
+description: Cite official documentation before writing or recommending any framework, library, or API code.
+triggers:
+  - "cite the docs"
+  - "official source"
+  - "verify the api"
+  - "what does the doc say"
+  - "rtfm"
+  - "version specific"
+  - "from the source"
+  - "source-driven"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+Training data goes stale. APIs change between major versions. This skill forces a doc-fetch step before any code that uses a third-party API, so the recommendation is grounded in the version actually installed in this project, not in what was true two years ago.
+
+## Workflow
+
+1. **Detect the version** of the relevant library from `package.json`, `pyproject.toml`, `Cargo.toml`, or a similar manifest.
+2. **Fetch the doc page** for the API in question — preference order:
+   1. Local `node_modules/<lib>/README.md` and `.d.ts` typings (most authoritative for what's installed)
+   2. Upstream docs site for the matching version (e.g. `https://nextjs.org/docs/16/...`)
+   3. The library's GitHub release notes for the major version
+3. **Quote the version-specific shape** in the output. Include the source URL or file path.
+4. **Compare to project usage.** If the project is using a deprecated pattern, flag it but don't auto-rewrite — call it out and let the user decide.
+5. **Write code** referencing only what the doc shows. No "I think this method is called X" without confirmation.
+6. **Note the doc source in the commit message** when the implementation depends on a specific API version (e.g. `feat(api): use Next.js 16 unstable_after — see https://...`).
+
+## Hard-listed sources for the rcode-default stack
+
+| Layer | Authoritative source |
+|---|---|
+| Next.js | `https://nextjs.org/docs/<version>/` |
+| React | `https://react.dev/reference/react` |
+| Strapi | `https://docs.strapi.io/` (and local `node_modules/@strapi/`) |
+| Postgres | `https://www.postgresql.org/docs/<version>/` |
+| Three.js | `https://threejs.org/docs/` |
+| Sentry | `https://docs.sentry.io/platforms/javascript/` |
+| Temporal | `https://docs.temporal.io/` |
+| Helm / K8s | `https://helm.sh/docs/` and `https://kubernetes.io/docs/` |
+
+For other libraries: fetch the readme from `node_modules/<lib>/`. If the doc returns a 404 for the version you need, say so plainly — don't fabricate.
+
+## Output Format
+
+```
+Library: <name> @ <version>  (from package.json)
+Source consulted: <URL or file path>
+Relevant API shape (verbatim):
+  <copy-pasted from doc>
+
+Project usage check:
+  ✓ in line with v<X> docs
+  ⚠ uses deprecated <Y>; replace with <Z>
+
+Recommendation:
+  <code grounded in the source>
+```
+
+Do NOT include: API names you did not see in the doc; "this is probably how it works"; recommendations for a version different from what's installed.
+
+## Examples
+
+**Happy path** — "Add a Next.js Server Action for the contact form" → check `package.json` (`next: 16.1.6`) → fetch `https://nextjs.org/docs/16/app/building-your-application/data-fetching/server-actions-and-mutations` → quote the `'use server'` directive shape → write the action.
+
+**Edge case — deprecated pattern** — Project is on React 19 but the codebase still uses `React.FC<>`. Flag it ("React.FC is discouraged in this project per CLAUDE.md") and recommend the function-component form, but don't auto-rewrite without permission.
+
+**Negative — guessing** — "I think Strapi's content-type API uses `lifecycles.beforeCreate`". STOP. Fetch the actual Strapi 5 docs first. Don't ship code based on a half-remembered API.
+
+## Memory Bank Hooks
+
+- **Reads:** `.rcode/memory/project/stack.md` (versions table) and `package.json`
+- **Writes:** when a non-obvious version-specific API is used, append the source link to `.rcode/memory/project/decisions.md`

package/rcode/skills/actions/4-implementation/rcode-sprint-planning/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: rcode-sprint-planning
+internal: true
+description: >
+  Generate or update a sprint plan that sequences stories for dev execution.
+  Activates when the user says "plan the sprint", "create sprint plan", "run
+  sprint planning", "sequence the next sprint", or "generate sprint N plan".
+  Do NOT use for epic breakdown (use rcode-create-epics-and-stories) or
+  status reporting (use rcode-sprint-status).
+triggers:
+  # English
+  - "plan the sprint"
+  - "create sprint plan"
+  - "run sprint planning"
+  - "sequence the next sprint"
+  - "generate sprint plan"
+  - "schedule the sprint"
+  # Roman Urdu / Hindi
+  - "sprint plan karo"
+  - "sprint banao"
+  - "agla sprint plan karo"
+  # Arabic native
+  - "خطّط السباق"
+  - "خطط السبرنت"
+  - "أنشئ خطة السباق"
+  - "السباق التالي"
+  - "جدولة السبرنت"
+user-invocable: true
+---
+@.rcode/references/karpathy-guidelines.md
+
+
+## Overview
+
+Generate or update a sprint plan that sequences stories for dev execution.
+
+## Workflow
+
+Follow the instructions in ./workflow.md.
+
+## Output Format
+
+- Output: .rcode/phases/{phase}/sprint-{N}.md
+- Fixed structure: Sprint Goal (one sentence) | Assumptions | Duration | Stories (with owners) | Capacity Used/Available | Risks | Definition of Done
+- Stories ranked by priority from epics.md
+- Leave 20% capacity buffer
+- Do NOT commit to stories without explicit owners
+- Sprint Goal must be one verifiable sentence — if it cannot be verified at sprint end without interpretation, rewrite it
+- `Assumptions` block required: list capacity assumptions, any known blockers assumed absent, any dependencies assumed resolved
+
+## Examples
+
+### Happy Path
+**Input:** "Plan the next 2-week sprint"
+**Expected behavior:** Read epics.md, ask team capacity, select stories fitting capacity with 20% buffer, assign owners, produce sprint file.
+
+### Edge Case: No Capacity Info
+**Input:** "Plan the sprint"
+**Expected behavior:** Ask: "How many devs, any PTO, any known meetings? I need capacity numbers before committing to stories."
+
+### Negative Example: Fabricated Capacity
+**Input:** "Plan the sprint" (no prior capacity info, no `mode: yolo`, no `--auto`)
+**Expected behavior:** DO NOT assume "1 senior FT, 30 pts/week" or any other capacity. DO NOT write `sprint-N.md` until the user provides numeric answers for devs/PTO/velocity. If the user resists, point them at the two sanctioned bypass paths (`.rcode/config.yaml` → `mode: yolo` or `/rcode-do --auto`). See `../../_shared/no-autonomous-bypass.md`.

package/rcode/skills/actions/4-implementation/rcode-sprint-planning/checklist.md

@@ -0,0 +1,43 @@
+# Sprint Planning Validation Checklist
+
+## Capacity Gate (BLOCKING — must pass before any story is committed)
+
+- [ ] Number of devs on the sprint is a concrete integer provided by the user
+- [ ] PTO / days off is accounted for (hours or days, explicit)
+- [ ] Known meetings / interrupt load is estimated (hours/week)
+- [ ] Velocity is either (a) provided by the user, or (b) pulled from prior sprint retrospective
+- [ ] 20% buffer is applied to the resulting capacity
+
+If any of the above is missing and the session is NOT running with `.rcode/config.yaml` `mode: yolo` or `/rcode-do --auto`, the workflow MUST halt and ask the user — never fabricate numbers.
+
+## Core Validation
+
+### Complete Coverage Check
+
+- [ ] Every epic found in epic\*.md files appears in sprint-status.yaml
+- [ ] Every story found in epic\*.md files appears in sprint-status.yaml
+- [ ] Every epic has a corresponding retrospective entry
+- [ ] No items in sprint-status.yaml that don't exist in epic files
+
+### Parsing Verification
+
+Compare epic files against generated sprint-status.yaml:
+
+```
+Epic Files Contains:                Sprint Status Contains:
+✓ Epic 1                            ✓ epic-1: [status]
+  ✓ Story 1.1: User Auth              ✓ 1-1-user-auth: [status]
+  ✓ Story 1.2: Account Mgmt           ✓ 1-2-account-mgmt: [status]
+  ✓ Story 1.3: Plant Naming           ✓ 1-3-plant-naming: [status]
+                                      ✓ epic-1-retrospective: [status]
+✓ Epic 2                            ✓ epic-2: [status]
+  ✓ Story 2.1: Personality Model      ✓ 2-1-personality-model: [status]
+  ✓ Story 2.2: Chat Interface         ✓ 2-2-chat-interface: [status]
+                                      ✓ epic-2-retrospective: [status]
+```
+
+### Final Check
+
+- [ ] Total count of epics matches
+- [ ] Total count of stories matches
+- [ ] All items are in the expected order (epic, stories, retrospective)

package/rcode/skills/actions/4-implementation/rcode-sprint-planning/workflow.md

@@ -0,0 +1,296 @@
+# Sprint Planning Workflow
+
+**Goal:** Generate sprint status tracking from epics, detecting current story statuses and building a complete sprint-status.yaml file.
+
+**Your Role:** You are a Scrum Master generating and maintaining sprint tracking. Parse epic files, detect story statuses, and produce a structured sprint-status.yaml.
+
+## State-sync rule (NO EXCEPTIONS)
+
+After this workflow writes any `.planning/` artifact (ROADMAP.md, epics.md, sprint-*.md, SUMMARY.md, etc.) or updates phase/story status:
+
+```bash
+node .rcode/bin/rcode-tools.cjs state sync --from-disk
+```
+
+This keeps `.rcode/state.json` in sync with disk — `/rcode-progress`, `/rcode-status`, and `/rcode-execute` all read state.json. Skipping the sync silently drifts them. See `../../_shared/state-sync-rule.md`.
+
+---
+
+---
+
+## CRITICAL RULES (NO EXCEPTIONS)
+
+- ⏸️ **ALWAYS** halt for capacity input (devs, PTO, meetings, velocity) before committing stories to the sprint. Per `SKILL.md` Edge Cases, the skill must ask: *"How many devs, any PTO, any known meetings? I need capacity numbers before committing to stories."*
+- 🚫 **NEVER** fabricate capacity numbers (e.g. *"1 senior FT, 30 pts/week"*) when the user has not provided them.
+- 🚷 **NEVER** invent an "autonomous mode" or any self-declared bypass. The only sanctioned bypass paths are `.rcode/config.yaml` → `mode: yolo` or `/rcode-do --auto`. See `../../_shared/no-autonomous-bypass.md` for the full rule and correct response pattern.
+
+---
+
+## INITIALIZATION
+
+### Configuration Loading
+
+Load config from `{project-root}/.rcode/config.json` and resolve:
+
+- `project_name`, `user_name`
+- `communication_language`, `document_output_language`
+- `implementation_artifacts`
+- `planning_artifacts`
+- `date` as system-generated current datetime
+- YOU MUST ALWAYS SPEAK OUTPUT in your Agent communication style with the config `{communication_language}`
+
+### Paths
+
+- `tracking_system` = `file-system`
+- `project_key` = `NOKEY`
+- `story_location` = `{implementation_artifacts}`
+- `story_location_absolute` = `{implementation_artifacts}`
+- `epics_location` = `{planning_artifacts}`
+- `epics_pattern` = `*epic*.md`
+- `status_file` = `{implementation_artifacts}/sprint-status.yaml`
+
+### Input Files
+
+| Input | Path | Load Strategy |
+|-------|------|---------------|
+| Epics | `{planning_artifacts}/*epic*.md` (whole) or `{planning_artifacts}/*epic*/*.md` (sharded) | FULL_LOAD |
+
+### Context
+
+- `project_context` = `**/project-context.md` (load if exists)
+
+---
+
+## EXECUTION
+
+### Document Discovery - Full Epic Loading
+
+**Strategy**: Sprint planning needs ALL epics and stories to build complete status tracking.
+
+**Epic Discovery Process:**
+
+1. **Search for whole document first** - Look for `epics.md`, `rcode-epics.md`, or any `*epic*.md` file
+2. **Check for sharded version** - If whole document not found, look for `epics/index.md`
+3. **If sharded version found**:
+   - Read `index.md` to understand the document structure
+   - Read ALL epic section files listed in the index (e.g., `epic-1.md`, `epic-2.md`, etc.)
+   - Process all epics and their stories from the combined content
+   - This ensures complete sprint status coverage
+4. **Priority**: If both whole and sharded versions exist, use the whole document
+
+**Fuzzy matching**: Be flexible with document names - users may use variations like `epics.md`, `rcode-epics.md`, `user-stories.md`, etc.
+
+<workflow>
+
+<step n="0" goal="Capacity Gate — halt until capacity inputs are known">
+<action>Check whether a recent sprint retrospective or prior sprint file contains numeric capacity (devs, PTO, velocity). If yes, load and display it for user confirmation.</action>
+<action>If no capacity data is available, ask the user — via AskUserQuestion or plain prompt — for:
+  1. Number of devs on the sprint
+  2. PTO / days off
+  3. Known meetings / interrupt load (hours/week)
+  4. Target velocity (story points or hours) — use prior sprint if available
+</action>
+<action>Compute: available_capacity = (devs × working_hours × velocity_factor) − PTO − meetings; apply a 20% buffer.</action>
+<action>BLOCKING: If any input is missing and the runtime is NOT in `mode: yolo` or `--auto`, halt and restate the question. Never fabricate numbers. See `../../_shared/no-autonomous-bypass.md`.</action>
+<action>Record the capacity inputs in the output `sprint-status.yaml` frontmatter under `capacity:` so downstream status/progress workflows can display the source of truth.</action>
+</step>
+
+<step n="1" goal="Parse epic files and extract all work items">
+<action>Load {project_context} for project-wide patterns and conventions (if exists)</action>
+<action>Communicate in {communication_language} with {user_name}</action>
+<action>Look for all files matching `{epics_pattern}` in {epics_location}</action>
+<action>Could be a single `epics.md` file or multiple `epic-1.md`, `epic-2.md` files</action>
+
+<action>For each epic file found, extract:</action>
+
+- Epic numbers from headers like `## Epic 1:` or `## Epic 2:`
+- Story IDs and titles from patterns like `### Story 1.1: User Authentication`
+- Convert story format from `Epic.Story: Title` to kebab-case key: `epic-story-title`
+
+**Story ID Conversion Rules:**
+
+- Original: `### Story 1.1: User Authentication`
+- Replace period with dash: `1-1`
+- Convert title to kebab-case: `user-authentication`
+- Final key: `1-1-user-authentication`
+
+<action>Build complete inventory of all epics and stories from all epic files</action>
+</step>
+
+<step n="2" goal="Build sprint status structure">
+<action>For each epic found, create entries in this order:</action>
+
+1. **Epic entry** - Key: `epic-{num}`, Default status: `backlog`
+2. **Story entries** - Key: `{epic}-{story}-{title}`, Default status: `backlog`
+3. **Retrospective entry** - Key: `epic-{num}-retrospective`, Default status: `optional`
+
+**Example structure:**
+
+```yaml
+development_status:
+  epic-1: backlog
+  1-1-user-authentication: backlog
+  1-2-account-management: backlog
+  epic-1-retrospective: optional
+```
+
+</step>
+
+<step n="3" goal="Apply intelligent status detection">
+<action>For each story, detect current status by checking files:</action>
+
+**Story file detection:**
+
+- Check: `{story_location_absolute}/{story-key}.md` (e.g., `stories/1-1-user-authentication.md`)
+- If exists → upgrade status to at least `ready-for-dev`
+
+**Preservation rule:**
+
+- If existing `{status_file}` exists and has more advanced status, preserve it
+- Never downgrade status (e.g., don't change `done` to `ready-for-dev`)
+
+**Status Flow Reference:**
+
+- Epic: `backlog` → `in-progress` → `done`
+- Story: `backlog` → `ready-for-dev` → `in-progress` → `review` → `done`
+- Retrospective: `optional` ↔ `done`
+  </step>
+
+<step n="4" goal="Generate sprint status file">
+<action>Create or update {status_file} with:</action>
+
+**File Structure:**
+
+```yaml
+# generated: {date}
+# last_updated: {date}
+# project: {project_name}
+# project_key: {project_key}
+# tracking_system: {tracking_system}
+# story_location: {story_location}
+
+# STATUS DEFINITIONS:
+# ==================
+# Epic Status:
+#   - backlog: Epic not yet started
+#   - in-progress: Epic actively being worked on
+#   - done: All stories in epic completed
+#
+# Epic Status Transitions:
+#   - backlog → in-progress: Automatically when first story is created (via create-story)
+#   - in-progress → done: Manually when all stories reach 'done' status
+#
+# Story Status:
+#   - backlog: Story only exists in epic file
+#   - ready-for-dev: Story file created in stories folder
+#   - in-progress: Developer actively working on implementation
+#   - review: Ready for code review (via Dev's code-review workflow)
+#   - done: Story completed
+#
+# Retrospective Status:
+#   - optional: Can be completed but not required
+#   - done: Retrospective has been completed
+#
+# WORKFLOW NOTES:
+# ===============
+# - Epic transitions to 'in-progress' automatically when first story is created
+# - Stories can be worked in parallel if team capacity allows
+# - SM typically creates next story after previous one is 'done' to incorporate learnings
+# - Dev moves story to 'review', then runs code-review (fresh context, different LLM recommended)
+
+generated: { date }
+last_updated: { date }
+project: { project_name }
+project_key: { project_key }
+tracking_system: { tracking_system }
+story_location: { story_location }
+
+development_status:
+  # All epics, stories, and retrospectives in order
+```
+
+<action>Write the complete sprint status YAML to {status_file}</action>
+<action>CRITICAL: Metadata appears TWICE - once as comments (#) for documentation, once as YAML key:value fields for parsing</action>
+<action>Ensure all items are ordered: epic, its stories, its retrospective, next epic...</action>
+</step>
+
+<step n="5" goal="Validate and report">
+<action>Perform validation checks:</action>
+
+- [ ] Every epic in epic files appears in {status_file}
+- [ ] Every story in epic files appears in {status_file}
+- [ ] Every epic has a corresponding retrospective entry
+- [ ] No items in {status_file} that don't exist in epic files
+- [ ] All status values are legal (match state machine definitions)
+- [ ] File is valid YAML syntax
+
+<action>Count totals:</action>
+
+- Total epics: {{epic_count}}
+- Total stories: {{story_count}}
+- Epics in-progress: {{in_progress_count}}
+- Stories done: {{done_count}}
+
+<action>Display completion summary to {user_name} in {communication_language}:</action>
+
+**Sprint Status Generated Successfully**
+
+- **File Location:** {status_file}
+- **Total Epics:** {{epic_count}}
+- **Total Stories:** {{story_count}}
+- **Epics In Progress:** {{in_progress_count}}
+- **Stories Completed:** {{done_count}}
+
+**Next Steps:**
+
+1. Review the generated {status_file}
+2. Use this file to track development progress
+3. Agents will update statuses as they work
+4. Re-run this workflow to refresh auto-detected statuses
+
+</step>
+
+</workflow>
+
+## Additional Documentation
+
+### Status State Machine
+
+**Epic Status Flow:**
+
+```
+backlog → in-progress → done
+```
+
+- **backlog**: Epic not yet started
+- **in-progress**: Epic actively being worked on (stories being created/implemented)
+- **done**: All stories in epic completed
+
+**Story Status Flow:**
+
+```
+backlog → ready-for-dev → in-progress → review → done
+```
+
+- **backlog**: Story only exists in epic file
+- **ready-for-dev**: Story file created (e.g., `stories/1-3-plant-naming.md`)
+- **in-progress**: Developer actively working
+- **review**: Ready for code review (via Dev's code-review workflow)
+- **done**: Completed
+
+**Retrospective Status:**
+
+```
+optional ↔ done
+```
+
+- **optional**: Ready to be conducted but not required
+- **done**: Finished
+
+### Guidelines
+
+1. **Epic Activation**: Mark epic as `in-progress` when starting work on its first story
+2. **Sequential Default**: Stories are typically worked in order, but parallel work is supported
+3. **Parallel Work Supported**: Multiple stories can be `in-progress` if team capacity allows
+4. **Review Before Done**: Stories should pass through `review` before `done`
+5. **Learning Transfer**: SM typically creates next story after previous one is `done` to incorporate learnings