@hanzlaa/rcode 3.6.16 → 4.1.0

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-06-phase-stubs.md

@@ -1,56 +0,0 @@
-# Step 6: Phase Stubs Under Each Milestone
-
-**Progress: Step 6 of 10** — Next: Backlog parking lot
-
-## STEP GOAL
-
-For each milestone, list the phases it contains as **stubs** (number + name + one-line goal). No plan detail — phases get full plans via `/rihal-plan` later.
-
-## MANDATORY RULES
-
-- 🛑 Phase numbers follow Rihal's NN convention (01, 02, ..., 99, then 999.x for parking lot).
-- 🛑 Do NOT generate plan content here. That's `/rihal-plan`.
-- 🛑 Each phase has one-sentence goal, max.
-- ⏸️ HALT at menu.
-
-## SEQUENCE
-
-### 1. Propose phase stubs
-
-Mirror the outcome-to-milestone mapping from step 3. Each outcome typically becomes 1–2 phases; a milestone typically has 3–6 phases.
-
-```
-Phase stubs:
-
-M1 — MVP (Apr 24 → Jun 19)
-  01  Setup & scaffolding — repo, CI, Vercel, Neon provisioned
-  02  Auth — email/password + Google OAuth
-  03  Project CRUD — list, detail, create, archive
-  04  Data model hardening — migrations, seeds, indexes
-
-M2 — Team collaboration (Jun 19 → Jul 31)
-  05  Workspace model — users-in-workspaces
-  06  Roles & permissions — admin/member/viewer
-  07  Activity feed — who did what, when
-
-M3 — Monetization (Jul 31 → Sep 11)
-  08  Stripe integration — checkout + portal
-  09  Usage metering — event ingestion + aggregation
-  10  Billing UI — plans, invoices, receipts
-
-[A] Accept
-[P] Propose changes (add, remove, rename, renumber)
-[C] Continue
-```
-
-### 2. Cross-check against outcomes
-
-Every outcome from step 2 must be covered by at least one phase stub. If an outcome is uncovered, flag it:
-
-> ⚠ O-11 "Admin audit log" does not appear in any phase. Add to M2 (phase 07)? Move to backlog? Drop?
-
-### 3. Persist & advance
-
-- Append phase stubs to each milestone block in `{outputFile}`.
-- Update `stepsCompleted`.
-- Load `./step-07-backlog.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-07-backlog.md

@@ -1,44 +0,0 @@
-# Step 7: Backlog Parking Lot
-
-**Progress: Step 7 of 10** — Next: Write ROADMAP.md
-
-## STEP GOAL
-
-Capture everything that is **not** in M1..Mn but was considered. Use Rihal's `999.x` parking-lot convention so items can be promoted later via `/rihal-plant-seed` or `/rihal-review-backlog`.
-
-## MANDATORY RULES
-
-- 🛑 Pull explicit "Out of scope" items from the PRD into the backlog — do not silently drop them.
-- 🛑 Each backlog item gets a one-line reason ("deferred: needs user auth from M1").
-- ⏸️ HALT at menu.
-
-## SEQUENCE
-
-### 1. Collect backlog items
-
-Sources:
-- PRD's explicit "Out of scope" section.
-- Outcomes that got cut in step 3 sequencing.
-- Ideas raised during step 4-6 that did not make it into a milestone.
-
-### 2. Number using 999.x convention
-
-```
-Backlog (999.x — promotable with /rihal-plant-seed):
-
-  999.1  Cross-post to LinkedIn          — deferred: requires LinkedIn OAuth (M2+)
-  999.2  Auto-DM feature                 — deferred: abuse risk, needs rate-limit design
-  999.3  Mobile native app               — deferred: PWA sufficient for launch
-  999.4  Enterprise SSO                  — deferred: no enterprise customers yet
-  999.5  Audit log export                — deferred: nice-to-have for M2
-
-[A] Accept
-[P] Add, remove, re-number
-[C] Continue
-```
-
-### 3. Persist & advance
-
-- Append backlog section to `{outputFile}`.
-- Update `stepsCompleted`.
-- Load `./step-08-write-roadmap.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-08-write-roadmap.md

