START HERE. Unified entry point for the RC Engine pipeline. Call this when starting a new project, resuming where you left off, or checking project status. Responds to: "rc_init", "resume project", "continue building", "where did I leave off", "pick up where I left off", "what's next", "continue from where I stopped". Detects your project state across all domains (Pre-RC, RC, Post-RC, Traceability) and tells you exactly which tool to call next. Defaults to Pre-RC research (prc_start) for new projects - because research comes before building.

FIRST STEP of Pre-RC research. Call when the user describes a product idea and you want deep research before building. Creates the pre-rc-research/ directory and initializes project state. Prerequisites: none - this is the entry point. After success: MUST call prc_classify next. Never skip to prc_run_stage without classifying first.

Call AFTER prc_start. Classifies the product idea using Cynefin framework (Clear/Complicated/Complex/Chaotic) and activates the appropriate subset of 20 research specialists. Returns: complexity domain, activated specialist list, estimated cost budget, and which stages to run. After success: present the classification to the user as Checkpoint 1 - call prc_gate with their decision. Read-only analysis, no side effects beyond state update.

Submit a checkpoint decision for the current Pre-RC research stage. NEVER call without presenting the checkpoint context to the user first and getting their explicit decision. Three checkpoints exist: Checkpoint 1 (after classify - is research scope right?), Checkpoint 2 (after stages 1-4 - is research accurate?), Checkpoint 3 (after all stages - ready to build?). Valid decisions: "approve" to proceed, "reject" with feedback to revise, "question" to pause for clarification. After approve: proceed to next stage or prc_synthesize (after Checkpoint 3). After reject: re-run the relevant stage with user feedback.

Re-run a specific research stage. In normal flow, stages execute automatically when you approve a checkpoint via prc_gate. Use this tool ONLY to re-run a failed or incomplete stage. Valid stages: "stage-1-meta", "stage-2-user-intelligence", "stage-3-business-market" (uses web search), "stage-4-technical", "stage-5-ux-cognitive", "stage-6-validation". Prerequisites: prc_classify must be complete and relevant checkpoints approved. Returns research specialist results with success/failure markers.

Check Pre-RC research progress. Read-only, safe to call anytime. Returns: current stage, completed stages, gate statuses, persona results, token usage. Use this to orient yourself when resuming a session or when the user asks "where are we?" Call this BEFORE deciding which prc_ tool to call next if you are unsure of the current state.

FINAL STEP of Pre-RC. Call ONLY after Gate 3 is approved (all 6 stages complete). Synthesizes all persona research into deliverables: 19-section PRD (markdown), HTML consulting deck, task list, DOCX document, and research index. LONG-RUNNING: involves multiple LLM calls for synthesis. Set include_task_deck=true to also generate a visual task breakdown deck. After success: present deliverables to user. To continue into RC Method, call rc_import_prerc. This is a natural stopping point - user may choose to stop here with just the PRD.

OPTIONAL Pro-tier tool. Call AFTER prc_synthesize to stress-test the product idea before building. Runs a VC-level devil's advocate analysis: challenges market assumptions, fact-checks claims with live web data, evaluates business model, technical risk, and differentiation. Returns GO/NO-GO/CONDITIONAL verdict with confidence score. LONG-RUNNING: involves 3 LLM calls (analysis, web fact-check, verdict synthesis). Prerequisites: Gate 3 approved, prc_synthesize complete. After success: present the verdict to the user. If GO or CONDITIONAL (with conditions met), proceed to rc_import_prerc. If NO-GO, discuss alternatives with the user.

BRIDGE from Pre-RC to RC Method. Call after prc_synthesize completes and user wants to continue building. Converts the 19-section Pre-RC PRD to 11-section RC format, auto-approves Phases 1-2, and advances to Phase 3 (Architect). Prerequisites: pre-rc-research/ directory must exist with Gate 3 approved. After success: call rc_architect to begin technical design. Skips rc_start/rc_illuminate/rc_define since Pre-RC already covered discovery and requirements.

