@hanzlaa/rcode 2.1.0

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

@@ -0,0 +1,77 @@
+---
+name: rihal-scaffold-project
+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).
+---
+
+## 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-01-target.md

@@ -0,0 +1,17 @@
+# Step 1: Target Directory
+
+## Goal
+Determine the target directory for the new project.
+
+## Rules
+- If the user already provided a project name or path when invoking the skill, use it.
+- If not, ask: **"What should the project be called? I'll create a folder with that name in the current directory."**
+- Accept either a bare name (`my-app`) or a full path (`/home/user/projects/my-app`).
+- If bare name: resolve to `{cwd}/{name}` where `{cwd}` is the directory the user is currently in.
+- Store resolved path as `{target_path}` and project name as `{project_name}`.
+
+## Output
+Confirm back to the user:
+> "Got it — I'll scaffold into `{target_path}`. Let me check if that folder is ready..."
+
+Then proceed to `step-02-safety.md`.

package/rihal/skills/actions/4-implementation/rihal-scaffold-project/steps/step-02-safety.md

@@ -0,0 +1,35 @@
+# Step 2: Safety Check
+
+## Goal
+Ensure the target directory is safe to scaffold into.
+
+## Check: Does the directory exist?
+
+### Case A — Directory does not exist
+- Safe to proceed.
+- Inform user: "Folder doesn't exist yet — I'll create it."
+- Proceed to `step-03-clone.md`.
+
+### Case B — Directory exists and is EMPTY
+- Safe to proceed.
+- Inform user: "Folder exists and is empty — proceeding."
+- Proceed to `step-03-clone.md`.
+
+### Case C — Directory exists and is NOT EMPTY
+- **STOP. Do not touch anything.**
+- Present the user with two options:
+
+  > "The folder `{target_path}` already has files in it. For safety I won't touch it.
+  >
+  > What would you like to do?
+  > **A)** Create a new folder called `{project_name}-new` instead
+  > **B)** Give me a different folder name
+  > **C)** Empty the folder yourself first, then tell me when it's ready"
+
+- Wait for user response. Do NOT proceed until user explicitly confirms.
+- If user chooses **A**: set `{target_path}` = `{cwd}/{project_name}-new`, proceed to step-03-clone.md.
+- If user chooses **B**: ask for new name, loop back to step-01-target.md logic.
+- If user chooses **C**: wait. When user says "ready" or "done", re-check the folder. Only proceed if it is now empty.
+
+## Security Note
+**NEVER delete, move, or modify files in an existing directory.** The user must take that action themselves. This skill only creates new content.

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

@@ -0,0 +1,50 @@
+# 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

@@ -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/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-sprint-planning/SKILL.md

@@ -0,0 +1,35 @@
+---
+name: rihal-sprint-planning
+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).
+---
+
+## Workflow
+
+Follow the instructions in ./workflow.md.
+
+## Output Format
+
+- Output: .rihal/phases/{phase}/sprint-{N}.md
+- Fixed structure: Sprint Goal (one sentence) | 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
+
+## 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

@@ -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 `.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/sprint-status-template.yaml

@@ -0,0 +1,56 @@
+# Sprint Status Template
+# This is an EXAMPLE showing the expected format
+# The actual file will be generated with all epics/stories from your epic files
+
+# generated: {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
+#
+# Story Status:
+#   - backlog: Story only exists in epic file
+#   - ready-for-dev: Story file created, ready for development
+#   - in-progress: Developer actively working on implementation
+#   - review: Implementation complete, ready for review
+#   - done: Story completed
+#
+# Retrospective Status:
+#   - optional: Can be completed but not required
+#   - done: Retrospective has been completed
+#
+# WORKFLOW NOTES:
+# ===============
+# - Mark epic as 'in-progress' when starting work on its first story
+# - SM typically creates next story ONLY after previous one is 'done' to incorporate learnings
+# - Dev moves story to 'review', then Dev runs code-review (fresh context, ideally different LLM)
+
+# EXAMPLE STRUCTURE (your actual epics/stories will replace these):
+
+generated: 05-06-2-2025 21:30
+last_updated: 05-06-2-2025 21:30
+project: My Awesome Project
+project_key: NOKEY
+tracking_system: file-system
+story_location: "{story_location}"
+
+development_status:
+  epic-1: backlog
+  1-1-user-authentication: done
+  1-2-account-management: ready-for-dev
+  1-3-plant-data-model: backlog
+  1-4-add-plant-manual: backlog
+  epic-1-retrospective: optional
+
+  epic-2: backlog
+  2-1-personality-system: backlog
+  2-2-chat-interface: backlog
+  2-3-llm-integration: backlog
+  epic-2-retrospective: optional

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

@@ -0,0 +1,284 @@
+# 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.
+
+---
+
+## 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

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

@@ -0,0 +1,30 @@
+---
+name: rihal-sprint-status
+description: >
+  Generate a sprint status report showing progress, blockers, and
+  recommended next actions. Activates when the user says "sprint status",
+  "how is the sprint going", "generate status report", "sprint progress", or
+  "where are we in the sprint". Do NOT use for retrospectives (use
+  rihal-retrospective).
+---
+
+## Workflow
+
+Follow the instructions in ./workflow.md.
+
+## Output Format
+
+- Status table: Story | Owner | Status | Blockers | Notes
+- Summary: X/Y stories done, N blockers, recommendation for next action
+- Output to .rihal/progress/status-{date}.md
+- Do NOT invent progress — read from actual file states
+
+## Examples
+
+### Happy Path
+**Input:** "What's the sprint status?"
+**Expected behavior:** Scan stories in current sprint, read each story's state (backlog/ready/in-progress/review/done), produce table + summary + recommendation.
+
+### Edge Case: No Active Sprint
+**Input:** "Sprint status" (no sprint file exists)
+**Expected behavior:** Respond: "No active sprint found. Run rihal-sprint-planning first."