@@ -1,58 +0,0 @@
-# Step 8: Write Final ROADMAP.md
-
-**Progress: Step 8 of 10** — Next: State Sync
-
-## STEP GOAL
-
-Assemble everything collected in steps 2–7 into a clean, publication-quality ROADMAP.md. This is the document the user will reference, share, and revisit.
-
-## MANDATORY RULES
-
-- 🛑 Use the canonical ROADMAP.md structure (mirrors `docs/ROADMAP.md` pattern in Rihal Code itself).
-- 🛑 Every milestone: name, window, goal, outcomes, phases, kill criteria.
-- 🛑 Every phase stub: number, name, one-line goal.
-- 🛑 Clean markdown — no debug sections, no "proposed" labels, no step headings.
-
-## SEQUENCE
-
-### 1. Template for each milestone block
-
-```markdown
-## Milestone M{N} — {Name}
-
-**Window:** {start} → {end}
-**Goal:** {one-sentence goal}
-**Status:** {Planned | Active | Complete}
-
-### Outcomes
-- O-{nn} {Outcome name} (PRD §{section})
-
-### Phases
-| # | Name | Goal |
-|---|------|------|
-| {NN} | {phase-name} | {one-line goal} |
-
-### Acceptance
-{1–3 bullet acceptance criteria derived from outcomes}
-
-### Kill criteria (binary)
-- K{N}.{M}: {criterion with numeric threshold}
-
----
-```
-
-### 2. Assemble
-
-- Top of file: title (project name + "Roadmap"), source PRD reference, hard deadline if any.
-- Then all milestones in order.
-- Then `## Backlog (parking lot)` section with 999.x items.
-- Then a brief `## Kill criteria summary` reminder explaining binary-threshold semantics.
-
-### 3. Overwrite {outputFile}
-
-Replace the step-by-step accumulated content with the clean final version. Do NOT keep the intermediate "proposed" sections. The frontmatter stays and is updated.
-
-### 4. Persist & advance
-
-- Update frontmatter: `stepsCompleted` adds `step-08-write-roadmap`. Add `totalMilestones`, `totalPhases`, `hardDeadline` (if any).
-- Load `./step-09-state-sync.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-09-state-sync.md

@@ -1,62 +0,0 @@
-# Step 9: Sync ROADMAP into state.json
-
-**Progress: Step 9 of 10** — Next: Completion summary
-
-## STEP GOAL
-
-Call the state-sync CLI so `.rihal/state.json` reflects every milestone and phase we just wrote to `ROADMAP.md`. This closes the drift loophole documented in issue #126 and enforced by `_shared/state-sync-rule.md`.
-
-## MANDATORY RULES
-
-- 🛑 This step MUST run. Skipping it leaves `/rihal-status` and `/rihal-progress` showing stale data.
-- 🛑 Report the sync result (pulled phases, existing phases updated, any errors) to the user.
-
-## SEQUENCE
-
-### 1. Run the sync
-
-```bash
-node .rihal/bin/rihal-tools.cjs state sync --from-disk
-```
-
-### 2. Parse and report
-
-Expected JSON output shape:
-
-```json
-{
-  "ok": true,
-  "synced": true,
-  "milestones_found": 3,
-  "phases_found": 10,
-  "phases_upserted": 10,
-  "epics_found": 0,
-  "roadmap_exists": true,
-  "epics_exists": false
-}
-```
-
-Report to the user:
-
-```
-State sync complete:
-  Milestones:       3
-  Phases:          10
-  Phases upserted: 10 (new)
-  Epics:            0 (none yet — run /rihal-create-epics-and-stories next)
-```
-
-### 3. Verify drift closed
-
-Run a sanity check:
-
-```bash
-node .rihal/bin/rihal-tools.cjs state read | grep -E '"phases":|"name":'
-```
-
-Confirm the phase count matches what ROADMAP.md shows. If not, surface a warning and tell the user to run `state sync --from-disk` again or check for markdown malformation.
-
-### 4. Advance
-
-- Update `stepsCompleted`: add `step-09-state-sync`.
-- Load `./step-10-complete.md`.

package/rihal/skills/actions/2-plan/rihal-create-milestone/steps/step-10-complete.md

@@ -1,56 +0,0 @@
-# Step 10: Completion Summary & Handoff
-
-**Progress: Step 10 of 10** — Final step
-
-## STEP GOAL
-
-Summarize what was produced, mark the workflow complete in frontmatter, and point the user at the next natural command.
-
-## SEQUENCE
-
-### 1. Final frontmatter update
-
-Append `step-10-complete` to `stepsCompleted`. Add `completedAt: {ISO date}`.
-
-### 2. Completion summary to user
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- RIHAL ► ROADMAP CREATED
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Source PRD:     {inputFile}
-Roadmap:        {outputFile}
-State:          .rihal/state.json (synced)
-
-Shipped:
-  {N} milestones: M1..M{N}
-  {M} phases:     01..{NN}
-  {K} backlog items: 999.1..999.{K}
-
-Hard deadline:  {deadline or "none specified"}
-
-[{completedAt}]
-```
-
-### 3. Next-step menu (intent-based Route A/B/C pattern)
-
-```
-What's next?
-
-  [A] Decompose M1 into epics + stories
-      → /rihal-create-epics-and-stories
-
-  [B] Plan the first phase in detail
-      → /rihal-plan 01
-
-  [C] Review the roadmap with the team
-      → /rihal-council "Is this roadmap realistic?"
-
-  [D] Park and review later
-      → Roadmap is saved; pick up with /rihal-progress anytime
-```
-
-### 4. HALT
-
-This is the terminal step. Do NOT load another step file. The workflow is complete.