Start RC Method WITHOUT Pre-RC research. Use when user wants to go straight to building without the 20-persona research phase. Creates rc-method/ directory and project state, begins Phase 1 (Illuminate) with discovery questions. Returns discovery questions - present these to the user and collect their answers. After success: call rc_illuminate with user answers. Do NOT use this if Pre-RC was run - use rc_import_prerc instead.

Phase 1 (Illuminate). Call after rc_start, passing the user's answers to discovery questions. Generates an Illuminate Report summarizing the problem space, users, and constraints. Returns report + gate prompt. Present the report to the user and ask for approval via rc_gate. Prerequisites: must be in Phase 1. After gate approval: moves to Phase 2 (Define).

Phase 2 (Define). Generates a Product Requirements Document from user-provided feature descriptions, user stories, and requirements. Produces an 11-section PRD saved to rc-method/prds/. Returns PRD content + gate prompt. Present the PRD to the user for review. Prerequisites: Phase 1 gate approved. After gate approval: moves to Phase 3 (Architect). Consider running ux_score on the feature list and ux_generate for UX-heavy products.

Phase 3 (Architect). Defines technical architecture: tech stack, data models, API design, integrations, and infrastructure. Pass the user's technical preferences or constraints in architecture_notes (e.g., "use Next.js and Supabase", "must integrate with Stripe"). Returns architecture document + gate prompt. Prerequisites: Phase 2 gate approved (or Phase 1-2 auto-approved via rc_import_prerc). After gate approval: moves to Phase 4 (Sequence).

Phase 4 (Sequence). Auto-generates a sequenced, dependency-ordered task list from the approved PRD and architecture. Each task gets an ID (TASK-001, TASK-002...) with estimated effort and dependencies. Saved to rc-method/tasks/. No user input needed - reads PRD artifacts automatically. Present the task list to user for approval. Prerequisites: Phase 3 gate approved. After gate approval: moves to Phase 5 (Validate).

Phase 5 (Validate). QUALITY GATE before building. Runs 4 automated checks: anti-pattern scan, token budget audit, scope drift detection, and UX quality assessment. This catches problems BEFORE code is written - saving significant rework. No user input needed. Present findings to user with severity ratings. Prerequisites: Phase 4 gate approved. After gate approval: moves to Phase 6 (Forge) - begin building with rc_forge_task.

Phase 6 (Forge). Call once per task from the approved task list. Loads the PRD, architecture, and task context, then generates implementation guidance for the specified task_id (e.g., "TASK-001"). Call this for EACH task in sequence, respecting dependency order. Prerequisites: Phase 5 gate approved, valid task_id from the task list. After ALL tasks complete: proceed to Phase 7 (Connect) via rc_gate, then run postrc_scan for security validation. Present each task result to user before moving to the next.

Phase 7 (Connect). Verifies that all built components integrate correctly. Reviews forge outputs for API wiring, authentication flows, data model alignment, and cross-component dependencies. Generates an integration report with gaps and recommended integration tests. No user input needed - reads forge artifacts automatically. Prerequisites: Phase 6 gate approved. After gate approval: moves to Phase 8 (Compound).

Phase 8 (Compound). Final phase before ship. Assesses production readiness: NFR compliance, error handling, observability, performance, security hardening, and deployment configuration. Cross-references integration report from Phase 7. Produces a ship checklist and go/no-go assessment. Prerequisites: Phase 7 gate approved. After gate approval: pipeline complete, proceed to postrc_scan for security validation.

Phase 6 (Forge) BATCH MODE. Builds ALL pending tasks from the approved task list in one call, respecting dependency order. Equivalent to calling rc_forge_task for each task sequentially. If a task fails, it is recorded as failed and the next task continues. Returns a summary of all tasks with success/failure status. Prerequisites: Phase 5 gate approved, task list must exist in rc-method/tasks/. After completion: proceed to rc_gate to approve Phase 6, then rc_connect for integration check.

