@hanzlaa/rcode 3.6.16 → 4.1.0

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

@@ -1,91 +0,0 @@
----
-name: rihal-scaffold-project
-internal: true
-description: >
-  Scaffold a new project for Rihalians using the official Rihal template repo.
-  Activates when the user says "scaffold project", "create project", "new project",
-  "initialize project", "setup new project", "scaffold from template", "create from template",
-  "rihal new project", or "start a new rihal project". Do NOT use for generating
-  project context files (use rihal-generate-project-context) or cloning websites
-  (use rihal-clone-website).
-triggers:
-  - "scaffold project"
-  - "create project"
-  - "new project"
-  - "initialize project"
-  - "setup new project"
-  - "scaffold from template"
-  - "create from template"
-  - "rihal new project"
-  - "start a new rihal project"
-user-invocable: true
----
-@.rihal/references/karpathy-guidelines.md
-
-
-## Workflow
-
-
-# Scaffold Project from Rihal Template
-
-## Overview
-
-This skill bootstraps a new Rihalian project by cloning the official Rihal template
-repository (`https://github.com/rihal-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}/.rihal/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/rihal-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)
-- `.rihal/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/rihal/skills/actions/4-implementation/rihal-scaffold-project/steps/step-03-clone.md

@@ -1,50 +0,0 @@
-# Step 3: Clone Template
-
-## Goal
-Clone the official Rihal template repository fresh from GitHub into `{target_path}`.
-
-## Template Source
-```
-https://github.com/rihal-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/rihal-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 rihal 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 rihal-om/template..."
-- "Stripping template history..."
-- "Initializing fresh git repo..."
-- "Done! Proceeding to post-setup..."
-
-Then proceed to `step-04-post-setup.md`.

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

@@ -1,44 +0,0 @@
-# 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/rihal-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 rihal skills
-Offer relevant follow-up actions:
-> "What would you like to do next?
-> - **Generate project context** → `rihal-generate-project-context`
-> - **Create a PRD** → `rihal-create-prd`
-> - **Set up architecture** → `rihal-create-architecture`"
-
-## Done
-Skill execution complete.

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

@@ -1,79 +0,0 @@
----
-name: rihal-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
----
-@.rihal/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:** `.rihal/memory/project/stack.md` (versions table) and `package.json`
-- **Writes:** when a non-obvious version-specific API is used, append the source link to `.rihal/memory/project/decisions.md`

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

@@ -1,63 +0,0 @@
----
-name: rihal-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 rihal-create-epics-and-stories) or
-  status reporting (use rihal-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
----
-@.rihal/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: .rihal/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 (`.rihal/config.yaml` → `mode: yolo` or `/rihal-do --auto`). See `../../_shared/no-autonomous-bypass.md`.

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

@@ -1,43 +0,0 @@
-# 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 `.rihal/config.yaml` `mode: yolo` or `/rihal-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/rihal/skills/actions/4-implementation/rihal-sprint-planning/workflow.md

@@ -1,296 +0,0 @@
-# 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 .rihal/bin/rihal-tools.cjs state sync --from-disk
-```
-
-This keeps `.rihal/state.json` in sync with disk — `/rihal:progress`, `/rihal:status`, and `/rihal: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 `.rihal/config.yaml` → `mode: yolo` or `/rihal-do --auto`. See `../../_shared/no-autonomous-bypass.md` for the full rule and correct response pattern.
-
----
-
-## INITIALIZATION
-
-### Configuration Loading
-
-Load config from `{project-root}/.rihal/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`, `rihal-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`, `rihal-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