package/rihal/skills/actions/2-plan/rihal-create-milestone/workflow.md

@@ -1,93 +0,0 @@
----
-main_config: '{project-root}/.rihal/config.json'
-outputFile: '{planning_artifacts}/ROADMAP.md'
-inputFile: '{planning_artifacts}/prd.md'
----
-
-# Create Milestone / Roadmap Workflow
-
-**Goal:** Design a roadmap of milestones (M1..Mn) from an approved PRD. Each milestone carries a window, goal, acceptance, and binary kill criteria.
-
-**Your Role:** Product strategist and program manager collaborating with the user. You sequence outcomes into milestones; the user validates priorities and cut lines.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self-contained instruction file
-- **Just-In-Time Loading**: Only the current step file is in memory
-- **Sequential Enforcement**: Sequence within step files must be completed in order
-- **State Tracking**: Document progress via `stepsCompleted` array in output frontmatter
-- **Append-Only Building**: Build ROADMAP.md by appending each milestone once confirmed
-
-### Critical Rules (NO EXCEPTIONS)
-
-- 🛑 **NEVER** load multiple step files simultaneously
-- 📖 **ALWAYS** read entire step file before execution
-- 🚫 **NEVER** skip steps or optimize the sequence
-- ⏸️ **ALWAYS** halt at menus and wait for user input
-- 💾 **ALWAYS** update frontmatter of output files when writing
-- 🎯 **ALWAYS** follow the exact instructions in the step file
-- 📋 **NEVER** create mental todo lists from future steps
-- 🚷 **NEVER** invent an "autonomous mode" or self-declared bypass. The only sanctioned paths are `.rihal/config.yaml` → `mode: yolo` or `/rihal-do --auto`. See `../../_shared/no-autonomous-bypass.md`.
-- 🔗 **NEVER** cite external sources without `WebFetch`. See `../../_shared/research-citation-rule.md`.
-- 🗂️ **ALWAYS** sync every milestone/phase into `.rihal/state.json` after writing to ROADMAP.md. See `../../_shared/state-sync-rule.md`.
-
----
-
-## INITIALIZATION SEQUENCE
-
-### 1. Configuration Loading
-
-Load and read full config from `{main_config}` and resolve:
-
-- `project_name`, `output_folder`, `planning_artifacts`, `user_name`
-- `communication_language`, `document_output_language`
-- `date` as system-generated current datetime
-
-✅ SPEAK OUTPUT in `{communication_language}`.
-✅ WRITE all artifact content in `{document_output_language}`.
-
-### 2. Prerequisite Check
-
-Verify `{inputFile}` (PRD) exists and is non-empty. If missing:
-
-- Respond: *"I need an approved PRD first. Run `/rihal-create-prd` or point me at the existing brief."*
-- HALT. Do not create ROADMAP.md.
-
-If PRD frontmatter shows `status: draft`, warn the user and ask whether to proceed.
-
-### 3. Route to First Step
-
-Read fully and follow: `./steps/step-01-init.md`
-
----
-
-## WORKFLOW OUTLINE
-
-Steps (loaded one at a time):
-
-1. `step-01-init.md` — Load PRD, detect continuation, initialize ROADMAP.md frontmatter.
-2. `step-02-outcomes.md` — Extract major outcomes from PRD. User confirms the list.
-3. `step-03-sequencing.md` — Group outcomes into milestones; agree cut lines.
-4. `step-04-windows.md` — Assign date windows to each milestone; verify realism with user.
-5. `step-05-kill-criteria.md` — Define binary kill criteria per milestone.
-6. `step-06-phase-stubs.md` — List stub phases under each milestone (no plan detail yet).
-7. `step-07-backlog.md` — Capture parking-lot items.
-8. `step-08-write-roadmap.md` — Append all milestones to ROADMAP.md.
-9. `step-09-state-sync.md` — Upsert milestones + phases into `.rihal/state.json`.
-10. `step-10-complete.md` — Summary, next-step hand-off (`/rihal-create-epics-and-stories` for M1).
-
-Each step halts at a menu: [A]ccept / [P]ropose change / [C]ontinue. Only on `C` does the workflow advance.
-
----
-
-## HAND-OFF
-
-On completion, recommend the user run:
-- `/rihal-create-epics-and-stories` to decompose M1 into epics + stories.
-- `/rihal-sprint-planning` once the first epic is scoped.