Run remaining RC Method steps automatically from the current step through Step 8 (Production Hardening). Auto-approves checkpoints between steps with a note that they were auto-approved. IMPORTANT: Does NOT auto-approve the Post-RC ship decision - that always requires human review. Use when the user wants to fast-track the build pipeline. If any step fails, stops and reports where it stopped. Prerequisites: at least rc_start or rc_import_prerc must have been called. Not recommended for first-time users - prefer step-by-step flow.

Submit user's checkpoint decision for the current RC Method step. NEVER call without first presenting the step output to the user and getting their explicit approval. Valid decisions: "approve" advances to next step, "reject" stays at current step (include reason in feedback), "question" pauses for clarification. Checkpoints exist after all 8 steps. Step 6 (Build) checkpoint fires after all tasks are complete. After approve: the next step tool becomes available. After reject: re-run the current step tool with adjusted inputs.

PASSTHROUGH MODE ONLY. Save an artifact generated by the host IDE (not by RC Engine tools) into the RC Method file structure. Use when the IDE's own AI generated a PRD, UX PRD, or task list that should be tracked by RC Method. Types: "prd" saves to rc-method/prds/, "prd-ux" saves UX child PRD, "tasks" saves task list. Do NOT use this for artifacts already saved by rc_define, rc_sequence, or ux_generate - those tools save automatically.

Check RC Method progress. Read-only, safe to call anytime. Returns: current phase (1-8), gate statuses (approved/pending/rejected), saved artifacts list, and UX score if scored. Use this to orient yourself when resuming a session, when the user asks "where are we?", or before deciding which rc_ tool to call next. Also useful to verify a gate was recorded after calling rc_gate.

Reset RC Method pipeline state. Clears checkpoint store and markdown state file, allowing a fresh rc_start. DESTRUCTIVE - requires explicit confirmation. Use when the user wants to start over or abandon current progress. After success: pipeline is clean, call rc_start or rc_init to begin again.

OPTIONAL - call during Phase 2 (Define) to assess UX complexity. Pass the feature list from the PRD. Returns: numeric score, mode (standard/selective/deep_dive), and which UX specialist modules to load. Use the result to decide whether to call ux_generate (for deep_dive/selective) or skip UX child PRD (for standard). Does NOT require project_path - works on any feature list. Read-only analysis.

Audit UI code or a screen description against 42 core UX rules plus specialist modules. Call during or after Forge (Phase 6) to check implementation quality. task_type controls which specialist modules load: form, dashboard, onboarding, admin, payment, component_library, content, navigation, or "audit" to load all. Returns findings with severity, rule citations, and fix suggestions. Use this to catch UX issues before postrc_scan.

Generate a UX child PRD (PRD-[project]-ux.md). Call during Phase 2 (Define) if ux_score returned selective or deep_dive mode. Produces: screen inventory, state contracts, component inventory, copy inventory, and accessibility checklist. Saved alongside the main PRD in rc-method/prds/. Pass descriptions of the screens and user flows. After success: the UX PRD is used by rc_validate (Phase 5) for UX quality checks and by rc_forge_task for implementation guidance.

Generate visual design options with HTML wireframes. Call after PRD is created (Phase 2+). Produces 1 or 3 design options based on ICP, competitor gaps, and design trends. Each option includes a design spec (colors, typography, layout) and self-contained HTML wireframes (lo-fi + hi-fi). Saves to rc-method/design/. Pass option_count=1 for budget-conscious, option_count=3 for full comparison.

Stress-test design options against 5 lenses: ICP alignment, copy quality, design justification, conversion flow, and accessibility. Call after ux_design generates options. Returns findings by severity with specific fixes. After success: present findings to user, then proceed to design_select or design_iterate.

Generate a Copy Research Brief: VOC phrase bank, awareness mapping, JTBD extraction, objection mapping, competitive copy audit, and persuasion framework selection. Call during Phase 2 (Define) AFTER the Design Research Brief. The brief feeds into copy_generate and ux_design. Requires project_path and PRD context.

Generate the full Content Strategy & Copy System: voice/tone, page-level copy with variants, microcopy library, CTA matrix, and SEO content map. Call AFTER copy_research_brief. Requires the screen inventory (list of screen names). Saves to rc-method/copy/COPY-SYSTEM.md.

