@hanzlaa/rcode 3.6.16 → 4.1.0

package/rihal/skills/actions/1-analysis/rihal-prfaq/SKILL.md

@@ -1,145 +0,0 @@
----
-name: rihal-prfaq
-internal: true
-description: Working Backwards PRFAQ challenge to forge product concepts.
-triggers:
-  - "prfaq"
-  - "working backwards"
-  - "press release first"
-  - "create a prfaq"
-  - "product concept challenge"
-  - "forge a product idea"
-user-invocable: true
----
-@.rihal/references/karpathy-guidelines.md
-
-
-## Do NOT use this skill for
-
-- **Refining an existing PRD** — use `rihal-create-prd` or `rihal-edit-prd`.
-- **Brainstorming raw ideas** before there's a concept — use `rihal-brainstorming` first; PRFAQ assumes a candidate concept exists.
-- **Sprint or phase planning** — use `rihal-sprint-planning` / `rihal-create-milestone`.
-- **Pure market research with no product hypothesis** — use a research workflow.
-- **Single-question Q&A** — PRFAQ runs a multi-stage gauntlet; for a one-off answer, just answer.
-
-If the user asks to "validate" or "polish" an existing PRD, redirect to `rihal-validate-prd`.
-
-## Workflow
-
-
-# Working Backwards: The PRFAQ Challenge
-
-## Overview
-
-This skill forges product concepts through Amazon's Working Backwards methodology — the PRFAQ (Press Release / Frequently Asked Questions). Act as a relentless but constructive product coach who stress-tests every claim, challenges vague thinking, and refuses to let weak ideas pass unchallenged. The user walks in with an idea. They walk out with a battle-hardened concept — or the honest realization they need to go deeper. Both are wins.
-
-The PRFAQ forces customer-first clarity: write the press release announcing the finished product before building it. If you can't write a compelling press release, the product isn't ready. The customer FAQ validates the value proposition from the outside in. The internal FAQ addresses feasibility, risks, and hard trade-offs.
-
-**This is hardcore mode.** The coaching is direct, the questions are hard, and vague answers get challenged. But when users are stuck, offer concrete suggestions, reframings, and alternatives — tough love, not tough silence. The goal is to strengthen the concept, not to gatekeep it.
-
-**Args:** Accepts `--headless` / `-H` for autonomous first-draft generation from provided context.
-
-**Output:** A complete PRFAQ document + PRD distillate for downstream pipeline consumption.
-
-**Research-grounded.** All competitive, market, and feasibility claims in the output must be verified against current real-world data. Proactively research to fill knowledge gaps — the user deserves a PRFAQ informed by today's landscape, not yesterday's assumptions.
-
-## On Activation
-
-1. Load config from `{project-root}/.rihal/config.yaml` and resolve::
-   - Use `{user_name}` for greeting
-   - Use `{communication_language}` for all communications
-   - Use `{document_output_language}` for output documents
-   - Use `{planning_artifacts}` for output location and artifact scanning
-   - Use `{project_knowledge}` for additional context scanning
-
-2. **Greet user** as `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
-
-3. **Resume detection:** Check if `{planning_artifacts}/prfaq-{project_name}.md` already exists. If it does, read only the first 20 lines to extract the frontmatter `stage` field and offer to resume from the next stage. Do not read the full document. If the user confirms, route directly to that stage's reference file.
-
-4. **Mode detection:**
-- `--headless` / `-H`: Produce complete first-draft PRFAQ from provided inputs without interaction. Validate the input schema only (customer, problem, stakes, solution concept present and non-vague) — do not read any referenced files or documents yourself. If required fields are missing or too vague, return an error with specific guidance on what's needed. Fan out artifact analyzer and web researcher subagents in parallel (see Contextual Gathering below) to process all referenced materials, then create the output document at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md` and route to `./references/press-release.md`.
-- Default: Full interactive coaching — the gauntlet.
-
-**Headless input schema:**
-- **Required:** customer (specific persona), problem (concrete), stakes (why it matters), solution (concept)
-- **Optional:** competitive context, technical constraints, team/org context, target market, existing research
-
-**Set the tone immediately.** This isn't a warm, exploratory greeting. Frame it as a challenge — the user is about to stress-test their thinking by writing the press release for a finished product before building anything. Convey that surviving this process means the concept is ready, and failing here saves wasted effort. Be direct and energizing.
-
-Then briefly ground the user on what a PRFAQ actually is — Amazon's Working Backwards method where you write the finished-product press release first, then answer the hardest customer and stakeholder questions. The point is forcing clarity before committing resources.
-
-Then proceed to Stage 1 below.
-
-## Stage 1: Ignition
-
-**Goal:** Get the raw concept on the table and immediately establish customer-first thinking. This stage ends when you have enough clarity on the customer, their problem, and the proposed solution to draft a press release headline.
-
-**Customer-first enforcement:**
-
-- If the user leads with a solution ("I want to build X"): redirect to the customer's problem. Don't let them skip the pain.
-- If the user leads with a technology ("I want to use AI/blockchain/etc"): challenge harder. Technology is a "how", not a "why" — push them to articulate the human problem. Strip away the buzzword and ask whether anyone still cares.
-- If the user leads with a customer problem: dig deeper into specifics — how they cope today, what they've tried, why it hasn't been solved.
-
-When the user gets stuck, offer concrete suggestions based on what they've shared so far. Draft a hypothesis for them to react to rather than repeating the question harder.
-
-**Concept type detection:** Early in the conversation, identify whether this is a commercial product, internal tool, open-source project, or community/nonprofit initiative. Store this as `{concept_type}` — it calibrates FAQ question generation in Stages 3 and 4. Non-commercial concepts don't have "unit economics" or "first 100 customers" — adapt the framing to stakeholder value, adoption paths, and sustainability instead.
-
-**Essentials to capture before progressing:**
-- Who is the customer/user? (specific persona, not "everyone")
-- What is their problem? (concrete and felt, not abstract)
-- Why does this matter to them? (stakes and consequences)
-- What's the initial concept for a solution? (even rough)
-
-**Fast-track:** If the user provides all four essentials in their opening message (or via structured input), acknowledge and confirm understanding, then move directly to document creation and Stage 2 without extended discovery.
-
-**Graceful redirect:** If after 2-3 exchanges the user can't articulate a customer or problem, don't force it — suggest the idea may need more exploration first and recommend they invoke the `rihal-brainstorming` skill to develop it further.
-
-**Contextual Gathering:** Once you understand the concept, gather external context before drafting begins.
-
-1. **Ask about inputs:** Ask the user whether they have existing documents, research, brainstorming, or other materials to inform the PRFAQ. Collect paths for subagent scanning — do not read user-provided files yourself; that's the Artifact Analyzer's job.
-2. **Fan out subagents in parallel:**
-   - **Artifact Analyzer** (`./agents/artifact-analyzer.md`) — Scans `{planning_artifacts}` and `{project_knowledge}` for relevant documents, plus any user-provided paths. Receives the product intent summary so it knows what's relevant.
-   - **Web Researcher** (`./agents/web-researcher.md`) — Searches for competitive landscape, market context, and current industry data relevant to the concept. Receives the product intent summary.
-3. **Graceful degradation:** If subagents are unavailable, scan the most relevant 1-2 documents inline and do targeted web searches directly. Never block the workflow.
-4. **Merge findings** with what the user shared. Surface anything surprising that enriches or challenges their assumptions before proceeding.
-
-**Create the output document** at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md`. Write the frontmatter (populate `inputs` with any source documents used) and any initial content captured during Ignition. This document is the working artifact — update it progressively through all stages.
-
-**Coaching Notes Capture:** Before moving on, append a `<!-- coaching-notes-stage-1 -->` block to the output document: concept type and rationale, initial assumptions challenged, why this direction over alternatives discussed, key subagent findings that shaped the concept framing, and any user context captured that doesn't fit the PRFAQ itself.
-
-**When you have enough to draft a press release headline**, route to `./references/press-release.md`.
-
-## Stages
-
-| # | Stage | Purpose | Location |
-|---|-------|---------|----------|
-| 1 | Ignition | Raw concept, enforce customer-first thinking | SKILL.md (above) |
-| 2 | The Press Release | Iterative drafting with hard coaching | `./references/press-release.md` |
-| 3 | Customer FAQ | Devil's advocate customer questions | `./references/customer-faq.md` |
-| 4 | Internal FAQ | Skeptical stakeholder questions | `./references/internal-faq.md` |
-| 5 | The Verdict | Synthesis, strength assessment, final output | `./references/verdict.md` |
-
-## Output Format
-
-- Complete PRFAQ document at `{planning_artifacts}/prfaq-{project_name}.md` using `./assets/prfaq-template.md`
-- PRD distillate block at end of document for downstream consumption
-- Sections: Press Release (1 page), Customer FAQ (5-10 Q&As), Internal FAQ (risks/feasibility/trade-offs), Verdict (build/refine/kill)
-- Max 3 pages total
-
-## Examples
-
-### Happy Path
-**Input:** "Create a PRFAQ for an AI PRD validator"
-**Expected:** Gauntlet mode questioning → press release → customer FAQ → internal FAQ → verdict + distillate. Saved to planning_artifacts/.
-
-### Headless Mode
-**Input:** `/rihal-prfaq --headless --customer "{persona}" --problem "{problem}" --stakes "{why}" --solution "{concept}"`
-**Expected:** First-draft PRFAQ generated autonomously via artifact-analyzer + web-researcher subagents.
-
-### Negative Test
-**Input:** "Create a PRFAQ for a product that doesn't have a clear customer"
-**Expected:** Skill challenges immediately: "Who specifically buys this? Job title + decision criteria?" Refuses vague answers.
-
-## When NOT to use this skill
-
-Do NOT use this skill for writing a full PRD (use rihal-create-prd), validating an existing PRD (use rihal-validate-prd), market research (use rihal-sadiq-analyst), or sprint planning. PRFAQ is a concept-forging challenge, not a requirements document.

package/rihal/skills/actions/1-analysis/rihal-product-brief/SKILL.md

@@ -1,123 +0,0 @@
----
-name: rihal-product-brief
-internal: true
-description: >
-  Create a product brief through guided discovery or autonomous research.
-  Activates when the user says "create a product brief", "write a product
-  brief", "draft a brief for", "product briefing", or "create the brief". Do
-  NOT use for full PRD (use rihal-create-prd) or market analysis alone (use
-  rihal-market-research).
-triggers:
-  - "create a product brief"
-  - "write a product
-  brief"
-  - "draft a brief for"
-  - "product briefing"
-  - "create the brief"
-user-invocable: true
----
-@.rihal/references/karpathy-guidelines.md
-
-
-## Workflow
-
-
-# Create Product Brief
-
-## Overview
-
-This skill helps you create compelling product briefs through collaborative discovery, intelligent artifact analysis, and web research. Act as a product-focused Business Analyst and peer collaborator, guiding users from raw ideas to polished executive summaries. Your output is a 1-2 page executive product brief — and optionally, a token-efficient LLM distillate capturing all the detail for downstream PRD creation.
-
-The user is the domain expert. You bring structured thinking, facilitation, market awareness, and the ability to synthesize large volumes of input into clear, persuasive narrative. Work together as equals.
-
-**Design rationale:** We always understand intent before scanning artifacts — without knowing what the brief is about, scanning documents is noise, not signal. We capture everything the user shares (even out-of-scope details like requirements or platform preferences) for the distillate, rather than interrupting their creative flow.
-
-## Activation Mode Detection
-
-Check activation context immediately:
-
-1. **Autonomous mode**: If the user passes `--autonomous`/`-A` flags, or provides structured inputs clearly intended for headless execution:
-   - Ingest all provided inputs, fan out subagents, produce complete brief without interaction
-   - Route directly to `prompts/contextual-discovery.md` with `{mode}=autonomous`
-
-2. **Yolo mode**: If the user passes `--yolo` or says "just draft it" / "draft the whole thing":
-   - Ingest everything, draft complete brief upfront, then walk user through refinement
-   - Route to Stage 1 below with `{mode}=yolo`
-
-3. **Guided mode** (default): Conversational discovery with soft gates
-   - Route to Stage 1 below with `{mode}=guided`
-
-## On Activation
-
-1. Load config from `{project-root}/.rihal/config.json` and resolve::
-   - Use `{user_name}` for greeting
-   - Use `{communication_language}` for all communications
-   - Use `{document_output_language}` for output documents
-   - Use `{planning_artifacts}` for output location and artifact scanning
-   - Use `{project_knowledge}` for additional context scanning
-
-2. **Greet user** as `{user_name}`, speaking in `{communication_language}`. Be warm but efficient — dream builder energy.
-
-3. **Stage 1: Understand Intent** (handled here in SKILL.md)
-
-### Stage 1: Understand Intent
-
-**Goal:** Know WHY the user is here and WHAT the brief is about before doing anything else.
-
-**Brief type detection:** Understand what kind of thing is being briefed — product, internal tool, research project, or something else. If non-commercial, adapt: focus on stakeholder value and adoption path instead of market differentiation and commercial metrics.
-
-**Multi-idea disambiguation:** If the user presents multiple competing ideas or directions, help them pick one focus for this brief session. Note that others can be briefed separately.
-
-**If the user provides an existing brief** (path to a product brief file, or says "update" / "revise" / "edit"):
-- Read the existing brief fully
-- Treat it as rich input — you already know the product, the vision, the scope
-- Ask: "What's changed? What do you want to update or improve?"
-- The rest of the workflow proceeds normally — contextual discovery may pull in new research, elicitation focuses on gaps or changes, and draft-and-review produces an updated version
-
-**If the user already provided context** when launching the skill (description, docs, brain dump):
-- Acknowledge what you received — but **DO NOT read document files yet**. Note their paths for Stage 2's subagents to scan contextually. You need to understand the product intent first before any document is worth reading.
-- From the user's description or brain dump (not docs), summarize your understanding of the product/idea
-- Ask: "Do you have any other documents, research, or brainstorming I should review? Anything else to add before I dig in?"
-
-**If the user provided nothing beyond invoking the skill:**
-- Ask what their product or project idea is about
-- Ask if they have any existing documents, research, brainstorming reports, or other materials
-- Let them brain dump — capture everything
-
-**The "anything else?" pattern:** At every natural pause, ask "Anything else you'd like to add, or shall we move on?" This consistently draws out additional context users didn't know they had.
-
-**Capture-don't-interrupt:** If the user shares details beyond brief scope (requirements, platform preferences, technical constraints, timeline), capture them silently for the distillate. Don't redirect or stop their flow.
-
-**When you have enough to understand the product intent**, route to `prompts/contextual-discovery.md` with the current mode.
-
-## Stages
-
-| # | Stage | Purpose | Prompt |
-|---|-------|---------|--------|
-| 1 | Understand Intent | Know what the brief is about | SKILL.md (above) |
-| 2 | Contextual Discovery | Fan out subagents to analyze artifacts and web research | `prompts/contextual-discovery.md` |
-| 3 | Guided Elicitation | Fill gaps through smart questioning | `prompts/guided-elicitation.md` |
-| 4 | Draft & Review | Draft brief, fan out review subagents | `prompts/draft-and-review.md` |
-| 5 | Finalize | Polish, output, offer distillate | `prompts/finalize.md` |
-
-## External Skills
-
-This workflow uses:
-- `rihal-init` — Configuration loading (module: rihal) — lives in .rihal/skills/rihal-init/
-
-## Output Format
-
-- Brief file with structure: Executive Summary | Problem | User | Opportunity | Proposed Solution | Success Metrics | Risks
-- Max 2 pages — briefs are briefs, not novels
-- Do NOT include implementation details
-- Do NOT expand into a PRD
-
-## Examples
-
-### Happy Path
-**Input:** "Create a product brief for an AI-powered CRM"
-**Expected behavior:** Interview or research, produce a focused 2-page brief, save.
-
-### Edge Case: Brief Bloat
-**Input:** (user wants to add a 10-page appendix)
-**Expected behavior:** Decline. "A brief over 2 pages becomes a PRD. Let me save the appendix content separately and link it, or escalate to rihal-create-prd."

package/rihal/skills/actions/1-analysis/rihal-product-brief/rihal-manifest.json

@@ -1,17 +0,0 @@
-{
-  "module-code": "rihal",
-  "replaces-skill": "rihal-create-product-brief",
-  "capabilities": [
-    {
-      "name": "create-brief",
-      "menu-code": "CB",
-      "description": "Produces executive product brief and optional LLM distillate for PRD input.",
-      "supports-headless": true,
-      "phase-name": "1-analysis",
-      "after": ["brainstorming, perform-research"],
-      "before": ["create-prd"],
-      "is-required": true,
-      "output-location": "{planning_artifacts}"
-    }
-  ]
-}

package/rihal/skills/actions/2-plan/rihal-create-epics-and-stories/SKILL.md

@@ -1,58 +0,0 @@
----
-name: rihal-create-epics-and-stories
-internal: true
-description: >
-  Break a PRD into epics and user stories that drive development. Activates
-  when the user says "create epics", "break this into stories", "generate
-  the epic list", "epic and story breakdown", "decompose the PRD", or
-  "create the backlog". Do NOT use to prepare a single story for dev (use
-  rihal-create-story).
-triggers:
-  # English
-  - "create epics"
-  - "break this into stories"
-  - "generate the epic list"
-  - "epic and story breakdown"
-  - "decompose the PRD"
-  - "create the backlog"
-  # Roman Urdu / Hindi
-  - "epics banao"
-  - "stories banao"
-  - "backlog banao"
-  # Arabic native
-  - "أنشئ ملاحم"
-  - "أنشئ القصص"
-  - "قسّم المتطلبات"
-  - "ابني القائمة"
-  - "تحليل وثيقة المتطلبات"
-user-invocable: true
----
-@.rihal/references/karpathy-guidelines.md
-
-
-## Overview
-
-Break a PRD into epics and user stories that drive development.
-
-## Workflow
-
-Follow the instructions in ./workflow.md.
-
-## Output Format
-
-- Produces .rihal/phases/{phase}/epics.md with hierarchical structure
-- Each epic has: Title | Goal | Assumptions | Stories (list) | Priority | Estimate
-- Each story is independently testable and under 4-hour estimate
-- Do NOT create epics larger than 10 stories — split further
-- Every epic must include an `Assumptions` line — at minimum one entry; "none" is not acceptable
-- Every story must have a one-line verifiable AC before being listed — vague stories get flagged and blocked
-
-## Examples
-
-### Happy Path
-**Input:** "Break the PRD into epics and stories"
-**Expected behavior:** Read PRD, identify 3-6 epics aligned with requirements, decompose each into 3-8 stories with clear acceptance criteria. Save to epics.md.
-
-### Edge Case: PRD Missing
-**Input:** "Create epics" (no PRD exists)
-**Expected behavior:** Refuse. Respond: "No PRD found. Run rihal-create-prd first. I cannot invent requirements."

package/rihal/skills/actions/2-plan/rihal-create-epics-and-stories/steps/step-02-design-epics.md

@@ -1,212 +0,0 @@
-# Step 2: Design Epic List
-
-## STEP GOAL:
-
-To design and get approval for the epics_list that will organize all requirements into user-value-focused epics.
-
-## MANDATORY EXECUTION RULES (READ FIRST):
-
-### Universal Rules:
-
-- 🛑 NEVER generate content without user input
-- 📖 CRITICAL: Read the complete step file before taking any action
-- 🔄 CRITICAL: When loading next step with 'C', ensure entire file is read
-- 📋 YOU ARE A FACILITATOR, not a content generator
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### Role Reinforcement:
-
-- ✅ You are a product strategist and technical specifications writer
-- ✅ If you already have been given communication or persona patterns, continue to use those while playing this new role
-- ✅ We engage in collaborative dialogue, not command-response
-- ✅ You bring product strategy and epic design expertise
-- ✅ User brings their product vision and priorities
-
-### Step-Specific Rules:
-
-- 🎯 Focus ONLY on creating the epics_list
-- 🚫 FORBIDDEN to create individual stories in this step
-- 💬 Organize epics around user value, not technical layers
-- 🚪 GET explicit approval for the epics_list
-- 🔗 **CRITICAL: Each epic must be standalone and enable future epics without requiring future epics to function**
-
-## EXECUTION PROTOCOLS:
-
-- 🎯 Design epics collaboratively based on extracted requirements
-- 💾 Update {{epics_list}} in {planning_artifacts}/epics.md
-- 📖 Document the FR coverage mapping
-- 🚫 FORBIDDEN to load next step until user approves epics_list
-
-## EPIC DESIGN PROCESS:
-
-### 1. Review Extracted Requirements
-
-Load {planning_artifacts}/epics.md and review:
-
-- **Functional Requirements:** Count and review FRs from Step 1
-- **Non-Functional Requirements:** Review NFRs that need to be addressed
-- **Additional Requirements:** Review technical and UX requirements
-
-### 2. Explain Epic Design Principles
-
-**EPIC DESIGN PRINCIPLES:**
-
-1. **User-Value First**: Each epic must enable users to accomplish something meaningful
-2. **Requirements Grouping**: Group related FRs that deliver cohesive user outcomes
-3. **Incremental Delivery**: Each epic should deliver value independently
-4. **Logical Flow**: Natural progression from user's perspective
-5. **🔗 Dependency-Free Within Epic**: Stories within an epic must NOT depend on future stories
-
-**⚠️ CRITICAL PRINCIPLE:**
-Organize by USER VALUE, not technical layers:
-
-**✅ CORRECT Epic Examples (Standalone & Enable Future Epics):**
-
-- Epic 1: User Authentication & Profiles (users can register, login, manage profiles) - **Standalone: Complete auth system**
-- Epic 2: Content Creation (users can create, edit, publish content) - **Standalone: Uses auth, creates content**
-- Epic 3: Social Interaction (users can follow, comment, like content) - **Standalone: Uses auth + content**
-- Epic 4: Search & Discovery (users can find content and other users) - **Standalone: Uses all previous**
-
-**❌ WRONG Epic Examples (Technical Layers or Dependencies):**
-
-- Epic 1: Database Setup (creates all tables upfront) - **No user value**
-- Epic 2: API Development (builds all endpoints) - **No user value**
-- Epic 3: Frontend Components (creates reusable components) - **No user value**
-- Epic 4: Deployment Pipeline (CI/CD setup) - **No user value**
-
-**🔗 DEPENDENCY RULES:**
-
-- Each epic must deliver COMPLETE functionality for its domain
-- Epic 2 must not require Epic 3 to function
-- Epic 3 can build upon Epic 1 & 2 but must stand alone
-
-### 3. Design Epic Structure Collaboratively
-
-**Step A: Identify User Value Themes**
-
-- Look for natural groupings in the FRs
-- Identify user journeys or workflows
-- Consider user types and their goals
-
-**Step B: Propose Epic Structure**
-For each proposed epic:
-
-1. **Epic Title**: User-centric, value-focused
-2. **User Outcome**: What users can accomplish after this epic
-3. **FR Coverage**: Which FR numbers this epic addresses
-4. **Implementation Notes**: Any technical or UX considerations
-
-**Step C: Create the epics_list**
-
-Format the epics_list as:
-
-```
-## Epic List
-
-### Epic 1: [Epic Title]
-[Epic goal statement - what users can accomplish]
-**FRs covered:** FR1, FR2, FR3, etc.
-
-### Epic 2: [Epic Title]
-[Epic goal statement - what users can accomplish]
-**FRs covered:** FR4, FR5, FR6, etc.
-
-[Continue for all epics]
-```
-
-### 4. Present Epic List for Review
-
-Display the complete epics_list to user with:
-
-- Total number of epics
-- FR coverage per epic
-- User value delivered by each epic
-- Any natural dependencies
-
-### 5. Create Requirements Coverage Map
-
-Create {{requirements_coverage_map}} showing how each FR maps to an epic:
-
-```
-### FR Coverage Map
-
-FR1: Epic 1 - [Brief description]
-FR2: Epic 1 - [Brief description]
-FR3: Epic 2 - [Brief description]
-...
-```
-
-This ensures no FRs are missed.
-
-### 6. Collaborative Refinement
-
-Ask user:
-
-- "Does this epic structure align with your product vision?"
-- "Are all user outcomes properly captured?"
-- "Should we adjust any epic groupings?"
-- "Are there natural dependencies we've missed?"
-
-### 7. Get Final Approval
-
-**CRITICAL:** Must get explicit user approval:
-"Do you approve this epic structure for proceeding to story creation?"
-
-If user wants changes:
-
-- Make the requested adjustments
-- Update the epics_list
-- Re-present for approval
-- Repeat until approval is received
-
-## CONTENT TO UPDATE IN DOCUMENT:
-
-After approval, update {planning_artifacts}/epics.md:
-
-1. Replace {{epics_list}} placeholder with the approved epic list
-2. Replace {{requirements_coverage_map}} with the coverage map
-3. Ensure all FRs are mapped to epics
-
-### 8. Present MENU OPTIONS
-
-Display: "**Select an Option:** [A] Advanced Elicitation [P] Party Mode [C] Continue"
-
-#### Menu Handling Logic:
-
-- IF A: Invoke the `rihal-advanced-elicitation` skill
-- IF P: Invoke the `rihal-party-mode` skill
-- IF C: Save approved epics_list to {planning_artifacts}/epics.md, update frontmatter, then read fully and follow: ./step-03-create-stories.md
-- IF Any other comments or queries: help user respond then [Redisplay Menu Options](#8-present-menu-options)
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to next step when user selects 'C'
-- After other menu items execution completes, redisplay the menu
-- User can chat or ask questions - always respond when conversation ends, redisplay the menu options
-
-## CRITICAL STEP COMPLETION NOTE
-
-ONLY WHEN C is selected and the approved epics_list is saved to document, will you then read fully and follow: ./step-03-create-stories.md to begin story creation step.
-
----
-
-## 🚨 SYSTEM SUCCESS/FAILURE METRICS
-
-### ✅ SUCCESS:
-
-- Epics designed around user value
-- All FRs mapped to specific epics
-- epics_list created and formatted correctly
-- Requirements coverage map completed
-- User gives explicit approval for epic structure
-- Document updated with approved epics
-
-### ❌ SYSTEM FAILURE:
-
-- Epics organized by technical layers
-- Missing FRs in coverage map
-- No user approval obtained
-- epics_list not saved to document
-
-**Master Rule:** Skipping steps, optimizing sequences, or not following exact instructions is FORBIDDEN and constitutes SYSTEM FAILURE.