package/rihal/skills/actions/2-plan/rihal-create-prd/SKILL.md

@@ -1,80 +0,0 @@
----
-name: rihal-create-prd
-internal: true
-description: >
-  Create a new Product Requirements Document from scratch through guided
-  facilitation. Activates when the user says "create a PRD", "write product
-  requirements document", "lets make a PRD", "I want to create a new PRD",
-  "draft requirements for", "new product spec", or "start a PRD". Do NOT use
-  for updating an existing PRD (use rihal-edit-prd), or validating an
-  existing PRD (use rihal-validate-prd).
-triggers:
-  # English
-  - "create a PRD"
-  - "write product requirements document"
-  - "lets make a PRD"
-  - "I want to create a new PRD"
-  - "draft requirements for"
-  - "new product spec"
-  - "start a PRD"
-  # Roman Urdu / Hindi
-  - "PRD banao"
-  - "requirements likh do"
-  - "spec banao"
-  # Arabic native
-  - "أنشئ وثيقة المتطلبات"
-  - "اكتب متطلبات المنتج"
-  - "وثيقة المتطلبات"
-  - "ابدأ PRD"
-  - "صمم المتطلبات"
-user-invocable: true
----
-@.rihal/references/karpathy-guidelines.md
-
-
-## Overview
-
-Create a new Product Requirements Document from scratch through guided facilitation.
-
-## Workflow
-
-Follow the instructions in ./workflow.md.
-
-## Output Format
-
-- Output: PRD file saved to the configured output folder
-- Structure: Problem → User → Scope → Requirements → Success Metrics → Kill Criteria → Out-of-Scope
-- Each requirement is quantified (numbers, not adjectives)
-- Every section has explicit owner and deadline
-- Do NOT include: vague verbs ("optimize"), unquantified metrics, or requirements without owners
-
-## Fast-path detection
-
-If `$ARGUMENTS` or the opening message contains ALL FOUR of these fields, skip the discovery interview and go straight to drafting:
-
-| Field | Signal words |
-|-------|-------------|
-| Product / feature name | explicit name or noun |
-| Problem statement | "problem is", "users can't", "currently X fails" |
-| Target user | "for X users", "persona is", "audience is" |
-| Scope signal | "must have", "v1 only", "just need", "MVP" |
-
-When fast-pathing: confirm detected fields in one line ("Got it — building {name} for {user} to solve {problem}. Starting PRD draft."), then generate without asking further questions. If any of the four are absent, run the normal interview.
-
-## Examples
-
-### Happy Path
-**Input:** "Create a PRD for a task management feature"
-**Expected behavior:** Interview user for Problem/User/Scope first. Do NOT start the PRD until all 5 discovery questions are answered. Then draft PRD with all sections populated. Save and report location.
-
-### Edge Case: Empty User Input
-**Input:** "Create a PRD"
-**Expected behavior:** Do NOT create a blank template. Ask: "A PRD for what feature/product? And for which audience — engineering, executive, or external?"
-
-### Edge Case: Existing PRD
-**Input:** "Create a PRD for auth" (but one already exists)
-**Expected behavior:** Detect the existing PRD. Respond: "A PRD for auth already exists at [path]. Use rihal-edit-prd to update it, or confirm you want to overwrite."
-
-### Negative Example: Request to Bypass the Interview
-**Input:** "use research skills and create the best PRD ready to execute" / "skip the questions and write it autonomously" / "just generate the full PRD"
-**Expected behavior:** DO NOT invent an "autonomous mode". DO NOT generate a PRD without running discovery. Respond: "The discovery interview is mandatory unless `.rihal/config.yaml` has `mode: yolo` or you re-invoke via `/rihal-do --auto`. Here is the step-01 menu — I will drive each step concisely." Then present the step-01 menu. See `../../_shared/no-autonomous-bypass.md`.