Iterate on the generated copy system with user feedback. Updates the COPY-SYSTEM.md in place. Optionally target specific screens for revision.

Self-critique the generated copy system against conversion heuristics. Scores across 7 categories: Clarity (25%), Persuasion Framework (20%), Behavioral Design (15%), Voice & Tone (15%), Microcopy (10%), Specificity (10%), SEO (5%). Returns weighted score with verdict: SHIP (4.0+), REVISE (3.0-3.9), or REWRITE (<3.0). Call AFTER copy_generate. Loads the COPY-SYSTEM.md artifact automatically.

Generate a Design Research Brief during Phase 2 (Define). Analyzes ICP, competitors, and brand constraints to produce research-backed design direction. Output: ICP design profile, competitive design landscape, emotional design strategy, information architecture, cognitive design principles, trend recommendations, and design constraints. Saves to rc-method/design/DESIGN-RESEARCH-BRIEF.md. Call AFTER prd is created.

Run the Design Intake Assessment - the FIRST step of the Design Intelligence pipeline after PRD. Captures comprehensive user design preferences: brand identity, colors, typography, layout, mood, animation, component styles, platform targets, accessibility requirements, competitor intelligence, and screen inventory. Evaluates all inputs against ICP expectations. Returns alignment score (0-100), verdict (proceed/proceed_with_adjustments/reconsider), and extracted design constraints that feed into every downstream design tool. Saves to rc-method/design/DESIGN-INTAKE.md.

Import brand assets during Phase 1 (Illuminate). Auto-detects colors, fonts, and design tokens from project files (tailwind config, CSS variables, constants/). Optionally scrapes a URL for brand signals. Produces a normalized BrandProfile saved to rc-method/design/BRAND-PROFILE.json. The profile is consumed by design_research_brief, ux_design, and copy_generate for brand consistency.

Iterate on existing wireframes based on user feedback. Loads the current design spec and regenerates wireframes for specified screens (or all screens) applying the feedback. Maintains design system consistency. Requires ux_design to have been run first.

Select a design option after reviewing ux_design output. Saves the selected option ID to project state so that design_iterate, design_challenge, and code generation know which option to use. REQUIRED for Deep Dive mode (UX score >= 7) before Gate 2 can be approved.

Run the full Design Intelligence pipeline in sequence: brand_import → design_intake → design_research_brief → copy_research + copy_generate → ux_design → auto-select → design_challenge. Requires PRD to exist (run rc_define first). Captures user design preferences via design_intake, generates real copy, then produces research-backed design options with wireframes using that copy. Returns a combined report with all artifacts. Each step can also be called individually for more control.

Generate the Project Playbook / Architecture Decision Record (ARD). Aggregates ALL pipeline outputs - research, PRD, design decisions, architecture, implementation plan, quality/security findings, traceability matrix - into a single comprehensive markdown document. This is the master deliverable that a non-technical user can hand to a development team. Saves to rc-method/PLAYBOOK-{name}.md. Requires at least one pipeline phase to have been completed.

Export project artifacts as a professional, print-ready HTML document. Converts one or more markdown files into styled HTML with a cover page, section headers, and @media print rules. Users open the HTML in a browser and use Cmd+P / Ctrl+P to save as PDF. Supports any markdown file in the project (PRDs, playbook, design briefs, reports). Saves the HTML to rc-method/exports/.

Generate architecture diagrams from the task list. Produces 3 Mermaid-based HTML diagrams: dependency graph (task DAG), Gantt timeline (build schedule), and architecture layers (swimlane view). Requires rc_sequence to have been run first (needs task list in rc-method/tasks/). Saves to rc-method/diagrams/. After success: diagrams are viewable in any browser.

[Pro] Run AFTER building (Phase 6 Forge complete). Scans code for security vulnerabilities, checks monitoring instrumentation, and optionally runs legal compliance review (Pro tier - enable via postrc_configure with legal_enabled=true). Pass code_context with the actual project code. Returns findings by severity (critical/high/medium/low) with CWE/legal references. LONG-RUNNING: involves LLM analysis. After success: present findings to user in plain language. Then call postrc_gate for ship/no-ship decision. If critical findings exist, also generates REMEDIATION-TASKS file.

