@hanzlaa/rcode 3.6.16 → 4.0.0

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

@@ -0,0 +1,56 @@
+# 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 `/rcode-plan` later.
+
+## MANDATORY RULES
+
+- 🛑 Phase numbers follow rcode's NN convention (01, 02, ..., 99, then 999.x for parking lot).
+- 🛑 Do NOT generate plan content here. That's `/rcode-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/rcode/skills/actions/2-plan/rcode-create-milestone/steps/step-07-backlog.md

@@ -0,0 +1,44 @@
+# 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 rcode's `999.x` parking-lot convention so items can be promoted later via `/rcode-plant-seed` or `/rcode-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 /rcode-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/rcode/skills/actions/2-plan/rcode-create-milestone/steps/step-08-write-roadmap.md

@@ -0,0 +1,58 @@
+# 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 rcode 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/rcode/skills/actions/2-plan/rcode-create-milestone/steps/step-09-state-sync.md

@@ -0,0 +1,62 @@
+# Step 9: Sync ROADMAP into state.json
+
+**Progress: Step 9 of 10** — Next: Completion summary
+
+## STEP GOAL
+
+Call the state-sync CLI so `.rcode/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 `/rcode-status` and `/rcode-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 .rcode/bin/rcode-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 /rcode-create-epics-and-stories next)
+```
+
+### 3. Verify drift closed
+
+Run a sanity check:
+
+```bash
+node .rcode/bin/rcode-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/rcode/skills/actions/2-plan/rcode-create-milestone/steps/step-10-complete.md

@@ -0,0 +1,56 @@
+# 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:          .rcode/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
+      → /rcode-create-epics-and-stories
+
+  [B] Plan the first phase in detail
+      → /rcode-plan 01
+
+  [C] Review the roadmap with the team
+      → /rcode-council "Is this roadmap realistic?"
+
+  [D] Park and review later
+      → Roadmap is saved; pick up with /rcode-progress anytime
+```
+
+### 4. HALT
+
+This is the terminal step. Do NOT load another step file. The workflow is complete.

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

@@ -0,0 +1,93 @@
+---
+main_config: '{project-root}/.rcode/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 `.rcode/config.yaml` → `mode: yolo` or `/rcode-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 `.rcode/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 `/rcode-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 `.rcode/state.json`.
+10. `step-10-complete.md` — Summary, next-step hand-off (`/rcode-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:
+- `/rcode-create-epics-and-stories` to decompose M1 into epics + stories.
+- `/rcode-sprint-planning` once the first epic is scoped.

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

@@ -0,0 +1,80 @@
+---
+name: rcode-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 rcode-edit-prd), or validating an
+  existing PRD (use rcode-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
+---
+@.rcode/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 rcode-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 `.rcode/config.yaml` has `mode: yolo` or you re-invoke via `/rcode-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/rcode/skills/actions/2-plan/rcode-create-prd/data/prd-purpose.md

@@ -0,0 +1,197 @@
+# rcode PRD Purpose
+
+**The PRD is the top of the required funnel that feeds all subsequent product development work in rhw rcode.**
+
+---
+
+## What is a rcode 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 rcode 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/rcode/skills/actions/2-plan/rcode-create-prd/data/project-types.csv

@@ -0,0 +1,11 @@
+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 rcode 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"