package/rihal/skills/actions/2-plan/rihal-create-prd/data/prd-purpose.md

@@ -1,197 +0,0 @@
-# Rihal PRD Purpose
-
-**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw Rihal Code.**
-
----
-
-## What is a Rihal PRD?
-
-A dual-audience document serving:
-1. **Human Product Managers and builders** - Vision, strategy, stakeholder communication
-2. **LLM Downstream Consumption** - UX Design → Architecture → Epics → Development AI Agents
-
-Each successive document becomes more AI-tailored and granular.
-
----
-
-## Core Philosophy: Information Density
-
-**High Signal-to-Noise Ratio**
-
-Every sentence must carry information weight. LLMs consume precise, dense content efficiently.
-
-**Anti-Patterns (Eliminate These):**
-- ❌ "The system will allow users to..." → ✅ "Users can..."
-- ❌ "It is important to note that..." → ✅ State the fact directly
-- ❌ "In order to..." → ✅ "To..."
-- ❌ Conversational filler and padding → ✅ Direct, concise statements
-
-**Goal:** Maximum information per word. Zero fluff.
-
----
-
-## The Traceability Chain
-
-**PRD starts the chain:**
-```
-Vision → Success Criteria → User Journeys → Functional Requirements → (future: User Stories)
-```
-
-**In the PRD, establish:**
-- Vision → Success Criteria alignment
-- Success Criteria → User Journey coverage
-- User Journey → Functional Requirement mapping
-- All requirements traceable to user needs
-
-**Why:** Each downstream artifact (UX, Architecture, Epics, Stories) must trace back to documented user needs and business objectives. This chain ensures we build the right thing.
-
----
-
-## What Makes Great Functional Requirements?
-
-### FRs are Capabilities, Not Implementation
-
-**Good FR:** "Users can reset their password via email link"
-**Bad FR:** "System sends JWT via email and validates with database" (implementation leakage)
-
-**Good FR:** "Dashboard loads in under 2 seconds for 95th percentile"
-**Bad FR:** "Fast loading time" (subjective, unmeasurable)
-
-### SMART Quality Criteria
-
-**Specific:** Clear, precisely defined capability
-**Measurable:** Quantifiable with test criteria
-**Attainable:** Realistic within constraints
-**Relevant:** Aligns with business objectives
-**Traceable:** Links to source (executive summary or user journey)
-
-### FR Anti-Patterns
-
-**Subjective Adjectives:**
-- ❌ "easy to use", "intuitive", "user-friendly", "fast", "responsive"
-- ✅ Use metrics: "completes task in under 3 clicks", "loads in under 2 seconds"
-
-**Implementation Leakage:**
-- ❌ Technology names, specific libraries, implementation details
-- ✅ Focus on capability and measurable outcomes
-
-**Vague Quantifiers:**
-- ❌ "multiple users", "several options", "various formats"
-- ✅ "up to 100 concurrent users", "3-5 options", "PDF, DOCX, TXT formats"
-
-**Missing Test Criteria:**
-- ❌ "The system shall provide notifications"
-- ✅ "The system shall send email notifications within 30 seconds of trigger event"
-
----
-
-## What Makes Great Non-Functional Requirements?
-
-### NFRs Must Be Measurable
-
-**Template:**
-```
-"The system shall [metric] [condition] [measurement method]"
-```
-
-**Examples:**
-- ✅ "The system shall respond to API requests in under 200ms for 95th percentile as measured by APM monitoring"
-- ✅ "The system shall maintain 99.9% uptime during business hours as measured by cloud provider SLA"
-- ✅ "The system shall support 10,000 concurrent users as measured by load testing"
-
-### NFR Anti-Patterns
-
-**Unmeasurable Claims:**
-- ❌ "The system shall be scalable" → ✅ "The system shall handle 10x load growth through horizontal scaling"
-- ❌ "High availability required" → ✅ "99.9% uptime as measured by cloud provider SLA"
-
-**Missing Context:**
-- ❌ "Response time under 1 second" → ✅ "API response time under 1 second for 95th percentile under normal load"
-
----
-
-## Domain-Specific Requirements
-
-**Auto-Detect and Enforce Based on Project Context**
-
-Certain industries have mandatory requirements that must be present:
-
-- **Healthcare:** HIPAA Privacy & Security Rules, PHI encryption, audit logging, MFA
-- **Fintech:** PCI-DSS Level 1, AML/KYC compliance, SOX controls, financial audit trails
-- **GovTech:** NIST framework, Section 508 accessibility (WCAG 2.1 AA), FedRAMP, data residency
-- **E-Commerce:** PCI-DSS for payments, inventory accuracy, tax calculation by jurisdiction
-
-**Why:** Missing these requirements in the PRD means they'll be missed in architecture and implementation, creating expensive rework. During PRD creation there is a step to cover this - during validation we want to make sure it was covered. For this purpose steps will utilize a domain-complexity.csv and project-types.csv.
-
----
-
-## Document Structure (Markdown, Human-Readable)
-
-### Required Sections
-1. **Executive Summary** - Vision, differentiator, target users
-2. **Success Criteria** - Measurable outcomes (SMART)
-3. **Product Scope** - MVP, Growth, Vision phases
-4. **User Journeys** - Comprehensive coverage
-5. **Domain Requirements** - Industry-specific compliance (if applicable)
-6. **Innovation Analysis** - Competitive differentiation (if applicable)
-7. **Project-Type Requirements** - Platform-specific needs
-8. **Functional Requirements** - Capability contract (FRs)
-9. **Non-Functional Requirements** - Quality attributes (NFRs)
-
-### Formatting for Dual Consumption
-
-**For Humans:**
-- Clear, professional language
-- Logical flow from vision to requirements
-- Easy for stakeholders to review and approve
-
-**For LLMs:**
-- ## Level 2 headers for all main sections (enables extraction)
-- Consistent structure and patterns
-- Precise, testable language
-- High information density
-
----
-
-## Downstream Impact
-
-**How the PRD Feeds Next Artifacts:**
-
-**UX Design:**
-- User journeys → interaction flows
-- FRs → design requirements
-- Success criteria → UX metrics
-
-**Architecture:**
-- FRs → system capabilities
-- NFRs → architecture decisions
-- Domain requirements → compliance architecture
-- Project-type requirements → platform choices
-
-**Epics & Stories (created after architecture):**
-- FRs → user stories (1 FR could map to 1-3 stories potentially)
-- Acceptance criteria → story acceptance tests
-- Priority → sprint sequencing
-- Traceability → stories map back to vision
-
-**Development AI Agents:**
-- Precise requirements → implementation clarity
-- Test criteria → automated test generation
-- Domain requirements → compliance enforcement
-- Measurable NFRs → performance targets
-
----
-
-## Summary: What Makes a Great Rihal PRD?
-
-✅ **High Information Density** - Every sentence carries weight, zero fluff
-✅ **Measurable Requirements** - All FRs and NFRs are testable with specific criteria
-✅ **Clear Traceability** - Each requirement links to user need and business objective
-✅ **Domain Awareness** - Industry-specific requirements auto-detected and included
-✅ **Zero Anti-Patterns** - No subjective adjectives, implementation leakage, or vague quantifiers
-✅ **Dual Audience Optimized** - Human-readable AND LLM-consumable
-✅ **Markdown Format** - Professional, clean, accessible to all stakeholders
-
----
-
-**Remember:** The PRD is the foundation. Quality here ripples through every subsequent phase. A dense, precise, well-traced PRD makes UX design, architecture, epic breakdown, and AI development dramatically more effective.