[Pro] Override a specific scan finding when the user accepts the risk. Requires: finding_id (from postrc_scan results) and justification (why this is acceptable). Creates an immutable audit record. Use when postrc_gate is blocked by a finding the user wants to accept. ALWAYS warn the user if overriding critical/high severity - explain the risk in plain language. Optionally set an expiration date. After override: re-run postrc_gate to re-evaluate ship decision.

[Pro] Generate a formal validation report from scan results. Call after postrc_scan to produce a shareable markdown document with: findings summary, severity breakdown, override records, and remediation recommendations. Useful for stakeholders, compliance, or audit trails. Saved to post-rc/. Read-only - does not modify scan state.

[Pro] OPTIONAL - configure validation policy BEFORE running postrc_scan. Sets: which modules are active (security, monitoring, legal-claims, legal-product), whether to block on critical/high findings, CWE suppressions (known false positives), monitoring requirements, and legal review settings (Pro tier: product domain, jurisdiction, license/accessibility checks). Defaults are reasonable - only call this if the user has specific compliance or risk tolerance requirements. Saved to post-rc/ state.

[Pro] Final checkpoint - ship/no-ship decision. Call after postrc_scan completes and user has reviewed findings. NEVER auto-approve - always present findings summary first. Returns PASS (safe to ship), WARN (issues exist but not blocking), or BLOCK (critical issues must be fixed or overridden). If BLOCK: user must either fix issues and re-scan, or use postrc_override to accept risks. After PASS/approved: pipeline is complete for the build phase. Consider running trace_map_findings next for coverage metrics.

Check Post-RC validation progress. Read-only, safe to call anytime. Returns: active modules, latest scan ID and findings count, override count, and gate status. Use this to orient yourself when resuming a session or when the user asks about validation status. Call before postrc_gate if you need to verify scan results are available.

PRE-FLIGHT tool - run BEFORE RC Method build phase, ideally after rc_define (Phase 2). Generates an observability requirements document from the PRD: error tracking setup, analytics events, SLO definitions, dashboard specs, and alerting rules. This ensures monitoring is designed in, not bolted on after shipping. Output feeds into rc_architect as a companion to the PRD. Optional but strongly recommended for production applications.

Assign tracking IDs to every requirement in the PRD. Call after PRD is created (rc_define or prc_synthesize) and BEFORE building. Auto-discovers PRDs in both pre-rc-research/ and rc-method/prds/. Assigns deterministic IDs by category: PRD-FUNC-001, PRD-SEC-001, PRD-PERF-001, etc. (8 categories). In autonomous mode, also generates testable acceptance criteria. Creates the traceability matrix in rc-traceability/. After success: tell user how many requirements were tagged by category. Does NOT modify the original PRD - creates an enhanced copy.

Run AFTER both building (Forge) and scanning (postrc_scan). Maps Post-RC findings and RC task completions back to the requirement IDs from trace_enhance_prd. Calculates: implementation coverage %, verification coverage %, orphan requirements (specified but never built), and orphan tasks (built but not in PRD). Generates a consulting-grade HTML traceability report. Prerequisites: trace_enhance_prd must have been run, and ideally postrc_scan completed. Present coverage gaps to user - orphan requirements are the most critical signal.

Check traceability coverage. Read-only, safe to call anytime after trace_enhance_prd. Returns: total requirements, implemented count, verified count, coverage percentages, orphan lists. Use when user asks "what percentage is done?" or "what did we miss?" Also useful mid-build to track progress against requirements.

High-level overview of the entire pipeline. Read-only, safe to call anytime. Shows token usage totals and registered domain summary. Call this FIRST when starting a new session to orient yourself, or when the user asks for a big-picture status. For detailed per-domain progress, follow up with the domain-specific status tools: prc_status, rc_status, postrc_status, trace_status.