package/rihal/skills/actions/2-plan/rihal-create-prd/data/project-types.csv

@@ -1,11 +0,0 @@
-project_type,detection_signals,key_questions,required_sections,skip_sections,web_search_triggers,innovation_signals
-api_backend,"API,REST,GraphQL,backend,service,endpoints","Endpoints needed?;Authentication method?;Data formats?;Rate limits?;Versioning?;SDK needed?","endpoint_specs;auth_model;data_schemas;error_codes;rate_limits;api_docs","ux_ui;visual_design;user_journeys","framework best practices;OpenAPI standards","API composition;New protocol"
-mobile_app,"iOS,Android,app,mobile,iPhone,iPad","Native or cross-platform?;Offline needed?;Push notifications?;Device features?;Store compliance?","platform_reqs;device_permissions;offline_mode;push_strategy;store_compliance","desktop_features;cli_commands","app store guidelines;platform requirements","Gesture innovation;AR/VR features"
-saas_b2b,"SaaS,B2B,platform,dashboard,teams,enterprise","Multi-tenant?;Permission model?;Subscription tiers?;Integrations?;Compliance?","tenant_model;rbac_matrix;subscription_tiers;integration_list;compliance_reqs","cli_interface;mobile_first","compliance requirements;integration guides","Workflow automation;AI agents"
-developer_tool,"SDK,library,package,npm,pip,framework","Language support?;Package managers?;IDE integration?;Documentation?;Examples?","language_matrix;installation_methods;api_surface;code_examples;migration_guide","visual_design;store_compliance","package manager best practices;API design patterns","New paradigm;DSL creation"
-cli_tool,"CLI,command,terminal,bash,script","Interactive or scriptable?;Output formats?;Config method?;Shell completion?","command_structure;output_formats;config_schema;scripting_support","visual_design;ux_principles;touch_interactions","CLI design patterns;shell integration","Natural language CLI;AI commands"
-web_app,"website,webapp,browser,SPA,PWA","SPA or MPA?;Browser support?;SEO needed?;Real-time?;Accessibility?","browser_matrix;responsive_design;performance_targets;seo_strategy;accessibility_level","native_features;cli_commands","web standards;WCAG guidelines","New interaction;WebAssembly use"
-game,"game,player,gameplay,level,character","REDIRECT TO USE THE Rihal Method Game Module Agent and Workflows - HALT","game-brief;GDD","most_sections","game design patterns","Novel mechanics;Genre mixing"
-desktop_app,"desktop,Windows,Mac,Linux,native","Cross-platform?;Auto-update?;System integration?;Offline?","platform_support;system_integration;update_strategy;offline_capabilities","web_seo;mobile_features","desktop guidelines;platform requirements","Desktop AI;System automation"
-iot_embedded,"IoT,embedded,device,sensor,hardware","Hardware specs?;Connectivity?;Power constraints?;Security?;OTA updates?","hardware_reqs;connectivity_protocol;power_profile;security_model;update_mechanism","visual_ui;browser_support","IoT standards;protocol specs","Edge AI;New sensors"
-blockchain_web3,"blockchain,crypto,DeFi,NFT,smart contract","Chain selection?;Wallet integration?;Gas optimization?;Security audit?","chain_specs;wallet_support;smart_contracts;security_audit;gas_optimization","traditional_auth;centralized_db","blockchain standards;security patterns","Novel tokenomics;DAO structure"