@baselane/packs 0.1.5 → 0.1.7

package/packs/full-harness/rendered/.claude/commands/multi-frontend.md

@@ -0,0 +1,6 @@
+---
+description: Run a frontend-focused multi-model workflow for components, layouts, animation, and UI polish.
+argument-hint: [optional arguments]
+---
+
+# Frontend - Frontend-Focused Development Frontend-focused workflow (Research → Ideation → Plan → Execute → Optimize → Review), Gemini-led. > **Prerequisite:** Requires the external `ccg-workflow` runtime, which is **not** part of the base ECC install. Initialize it with `npx ccg-workflow` to provision `~/.claude/bin/codeagent-wrapper` and the `~/.claude/.ccg/prompts/*` role files this command depends on. Without that runtime, this command will not run correctly. ## Usage ```bash /frontend <UI task description> ``` ## Context - Frontend task: $ARGUMENTS - Gemini-led, Codex for auxiliary reference - Applicable: Component design, responsive layout, UI animations, style optimization ## Your Role You are the **Frontend Orchestrator**, coordinating multi-model collaboration for UI/UX tasks (Research → Ideation → Plan → Execute → Optimize → Review). **Collaborative Models**: - **Gemini** – Frontend UI/UX (**Frontend authority, trustworthy**) - **Codex** – Backend perspective (**Frontend opinions for reference only**) - **Claude (self)** – Orchestration, planning, execution, delivery --- ## Multi-Model Call Specification **Call Syntax**: ``` # New session call Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview - \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)> Context: <project context and analysis from previous phases> </TASK> OUTPUT: Expected output format EOF", run_in_background: false, timeout: 3600000, description: "Brief description" }) # Resume session call Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend gemini --gemini-model gemini-3-pro-preview resume <SESSION_ID> - \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)> Context: <project context and analysis from previous phases> </TASK> OUTPUT: Expected output format EOF", run_in_background: false, timeout: 3600000, description: "Brief description" }) ``` **Role Prompts**: | Phase | Gemini | |-------|--------| | Analysis | `~/.claude/.ccg/prompts/gemini/analyzer.md` | | Planning | `~/.claude/.ccg/prompts/gemini/architect.md` | | Review | `~/.claude/.ccg/prompts/gemini/reviewer.md` | **Session Reuse**: Each call returns `SESSION_ID: xxx`, use `resume xxx` for subsequent phases. Save `GEMINI_SESSION` in Phase 2, use `resume` in Phases 3 and 5. --- ## Communication Guidelines 1. Start responses with mode label `[Mode: X]`, initial is `[Mode: Research]` 2. Follow strict sequence: `Research → Ideation → Plan → Execute → Optimize → Review` 3. Use `AskUserQuestion` tool for user interaction when needed (e.g., confirmation/selection/approval) --- ## Core Workflow ### Phase 0: Prompt Enhancement (Optional) `[Mode: Prepare]` - If ace-tool MCP available, call `mcp__ace-tool__enhance_prompt`, **replace original $ARGUMENTS with enhanced result for subsequent Gemini calls**. If unavailable, use `$ARGUMENTS` as-is. ### Phase 1: Research `[Mode: Research]` - Understand requirements and gather context 1. **Code Retrieval** (if ace-tool MCP available): Call `mcp__ace-tool__search_context` to retrieve existing components, styles, design system. If unavailable, use built-in tools: `Glob` for file discovery, `Grep` for component/style search, `Read` for context gathering, `Task` (Explore agent) for deeper exploration. 2. Requirement completeness score (0-10): >=7 continue, <7 stop and supplement ### Phase 2: Ideation `[Mode: Ideation]` - Gemini-led analysis **MUST call Gemini** (follow call specification above): - ROLE_FILE: `~/.claude/.ccg/prompts/gemini/analyzer.md` - Requirement: Enhanced requirement (or $ARGUMENTS if not enhanced) - Context: Project context from Phase 1 - OUTPUT: UI feasibility analysis, recommended solutions (at least 2), UX evaluation **Save SESSION_ID** (`GEMINI_SESSION`) for subsequent phase reuse. Output solutions (at least 2), wait for user selection. ### Phase 3: Planning `[Mode: Plan]` - Gemini-led planning **MUST call Gemini** (use `resume <GEMINI_SESSION>` to reuse session): - ROLE_FILE: `~/.claude/.ccg/prompts/gemini/architect.md` - Requirement: User's selected solution - Context: Analysis results from Phase 2 - OUTPUT: Component structure, UI flow, styling approach Claude synthesizes plan, save to `.claude/plan/task-name.md` after user approval. ### Phase 4: Implementation `[Mode: Execute]` - Code development - Strictly follow approved plan - Follow existing project design system and code standards - Ensure responsiveness, accessibility ### Phase 5: Optimization `[Mode: Optimize]` - Gemini-led review **MUST call Gemini** (follow call specification above): - ROLE_FILE: `~/.claude/.ccg/prompts/gemini/reviewer.md` - Requirement: Review the following frontend code changes - Context: git diff or code content - OUTPUT: Accessibility, responsiveness, performance, design consistency issues list Integrate review feedback, execute optimization after user confirmation. ### Phase 6: Quality Review `[Mode: Review]` - Final evaluation - Check completion against plan - Verify responsiveness and accessibility - Report issues and recommendations --- ## Key Rules 1. **Gemini frontend opinions are trustworthy** 2. **Codex frontend opinions for reference only** 3. External models have **zero filesystem write access** 4. Claude handles all code writes and file operations

package/packs/full-harness/rendered/.claude/commands/multi-plan.md

@@ -0,0 +1,6 @@
+---
+description: Create a multi-model implementation plan without modifying production code.
+argument-hint: [optional arguments]
+---
+
+# Plan - Multi-Model Collaborative Planning Multi-model collaborative planning - Context retrieval + Dual-model analysis → Generate step-by-step implementation plan. > **Prerequisite:** Requires the external `ccg-workflow` runtime, which is **not** part of the base ECC install. Initialize it with `npx ccg-workflow` to provision `~/.claude/bin/codeagent-wrapper` and the `~/.claude/.ccg/prompts/*` role files this command depends on. Without that runtime, this command will not run correctly. $ARGUMENTS --- ## Core Protocols - **Language Protocol**: Use **English** when interacting with tools/models, communicate with user in their language - **Mandatory Parallel**: Codex/Gemini calls MUST use `run_in_background: true` (including single model calls, to avoid blocking main thread) - **Code Sovereignty**: External models have **zero filesystem write access**, all modifications by Claude - **Stop-Loss Mechanism**: Do not proceed to next phase until current phase output is validated - **Planning Only**: This command allows reading context and writing to `.claude/plan/*` plan files, but **NEVER modify production code** --- ## Multi-Model Call Specification **Call Syntax** (parallel: use `run_in_background: true`): ``` Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Requirement: <enhanced requirement> Context: <retrieved project context> </TASK> OUTPUT: Step-by-step implementation plan with pseudo-code. DO NOT modify any files. EOF", run_in_background: true, timeout: 3600000, description: "Brief description" }) ``` **Model Parameter Notes**: - `{{GEMINI_MODEL_FLAG}}`: When using `--backend gemini`, replace with `--gemini-model gemini-3-pro-preview` (note trailing space); use empty string for codex **Role Prompts**: | Phase | Codex | Gemini | |-------|-------|--------| | Analysis | `~/.claude/.ccg/prompts/codex/analyzer.md` | `~/.claude/.ccg/prompts/gemini/analyzer.md` | | Planning | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/architect.md` | **Session Reuse**: Each call returns `SESSION_ID: xxx` (typically output by wrapper), **MUST save** for subsequent `/ccg:execute` use. **Wait for Background Tasks** (max timeout 600000ms = 10 minutes): ``` TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 }) ``` **IMPORTANT**: - Must specify `timeout: 600000`, otherwise default 30 seconds will cause premature timeout - If still incomplete after 10 minutes, continue polling with `TaskOutput`, **NEVER kill the process** - If waiting is skipped due to timeout, **MUST call `AskUserQuestion` to ask user whether to continue waiting or kill task** --- ## Execution Workflow **Planning Task**: $ARGUMENTS ### Phase 1: Full Context Retrieval `[Mode: Research]` #### 1.1 Prompt Enhancement (MUST execute first) **If ace-tool MCP is available**, call `mcp__ace-tool__enhance_prompt` tool: ``` mcp__ace-tool__enhance_prompt({ prompt: "$ARGUMENTS", conversation_history: "<last 5-10 conversation turns>", project_root_path: "$PWD" }) ``` Wait for enhanced prompt, **replace original $ARGUMENTS with enhanced result** for all subsequent phases. **If ace-tool MCP is NOT available**: Skip this step and use the original `$ARGUMENTS` as-is for all subsequent phases. #### 1.2 Context Retrieval **If ace-tool MCP is available**, call `mcp__ace-tool__search_context` tool: ``` mcp__ace-tool__search_context({ query: "<semantic query based on enhanced requirement>", project_root_path: "$PWD" }) ``` - Build semantic query using natural language (Where/What/How) - **NEVER answer based on assumptions** **If ace-tool MCP is NOT available**, use Claude Code built-in tools as fallback: 1. **Glob**: Find relevant files by pattern (e.g., `Glob("**/*.ts")`, `Glob("src/**/*.py")`) 2. **Grep**: Search for key symbols, function names, class definitions (e.g., `Grep("className|functionName")`) 3. **Read**: Read the discovered files to gather complete context 4. **Task (Explore agent)**: For deeper exploration, use `Task` with `subagent_type: "Explore"` to search across the codebase #### 1.3 Completeness Check - Must obtain **complete definitions and signatures** for relevant classes, functions, variables - If context insufficient, trigger **recursive retrieval** - Prioritize output: entry file + line number + key symbol name; add minimal code snippets only when necessary to resolve ambiguity #### 1.4 Requirement Alignment - If requirements still have ambiguity, **MUST** output guiding questions for user - Until requirement boundaries are clear (no omissions, no redundancy) ### Phase 2: Multi-Model Collaborative Analysis `[Mode: Analysis]` #### 2.1 Distribute Inputs **Parallel call** Codex and Gemini (`run_in_background: true`): Distribute **original requirement** (without preset opinions) to both models: 1. **Codex Backend Analysis**: - ROLE_FILE: `~/.claude/.ccg/prompts/codex/analyzer.md` - Focus: Technical feasibility, architecture impact, performance considerations, potential risks - OUTPUT: Multi-perspective solutions + pros/cons analysis 2. **Gemini Frontend Analysis**: - ROLE_FILE: `~/.claude/.ccg/prompts/gemini/analyzer.md` - Focus: UI/UX impact, user experience, visual design - OUTPUT: Multi-perspective solutions + pros/cons analysis Wait for both models' complete results with `TaskOutput`. **Save SESSION_ID** (`CODEX_SESSION` and `GEMINI_SESSION`). #### 2.2 Cross-Validation Integrate perspectives and iterate for optimization: 1. **Identify consensus** (strong signal) 2. **Identify divergence** (needs weighing) 3. **Complementary strengths**: Backend logic follows Codex, Frontend design follows Gemini 4. **Logical reasoning**: Eliminate logical gaps in solutions #### 2.3 (Optional but Recommended) Dual-Model Plan Draft To reduce risk of omissions in Claude's synthesized plan, can parallel have both models output "plan drafts" (still **NOT allowed** to modify files): 1. **Codex Plan Draft** (Backend authority): - ROLE_FILE: `~/.claude/.ccg/prompts/codex/architect.md` - OUTPUT: Step-by-step plan + pseudo-code (focus: data flow/edge cases/error handling/test strategy) 2. **Gemini Plan Draft** (Frontend authority): - ROLE_FILE: `~/.claude/.ccg/prompts/gemini/architect.md` - OUTPUT: Step-by-step plan + pseudo-code (focus: information architecture/interaction/accessibility/visual consistency) Wait for both models' complete results with `TaskOutput`, record key differences in their suggestions. #### 2.4 Generate Implementation Plan (Claude Final Version) Synthesize both analyses, generate **Step-by-step Implementation Plan**: ```markdown ## Implementation Plan: <Task Name> ### Task Type - [ ] Frontend (→ Gemini) - [ ] Backend (→ Codex) - [ ] Fullstack (→ Parallel) ### Technical Solution <Optimal solution synthesized from Codex + Gemini analysis> ### Implementation Steps 1. <Step 1> - Expected deliverable 2. <Step 2> - Expected deliverable ... ### Key Files | File | Operation | Description | |------|-----------|-------------| | path/to/file.ts:L10-L50 | Modify | Description | ### Risks and Mitigation | Risk | Mitigation | |------|------------| ### SESSION_ID (for /ccg:execute use) - CODEX_SESSION: <session_id> - GEMINI_SESSION: <session_id> ``` ### Phase 2 End: Plan Delivery (Not Execution) **`/ccg:plan` responsibilities end here, MUST execute the following actions**: 1. Present complete implementation plan to user (including pseudo-code) 2. Save plan to `.claude/plan/<feature-name>.md` (extract feature name from requirement, e.g., `user-auth`, `payment-module`) 3. Output prompt in **bold text** (MUST use actual saved file path): --- **Plan generated and saved to `.claude/plan/actual-feature-name.md`** **Please review the plan above. You can:** - **Modify plan**: Tell me what needs adjustment, I'll update the plan - **Execute plan**: Copy the following command to a new session ``` /ccg:execute .claude/plan/actual-feature-name.md ``` --- **NOTE**: The `actual-feature-name.md` above MUST be replaced with the actual saved filename! 4. **Immediately terminate current response** (Stop here. No more tool calls.) **ABSOLUTELY FORBIDDEN**: - Ask user "Y/N" then auto-execute (execution is `/ccg:execute`'s responsibility) - Any write operations to production code - Automatically call `/ccg:execute` or any implementation actions - Continue triggering model calls when user hasn't explicitly requested modifications --- ## Plan Saving After planning completes, save plan to: - **First planning**: `.claude/plan/<feature-name>.md` - **Iteration versions**: `.claude/plan/<feature-name>-v2.md`, `.claude/plan/<feature-name>-v3.md`... Plan file write should complete before presenting plan to user. --- ## Plan Modification Flow If user requests plan modifications: 1. Adjust plan content based on user feedback 2. Update `.claude/plan/<feature-name>.md` file 3. Re-present modified plan 4. Prompt user to review or execute again --- ## Next Steps After user approves, **manually** execute: ```bash /ccg:execute .claude/plan/<feature-name>.md ``` --- ## Key Rules 1. **Plan only, no implementation** – This command does not execute any code changes 2. **No Y/N prompts** – Only present plan, let user decide next steps 3. **Trust Rules** – Backend follows Codex, Frontend follows Gemini 4. External models have **zero filesystem write access** 5. **SESSION_ID Handoff** – Plan must include `CODEX_SESSION` / `GEMINI_SESSION` at end (for `/ccg:execute resume <SESSION_ID>` use)

package/packs/full-harness/rendered/.claude/commands/multi-workflow.md

@@ -0,0 +1,6 @@
+---
+description: Run a full multi-model development workflow with research, planning, execution, optimization, and review.
+argument-hint: [optional arguments]
+---
+
+# Workflow - Multi-Model Collaborative Development Multi-model collaborative development workflow (Research → Ideation → Plan → Execute → Optimize → Review), with intelligent routing: Frontend → Gemini, Backend → Codex. > **Prerequisite:** Requires the external `ccg-workflow` runtime, which is **not** part of the base ECC install. Initialize it with `npx ccg-workflow` to provision `~/.claude/bin/codeagent-wrapper` and the `~/.claude/.ccg/prompts/*` role files this command depends on. Without that runtime, this command will not run correctly. Structured development workflow with quality gates, MCP services, and multi-model collaboration. ## Usage ```bash /workflow <task description> ``` ## Context - Task to develop: $ARGUMENTS - Structured 6-phase workflow with quality gates - Multi-model collaboration: Codex (backend) + Gemini (frontend) + Claude (orchestration) - MCP service integration (ace-tool, optional) for enhanced capabilities ## Your Role You are the **Orchestrator**, coordinating a multi-model collaborative system (Research → Ideation → Plan → Execute → Optimize → Review). Communicate concisely and professionally for experienced developers. **Collaborative Models**: - **ace-tool MCP** (optional) – Code retrieval + Prompt enhancement - **Codex** – Backend logic, algorithms, debugging (**Backend authority, trustworthy**) - **Gemini** – Frontend UI/UX, visual design (**Frontend expert, backend opinions for reference only**) - **Claude (self)** – Orchestration, planning, execution, delivery --- ## Multi-Model Call Specification **Call syntax** (parallel: `run_in_background: true`, sequential: `false`): ``` # New session call Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}- \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)> Context: <project context and analysis from previous phases> </TASK> OUTPUT: Expected output format EOF", run_in_background: true, timeout: 3600000, description: "Brief description" }) # Resume session call Bash({ command: "~/.claude/bin/codeagent-wrapper {{LITE_MODE_FLAG}}--backend <codex|gemini> {{GEMINI_MODEL_FLAG}}resume <SESSION_ID> - \"$PWD\" <<'EOF' ROLE_FILE: <role prompt path> <TASK> Requirement: <enhanced requirement (or $ARGUMENTS if not enhanced)> Context: <project context and analysis from previous phases> </TASK> OUTPUT: Expected output format EOF", run_in_background: true, timeout: 3600000, description: "Brief description" }) ``` **Model Parameter Notes**: - `{{GEMINI_MODEL_FLAG}}`: When using `--backend gemini`, replace with `--gemini-model gemini-3-pro-preview` (note trailing space); use empty string for codex **Role Prompts**: | Phase | Codex | Gemini | |-------|-------|--------| | Analysis | `~/.claude/.ccg/prompts/codex/analyzer.md` | `~/.claude/.ccg/prompts/gemini/analyzer.md` | | Planning | `~/.claude/.ccg/prompts/codex/architect.md` | `~/.claude/.ccg/prompts/gemini/architect.md` | | Review | `~/.claude/.ccg/prompts/codex/reviewer.md` | `~/.claude/.ccg/prompts/gemini/reviewer.md` | **Session Reuse**: Each call returns `SESSION_ID: xxx`, use `resume xxx` subcommand for subsequent phases (note: `resume`, not `--resume`). **Parallel Calls**: Use `run_in_background: true` to start, wait for results with `TaskOutput`. **Must wait for all models to return before proceeding to next phase**. **Wait for Background Tasks** (use max timeout 600000ms = 10 minutes): ``` TaskOutput({ task_id: "<task_id>", block: true, timeout: 600000 }) ``` **IMPORTANT**: - Must specify `timeout: 600000`, otherwise default 30 seconds will cause premature timeout. - If still incomplete after 10 minutes, continue polling with `TaskOutput`, **NEVER kill the process**. - If waiting is skipped due to timeout, **MUST call `AskUserQuestion` to ask user whether to continue waiting or kill task. Never kill directly.** --- ## Communication Guidelines 1. Start responses with mode label `[Mode: X]`, initial is `[Mode: Research]`. 2. Follow strict sequence: `Research → Ideation → Plan → Execute → Optimize → Review`. 3. Request user confirmation after each phase completion. 4. Force stop when score < 7 or user does not approve. 5. Use `AskUserQuestion` tool for user interaction when needed (e.g., confirmation/selection/approval). ## When to Use External Orchestration Use external tmux/worktree orchestration when the work must be split across parallel workers that need isolated git state, independent terminals, or separate build/test execution. Use in-process subagents for lightweight analysis, planning, or review where the main session remains the only writer. ```bash node scripts/orchestrate-worktrees.js .claude/plan/workflow-e2e-test.json --execute ``` --- ## Execution Workflow **Task Description**: $ARGUMENTS ### Phase 1: Research & Analysis `[Mode: Research]` - Understand requirements and gather context: 1. **Prompt Enhancement** (if ace-tool MCP available): Call `mcp__ace-tool__enhance_prompt`, **replace original $ARGUMENTS with enhanced result for all subsequent Codex/Gemini calls**. If unavailable, use `$ARGUMENTS` as-is. 2. **Context Retrieval** (if ace-tool MCP available): Call `mcp__ace-tool__search_context`. If unavailable, use built-in tools: `Glob` for file discovery, `Grep` for symbol search, `Read` for context gathering, `Task` (Explore agent) for deeper exploration. 3. **Requirement Completeness Score** (0-10): - Goal clarity (0-3), Expected outcome (0-3), Scope boundaries (0-2), Constraints (0-2) - ≥7: Continue | <7: Stop, ask clarifying questions ### Phase 2: Solution Ideation `[Mode: Ideation]` - Multi-model parallel analysis: **Parallel Calls** (`run_in_background: true`): - Codex: Use analyzer prompt, output technical feasibility, solutions, risks - Gemini: Use analyzer prompt, output UI feasibility, solutions, UX evaluation Wait for results with `TaskOutput`. **Save SESSION_ID** (`CODEX_SESSION` and `GEMINI_SESSION`). **Follow the `IMPORTANT` instructions in `Multi-Model Call Specification` above** Synthesize both analyses, output solution comparison (at least 2 options), wait for user selection. ### Phase 3: Detailed Planning `[Mode: Plan]` - Multi-model collaborative planning: **Parallel Calls** (resume session with `resume <SESSION_ID>`): - Codex: Use architect prompt + `resume $CODEX_SESSION`, output backend architecture - Gemini: Use architect prompt + `resume $GEMINI_SESSION`, output frontend architecture Wait for results with `TaskOutput`. **Follow the `IMPORTANT` instructions in `Multi-Model Call Specification` above** **Claude Synthesis**: Adopt Codex backend plan + Gemini frontend plan, save to `.claude/plan/task-name.md` after user approval. ### Phase 4: Implementation `[Mode: Execute]` - Code development: - Strictly follow approved plan - Follow existing project code standards - Request feedback at key milestones ### Phase 5: Code Optimization `[Mode: Optimize]` - Multi-model parallel review: **Parallel Calls**: - Codex: Use reviewer prompt, focus on security, performance, error handling - Gemini: Use reviewer prompt, focus on accessibility, design consistency Wait for results with `TaskOutput`. Integrate review feedback, execute optimization after user confirmation. **Follow the `IMPORTANT` instructions in `Multi-Model Call Specification` above** ### Phase 6: Quality Review `[Mode: Review]` - Final evaluation: - Check completion against plan - Run tests to verify functionality - Report issues and recommendations - Request final user confirmation --- ## Key Rules 1. Phase sequence cannot be skipped (unless user explicitly instructs) 2. External models have **zero filesystem write access**, all modifications by Claude 3. **Force stop** when score < 7 or user does not approve

package/packs/full-harness/rendered/.claude/commands/orch-add-feature.md

@@ -0,0 +1,6 @@
+---
+description: Orchestrate building a brand-new feature end to end — research, plan, TDD, review, gated commit. Wrapper that kicks off the orch-add-feature skill.
+argument-hint: [optional arguments]
+---
+
+# /orch-add-feature Manually launch the **orch-add-feature** orchestrator: a gated Research → Plan → TDD → Review → Commit pipeline for net-new capability. ## Usage ``` /orch-add-feature <what to add> ``` Examples: ``` /orch-add-feature add OAuth2 login to nws-poller /orch-add-feature support CSV export in the dashboard ``` ## What It Does Invoke the `orch-add-feature` skill with `$ARGUMENTS` as the request. The skill (via the shared `orch-pipeline` engine) will: 1. Classify size and state the tier in one line. 2. Research existing libraries/patterns, then plan a `task_list`. → **GATE 1** (approve plan). 3. TDD each task (new failing tests → green), then `code-reviewer` (+ `security-reviewer` if a security trigger is touched). 4. Commit as conventional `feat:` commits. → **GATE 2** (confirm before commit). Honor both gates — do not write implementation before Gate 1, do not commit before Gate 2. If `$ARGUMENTS` is empty, ask the user what capability to add.

package/packs/full-harness/rendered/.claude/commands/orch-build-mvp.md

@@ -0,0 +1,6 @@
+---
+description: Orchestrate bootstrapping a working MVP from a design/spec doc — ingest, slice, scaffold, TDD, review, gated commit (reuses the GAN harness). Wrapper for the orch-build-mvp skill.
+argument-hint: [optional arguments]
+---
+
+# /orch-build-mvp Manually launch the **orch-build-mvp** orchestrator: turn an SDD/PRD/system-design document into a running vertical slice. ## Usage ``` /orch-build-mvp <path to design/spec doc> ``` Examples: ``` /orch-build-mvp civicpulse/docs/SDD-v0.6.md ``` ## What It Does Invoke the `orch-build-mvp` skill with `$ARGUMENTS` as the doc path. The skill (via the shared `orch-pipeline` engine, full pipeline incl. Scaffold) will: 1. Read the spec; extract scope, locked decisions, and a feature list ordered as **thin vertical slices** (one end-to-end path first). → **GATE 1** (approve slice plan). 2. Scaffold the first end-to-end slice. 3. Reuse the GAN harness: translate the SDD into `gan-harness/spec.md` + `eval-rubric.md`, then drive `/gan-build "<brief>" --skip-planner` (generator → evaluator loop) until the score passes or plateaus. 4. `code-reviewer` (+ `security-reviewer` on any security-trigger slice), then commit the scaffold and each slice as separate `feat:` commits. → **GATE 2**. If `$ARGUMENTS` is empty, ask the user for the path to the design/spec doc.

package/packs/full-harness/rendered/.claude/commands/orch-change-feature.md

@@ -0,0 +1,6 @@
+---
+description: Orchestrate altering an existing, working feature to new desired behavior — update tests to the new spec, change impl, review, gated commit. Wrapper for the orch-change-feature skill.
+argument-hint: [optional arguments]
+---
+
+# /orch-change-feature Manually launch the **orch-change-feature** orchestrator: change behavior that already works to a new desired spec, tests-first. ## Usage ``` /orch-change-feature <the new desired behavior> ``` Examples: ``` /orch-change-feature make nws-poller alert at 2 warnings instead of 3 /orch-change-feature instead of sorting by date, sort by priority ``` ## What It Does Invoke the `orch-change-feature` skill with `$ARGUMENTS` as the request. The skill (via the shared `orch-pipeline` engine) will: 1. Classify size (default floor: small) and state the tier. 2. Light plan only if the new behavior needs research. → **GATE 1** (approve changed-test plan). 3. **Update the existing tests** to express the new behavior, then change the implementation until green. (Changing the tests first is what makes this a tweak, not a fix.) 4. `code-reviewer` (+ `security-reviewer` on a security trigger), then commit. → **GATE 2**. Use this only when the feature **works** but should behave differently — not for bugs (`/orch-fix-defect`) or net-new capability (`/orch-add-feature`). If `$ARGUMENTS` is empty, ask the user what behavior should change.

package/packs/full-harness/rendered/.claude/commands/orch-fix-defect.md

@@ -0,0 +1,6 @@
+---
+description: Orchestrate fixing a bug — reproduce it as a failing regression test, fix to green, review, gated commit. Wrapper for the orch-fix-defect skill.
+argument-hint: [optional arguments]
+---
+
+# /orch-fix-defect Manually launch the **orch-fix-defect** orchestrator: prove the bug with a red test, then fix to green. ## Usage ``` /orch-fix-defect <what is broken> ``` Examples: ``` /orch-fix-defect poller crashes on empty NWS response /orch-fix-defect login returns 500 when email has a plus sign ``` ## What It Does Invoke the `orch-fix-defect` skill with `$ARGUMENTS` as the request. The skill (via the shared `orch-pipeline` engine) will: 1. Classify size (default floor: small, often trivial); scope root cause with `code-explorer` if unclear. 2. **Write a new failing regression test** reproducing the bug, then fix until it goes green. (Proving the bug first is what makes this a fix, not a tweak.) 3. `code-reviewer` (+ `security-reviewer` if the defect sits in a sensitive path). 4. Commit as a conventional `fix:` commit. → **GATE 2** (confirm before commit). Use this only when behavior is **broken/wrong** — not for intentional changes (`/orch-change-feature`) or new capability (`/orch-add-feature`). If `$ARGUMENTS` is empty, ask the user to describe the defect.

package/packs/full-harness/rendered/.claude/commands/orch-refine-code.md

@@ -0,0 +1,6 @@
+---
+description: Orchestrate a behavior-preserving refactor — confirm tests green, restructure without changing behavior, keep green, review, gated commit. Wrapper for the orch-refine-code skill.
+argument-hint: [optional arguments]
+---
+
+# /orch-refine-code Manually launch the **orch-refine-code** orchestrator: improve structure while behavior stays identical, with the existing test suite as the safety net. ## Usage ``` /orch-refine-code <what to restructure> ``` Examples: ``` /orch-refine-code extract the NWS HTTP client out of poller.py /orch-refine-code remove dead code and duplication in the dashboard module ``` ## What It Does Invoke the `orch-refine-code` skill with `$ARGUMENTS` as the request. The skill (via the shared `orch-pipeline` engine) will: 1. Classify size (default floor: standard — restructures touch multiple files). 2. Confirm the relevant tests exist and are **green before** touching code; add characterization tests first if coverage is thin. Plan the restructure. → **GATE 1**. 3. Restructure in small steps, re-running tests after each (no new behavior tests — the existing suite proves behavior is unchanged). Dead-code/dup sweeps delegate to `refactor-cleaner`. 4. `code-reviewer`, then commit as `refactor:` (the diff must be behavior-neutral). → **GATE 2**. Use this only when behavior must **not** change. If behavior should change at all, use `/orch-change-feature` or `/orch-fix-defect`. If `$ARGUMENTS` is empty, ask the user what to refine.

package/packs/full-harness/rendered/.claude/commands/orch-review.md

@@ -0,0 +1,6 @@
+---
+description: Run the orch-review native Workflow over a diff (local changes or a GitHub PR) and report blocking vs advisory findings. Surface for the orch-review workflow.
+argument-hint: pr-number | pr-url | blank for local uncommitted changes
+---
+
+# /orch-review Surface for `workflows/orch-review.workflow.js` — the native Workflow port of orch-pipeline Phase 5 (Review). This command computes a diff, hands it to the workflow, and presents the result. The workflow owns the fan-out (one reviewer per dimension, dedup, adversarial verify); this command owns input and output. **Input**: $ARGUMENTS --- ## Mode Selection | Input | Mode | |---|---| | Blank | **Local Mode** — review uncommitted changes | | Number (e.g. `42`) or PR URL | **PR Mode** — review a GitHub PR | --- ## Phase 1 — GATHER Build the unified diff and the metadata the workflow needs. **Local Mode:** ```bash git diff --name-only HEAD # changedFiles git diff HEAD # diff text ``` If the diff is empty, stop: "Nothing to review." **PR Mode:** First derive a **safe numeric PR id** from `$ARGUMENTS` — never pass the raw argument to the shell. Accept either a bare integer, or the trailing number of a `https://github.com/<owner>/<repo>/pull/<N>` URL. Reject anything else (extra text, shell metacharacters, a non-PR URL) and stop with an error. Use only the extracted integer `<NUMBER>` below: ```bash gh pr diff <NUMBER> # diff text gh pr view <NUMBER> --json files \ --jq '.files[].path' # changedFiles ``` If the PR is not found, stop with an error. Then derive `language` from the dominant changed-file extension (for example `.ts`/`.tsx` to `typescript`, `.py` to `python`, `.go` to `go`). Leave it unset when the change is mixed or non-code — the workflow simply skips the language-specific reviewer. ## Phase 2 — INVOKE Call the Workflow tool. The workflow validates its own input and fails closed on a missing or empty diff, so always pass a non-empty `diff`. ```jsonc Workflow({ scriptPath: "workflows/orch-review.workflow.js", args: { diff: "<unified diff text from Phase 1>", // required language: "typescript", // optional changedFiles: ["src/auth.ts"] // optional — feeds the security trigger } }) ``` The workflow fans out reviewers in parallel, dedups findings on the normalized evidence snippet, and runs an adversarial verifier on every unique CRITICAL/HIGH finding. It returns: ```jsonc { "verdict": "APPROVE" | "CHANGES_REQUESTED", "incomplete": false, // true if a review dimension failed to run "failedDimensions": [ /* { dimension, error } */ ], "blocking": [ /* confirmed CRITICAL/HIGH + unverifiable findings */ ], "advisory": [ /* MEDIUM/LOW + adversarially-refuted findings */ ], "stats": { "dimensions": 3, "failed": 0, "raw": 11, "unique": 4, "confirmed": 3, "unverified": 0, "uncertain": 0, "refuted": 1 } } ``` ## Phase 3 — REPORT Present the result to the user (this is the human review gate; the workflow does not commit anything): - Lead with `verdict` and the `stats` line (dimensions, raw to unique collapse). - List every `blocking` finding with file, severity, and evidence — these must clear before a commit. Findings tagged "could not be verified" stay in `blocking` by design; call them out as needing manual confirmation. - List `advisory` findings briefly (MEDIUM/LOW and verifier-refuted items). - If `incomplete` is true, state which dimensions in `failedDimensions` did not run and that the verdict is therefore not a clean approval. ## Fail-Closed Contract This command must never present a clean APPROVE when the review could not fully run. If the Workflow tool itself errors, report the failure — do not fall back to a hand-rolled review and do not imply the diff was approved. --- ## Edge Cases - **No `gh` CLI (PR Mode)**: stop and tell the user PR Mode needs `gh`; suggest Local Mode against a checked-out branch instead. - **Large diff**: the workflow caps reviewer concurrency automatically, so a large diff is slower but safe; warn the user it may take longer. - **Binary or generated files**: drop them from `changedFiles` before invoking — they add noise to the security trigger without reviewable content.

package/packs/full-harness/rendered/.claude/commands/plan-canvas.md

@@ -0,0 +1,6 @@
+---
+description: Open a plan or HTML artifact in the browser Plan Canvas for annotate-and-approve review
+argument-hint: [path/to/artifact.plan.md | path/to/artifact.html]
+---
+
+# Plan Canvas Command Opens a local artifact in the Plan Canvas — ECC's browser review surface — where the user annotates elements, chats with you, and approves the plan or requests changes without leaving the page. This command is a thin entry point over the `plan-canvas` skill. Follow that skill for the full workflow and rules. ## What This Command Does 1. Resolve the artifact: the given path, else the most recently modified `.claude/plans/*.plan.md`, else ask what to review. 2. `ecc-plan-canvas open <artifact>` — opens the user's browser. 3. `ecc-plan-canvas await <artifact>` — block until feedback, verdict, or session end; leave it running. 4. Apply feedback to the artifact file (the canvas live-reloads), answer with `await <artifact> --reply "..."`, and repeat until the user approves or ends the session. An `approve` verdict counts as plan confirmation for `/plan`-style gates: stop polling, `end` the session, and begin implementation. ## Example ``` User: /plan-canvas .claude/plans/notifications.plan.md Assistant: (runs open + await, browser opens) ...user clicks "Request changes" with two annotations... Assistant: (edits the plan, replies in-canvas, awaits again) ...user clicks "Approve plan"... Assistant: Plan approved in the canvas — starting implementation. ``` ## Related - `plan-canvas` skill — full workflow, feedback JSON shapes, rules - `/plan` — produces the plan artifacts this reviews - Source: `scripts/plan-canvas.js`, `scripts/lib/plan-canvas/`

package/packs/full-harness/rendered/.claude/commands/plan-prd.md

@@ -0,0 +1,6 @@
+---
+description: Generate a lean, problem-first PRD and hand off to /plan for implementation planning.
+argument-hint: [product/feature idea] (blank = start with questions)
+---
+
+# PRD Command Produces a **Product Requirements Document** — the requirements-phase artifact of the SDLC. Captures *what* must be true for success and *why*, and stops before *how*. Implementation decomposition is delegated to `/plan`. **Input**: `$ARGUMENTS` ## Scope of this command | This command does | This command does NOT do | |---|---| | Frame the problem and users | Design the architecture | | Capture success criteria and scope | Pick files or write patterns | | List open questions and risks | Enumerate implementation tasks | | Write `.claude/prds/{name}.prd.md` | Produce an implementation plan — that's `/plan` | If you find yourself writing implementation detail, stop and cut it. It belongs in `/plan`. **Anti-fluff rule**: When information is missing, write `TBD — needs validation via {method}`. Never invent plausible-sounding requirements. ## Workflow Four phases. Each phase is a single gate — ask the questions, wait for the user, then move on. No nested loops, no parallel research ceremony. ### Phase 1 — FRAME If `$ARGUMENTS` is empty, ask: > What do you want to build? One or two sentences. If provided, restate in one sentence and ask: > I understand: *{restated}*. Correct, or should I adjust? Then ask the framing questions in a single set: > 1. **Who** has this problem? (specific role or segment) > 2. **What** is the observable pain? (describe behavior, not assumed needs) > 3. **Why** can't they solve it with what exists today? > 4. **Why now?** — what changed that makes this worth doing? Wait for the user. Do not proceed without answers (or explicit "skip"). ### Phase 2 — GROUND Ask for evidence. This is the shortest phase and the most load-bearing: > What evidence do you have that this problem is real and worth solving? (user quotes, support tickets, metrics, observed behavior, failed workarounds — anything concrete) If the user has none, record the PRD's Evidence section as `Assumption — needs validation via {user research | analytics | prototype}`. This keeps the PRD honest. ### Phase 3 — DECIDE Scope and hypothesis in a single set: > 1. **Hypothesis** — Complete: *We believe **{capability}** will **{solve problem}** for **{users}**. We'll know we're right when **{measurable outcome}**.* > 2. **MVP** — The minimum needed to test the hypothesis? > 3. **Out of scope** — What are you explicitly **not** building (even if users ask)? > 4. **Open questions** — Uncertainties that could change the approach? Wait for responses. ### Phase 4 — GENERATE & HAND OFF Create the directory if needed, write the PRD, and report. ```bash mkdir -p .claude/prds ``` **Output path**: `.claude/prds/{kebab-case-name}.prd.md` #### PRD Template ```markdown # {Product / Feature Name} ## Problem {2–3 sentences: who has what problem, and what's the cost of leaving it unsolved?} ## Evidence - {User quote, data point, or observation} - {OR: "Assumption — needs validation via {method}"} ## Users - **Primary**: {role, context, what triggers the need} - **Not for**: {who this explicitly excludes} ## Hypothesis We believe **{capability}** will **{solve problem}** for **{users}**. We'll know we're right when **{measurable outcome}**. ## Success Metrics | Metric | Target | How measured | |---|---|---| | {primary} | {number} | {method} | ## Scope **MVP** — {the minimum to test the hypothesis} **Out of scope** - {item} — {why deferred} ## Delivery Milestones <!-- Business outcomes, not engineering tasks. /plan turns each into a plan. --> <!-- Status: pending | in-progress | complete --> | # | Milestone | Outcome | Status | Plan | |---|---|---|---|---| | 1 | {name} | {user-visible change} | pending | — | | 2 | {name} | {user-visible change} | pending | — | ## Open Questions - [ ] {question that could change scope or approach} ## Risks | Risk | Likelihood | Impact | Mitigation | |---|---|---|---| --- *Status: DRAFT — requirements only. Implementation planning pending via /plan.* ``` #### Report to user ``` PRD created: .claude/prds/{name}.prd.md Problem: {one line} Hypothesis: {one line} MVP: {one line} Validation status: Problem {validated | assumption} Users {concrete | generic — refine} Metrics {defined | TBD} Open questions: {count} Next step: /plan .claude/prds/{name}.prd.md → /plan will pick the next pending milestone and produce an implementation plan. ``` ## Integration - `/plan <prd-path>` — consume the PRD and produce an implementation plan for the next pending milestone. - `tdd-workflow` skill — implement the plan test-first. - `/pr` — open a PR that references the PRD and plan. ## Success criteria - **PROBLEM_CLEAR**: problem is specific and evidenced (or flagged as assumption). - **USER_CONCRETE**: primary user is a specific role, not "users". - **HYPOTHESIS_TESTABLE**: measurable outcome included. - **SCOPE_BOUNDED**: explicit MVP and explicit out-of-scope. - **NO_IMPLEMENTATION_DETAIL**: file paths, libraries, or task breakdowns are absent — if they appeared, move them to the `/plan` step.

package/packs/full-harness/rendered/.claude/commands/plan.md

@@ -0,0 +1,6 @@
+---
+description: Restate requirements, assess risks, and create step-by-step implementation plan. WAIT for user CONFIRM before touching any code.
+argument-hint: [feature description | path/to/*.prd.md]
+---
+
+# Plan Command This command creates a comprehensive implementation plan before writing any code. It accepts either free-form requirements or a PRD markdown file. Run inline by default. Do not call the Task tool or any subagent by default. This keeps `/plan` usable from plugin installs that ship commands without agent files. ## What This Command Does 1. **Restate Requirements** - Clarify what needs to be built 2. **Identify Risks** - Surface potential issues and blockers 3. **Create Step Plan** - Break down implementation into phases 4. **Wait for Confirmation** - MUST receive user approval before proceeding ## When to Use Use `/plan` when: - Starting a new feature - Making significant architectural changes - Working on complex refactoring - Multiple files/components will be affected - Requirements are unclear or ambiguous ## How It Works The assistant will: 1. **Analyze the request** and restate requirements in clear terms 2. **Ground the plan** in relevant codebase patterns when the repo is available 3. **Break down into phases** with specific, actionable steps 4. **Identify dependencies** between components 5. **Assess risks** and potential blockers 6. **Estimate complexity** (High/Medium/Low) 7. **Present the plan** and WAIT for your explicit confirmation ## Input Modes | Input | Mode | Behavior | |---|---|---| | `path/to/name.prd.md` | PRD artifact mode | Read the PRD, pick the next pending delivery milestone or implementation phase, and write `.claude/plans/{name}.plan.md` | | Any other markdown path | Reference mode | Read the file as context and produce an inline plan | | Free-form text | Conversational mode | Produce an inline plan | | Empty input | Clarification mode | Ask what should be planned | In PRD artifact mode, create `.claude/plans/` if needed. If the PRD contains a `Delivery Milestones` table, update only the selected row from `pending` to `in-progress` and set its `Plan` cell to the generated plan path. If the PRD uses the legacy `.claude/PRPs/prds/` format with `Implementation Phases`, read it without migrating paths. ## Pattern Grounding Before writing the plan, search the codebase for conventions the implementation should mirror. Capture the top example for each relevant category with file references: | Category | What to capture | |---|---| | Naming | File, function, type, command, or script naming in the affected area | | Error handling | How failures are raised, returned, logged, or handled gracefully | | Logging | Levels, format, and what gets logged | | Data access | Repository, service, query, or filesystem patterns | | Tests | Test file location, framework, fixtures, and assertion style | If no similar code exists, state that explicitly. Do not invent a pattern. ## PRD Artifact Output When called with a `.prd.md` file, write the plan to `.claude/plans/{kebab-case-name}.plan.md` using this structure: ````markdown # Plan: {Feature Name} **Source PRD**: {path} **Selected Milestone**: {milestone or phase name} **Complexity**: {Small | Medium | Large} ## Summary {2-3 sentences} ## Patterns to Mirror | Category | Source | Pattern | |---|---|---| | Naming | `path:line` | {short description} | | Errors | `path:line` | {short description} | | Tests | `path:line` | {short description} | ## Files to Change | File | Action | Why | |---|---|---| | `path` | CREATE / UPDATE / DELETE | {reason} | ## Tasks ### Task 1: {name} - **Action**: {what to do} - **Mirror**: {pattern to follow} - **Validate**: {command that proves correctness} ## Validation ```bash {project-specific validation commands} ``` ## Risks | Risk | Likelihood | Mitigation | |---|---|---| ## Acceptance - [ ] All tasks complete - [ ] Validation passes - [ ] Patterns mirrored, not reinvented ```` After writing the artifact, report its path and WAIT for confirmation before writing code. > **Visual review:** instead of asking for a typed confirmation, you can open the > artifact in the browser Plan Canvas (`/plan-canvas`, or the `plan-canvas` skill): > the user annotates the plan in place and clicks **Approve plan** or **Request > changes**, which arrives as your confirmation signal. ## Example Usage ``` User: /plan I need to add real-time notifications when markets resolve Assistant: # Implementation Plan: Real-Time Market Resolution Notifications ## Requirements Restatement - Send notifications to users when markets they're watching resolve - Support multiple notification channels (in-app, email, webhook) - Ensure notifications are delivered reliably - Include market outcome and user's position result ## Implementation Phases ### Phase 1: Database Schema - Add notifications table with columns: id, user_id, market_id, type, status, created_at - Add user_notification_preferences table for channel preferences - Create indexes on user_id and market_id for performance ### Phase 2: Notification Service - Create notification service in lib/notifications.ts - Implement notification queue using BullMQ/Redis - Add retry logic for failed deliveries - Create notification templates ### Phase 3: Integration Points - Hook into market resolution logic (when status changes to "resolved") - Query all users with positions in market - Enqueue notifications for each user ### Phase 4: Frontend Components - Create NotificationBell component in header - Add NotificationList modal - Implement real-time updates via Supabase subscriptions - Add notification preferences page ## Dependencies - Redis (for queue) - Email service (SendGrid/Resend) - Supabase real-time subscriptions ## Risks - HIGH: Email deliverability (SPF/DKIM required) - MEDIUM: Performance with 1000+ users per market - MEDIUM: Notification spam if markets resolve frequently - LOW: Real-time subscription overhead ## Estimated Complexity: MEDIUM - Backend: 4-6 hours - Frontend: 3-4 hours - Testing: 2-3 hours - Total: 9-13 hours **WAITING FOR CONFIRMATION**: Proceed with this plan? (yes/no/modify) ``` ## Important Notes **CRITICAL**: This command will **NOT** write any code until you explicitly confirm the plan with "yes" or "proceed" or similar affirmative response. If you want changes, respond with: - "modify: [your changes]" - "different approach: [alternative]" - "skip phase 2 and do phase 3 first" ## Integration with Other Commands After planning: - Use `/plan-canvas` to run the confirmation gate visually in the browser (annotate + approve) - Use the `tdd-workflow` skill to implement with test-driven development - Use `/build-fix` if build errors occur - Use `/code-review` to review completed implementation - Use `/pr` or `/prp-pr` to open a pull request > **Need requirements first?** Use `/plan-prd` for a lean PRD at `.claude/prds/{name}.prd.md`. > > **Need the legacy PRP flow?** Use `/prp-plan` for deep PRP planning with `.claude/PRPs/` artifacts. Use `/prp-implement` to execute those plans with rigorous validation loops. ## Optional Planner Agent ECC also provides a `planner` agent for manual installs that include agent files. Use it only when the local runtime already exposes that subagent and the user explicitly asks you to delegate planning. If the `planner` subagent is unavailable, continue planning inline instead of surfacing an "Agent type 'planner' not found" error. For manual installs, the source file lives at: `agents/planner.md`

package/packs/full-harness/rendered/.claude/commands/pm2.md

@@ -0,0 +1,6 @@
+---
+description: Analyze a project and generate PM2 service commands for detected frontend, backend, or database services.
+argument-hint: [optional arguments]
+---
+
+# PM2 Init Auto-analyze project and generate PM2 service commands. **Command**: `$ARGUMENTS` --- ## Workflow 1. Check PM2 (install via `npm install -g pm2` if missing) 2. Scan project to identify services (frontend/backend/database) 3. Generate config files and individual command files --- ## Service Detection | Type | Detection | Default Port | |------|-----------|--------------| | Vite | vite.config.* | 5173 | | Next.js | next.config.* | 3000 | | Nuxt | nuxt.config.* | 3000 | | CRA | react-scripts in package.json | 3000 | | Express/Node | server/backend/api directory + package.json | 3000 | | FastAPI/Flask | requirements.txt / pyproject.toml | 8000 | | Go | go.mod / main.go | 8080 | **Port Detection Priority**: User specified > .env > config file > scripts args > default port --- ## Generated Files ``` project/ ├── ecosystem.config.cjs # PM2 config ├── {backend}/start.cjs # Python wrapper (if applicable) └── .claude/ ├── commands/ │ ├── pm2-all.md # Start all + monit │ ├── pm2-all-stop.md # Stop all │ ├── pm2-all-restart.md # Restart all │ ├── pm2-{port}.md # Start single + logs │ ├── pm2-{port}-stop.md # Stop single │ ├── pm2-{port}-restart.md # Restart single │ ├── pm2-logs.md # View all logs │ └── pm2-status.md # View status └── scripts/ ├── pm2-logs-{port}.ps1 # Single service logs └── pm2-monit.ps1 # PM2 monitor ``` --- ## Windows Configuration (IMPORTANT) ### ecosystem.config.cjs **Must use `.cjs` extension** ```javascript module.exports = { apps: [ // Node.js (Vite/Next/Nuxt) { name: 'project-3000', cwd: './packages/web', script: 'node_modules/vite/bin/vite.js', args: '--port 3000', interpreter: 'C:/Program Files/nodejs/node.exe', env: { NODE_ENV: 'development' } }, // Python { name: 'project-8000', cwd: './backend', script: 'start.cjs', interpreter: 'C:/Program Files/nodejs/node.exe', env: { PYTHONUNBUFFERED: '1' } } ] } ``` **Framework script paths:** | Framework | script | args | |-----------|--------|------| | Vite | `node_modules/vite/bin/vite.js` | `--port {port}` | | Next.js | `node_modules/next/dist/bin/next` | `dev -p {port}` | | Nuxt | `node_modules/nuxt/bin/nuxt.mjs` | `dev --port {port}` | | Express | `src/index.js` or `server.js` | - | ### Python Wrapper Script (start.cjs) ```javascript const { spawn } = require('child_process'); const proc = spawn('python', ['-m', 'uvicorn', 'app.main:app', '--host', '0.0.0.0', '--port', '8000', '--reload'], { cwd: __dirname, stdio: 'inherit', windowsHide: true }); proc.on('close', (code) => process.exit(code)); ``` --- ## Command File Templates (Minimal Content) ### pm2-all.md (Start all + monit) ````markdown Start all services and open PM2 monitor. ```bash cd "{PROJECT_ROOT}" && pm2 start ecosystem.config.cjs && start wt.exe -d "{PROJECT_ROOT}" pwsh -NoExit -c "pm2 monit" ``` ```` ### pm2-all-stop.md ````markdown Stop all services. ```bash cd "{PROJECT_ROOT}" && pm2 stop all ``` ```` ### pm2-all-restart.md ````markdown Restart all services. ```bash cd "{PROJECT_ROOT}" && pm2 restart all ``` ```` ### pm2-{port}.md (Start single + logs) ````markdown Start {name} ({port}) and open logs. ```bash cd "{PROJECT_ROOT}" && pm2 start ecosystem.config.cjs --only {name} && start wt.exe -d "{PROJECT_ROOT}" pwsh -NoExit -c "pm2 logs {name}" ``` ```` ### pm2-{port}-stop.md ````markdown Stop {name} ({port}). ```bash cd "{PROJECT_ROOT}" && pm2 stop {name} ``` ```` ### pm2-{port}-restart.md ````markdown Restart {name} ({port}). ```bash cd "{PROJECT_ROOT}" && pm2 restart {name} ``` ```` ### pm2-logs.md ````markdown View all PM2 logs. ```bash cd "{PROJECT_ROOT}" && pm2 logs ``` ```` ### pm2-status.md ````markdown View PM2 status. ```bash cd "{PROJECT_ROOT}" && pm2 status ``` ```` ### PowerShell Scripts (pm2-logs-{port}.ps1) ```powershell Set-Location "{PROJECT_ROOT}" pm2 logs {name} ``` ### PowerShell Scripts (pm2-monit.ps1) ```powershell Set-Location "{PROJECT_ROOT}" pm2 monit ``` --- ## Key Rules 1. **Config file**: `ecosystem.config.cjs` (not .js) 2. **Node.js**: Specify bin path directly + interpreter 3. **Python**: Node.js wrapper script + `windowsHide: true` 4. **Open new window**: `start wt.exe -d "{path}" pwsh -NoExit -c "command"` 5. **Minimal content**: Each command file has only 1-2 lines description + bash block 6. **Direct execution**: No AI parsing needed, just run the bash command --- ## Execute Based on `$ARGUMENTS`, execute init: 1. Scan project for services 2. Generate `ecosystem.config.cjs` 3. Generate `{backend}/start.cjs` for Python services (if applicable) 4. Generate command files in `.claude/commands/` 5. Generate script files in `.claude/scripts/` 6. **Update project CLAUDE.md** with PM2 info (see below) 7. **Display completion summary** with terminal commands --- ## Post-Init: Update CLAUDE.md After generating files, append PM2 section to project's `CLAUDE.md` (create if not exists): ````markdown ## PM2 Services | Port | Name | Type | |------|------|------| | {port} | {name} | {type} | **Terminal Commands:** ```bash pm2 start ecosystem.config.cjs # First time pm2 start all # After first time pm2 stop all / pm2 restart all pm2 start {name} / pm2 stop {name} pm2 logs / pm2 status / pm2 monit pm2 save # Save process list pm2 resurrect # Restore saved list ``` ```` **Rules for CLAUDE.md update:** - If PM2 section exists, replace it - If not exists, append to end - Keep content minimal and essential --- ## Post-Init: Display Summary After all files generated, output: ``` ## PM2 Init Complete **Services:** | Port | Name | Type | |------|------|------| | {port} | {name} | {type} | **Claude Commands:** /pm2-all, /pm2-all-stop, /pm2-{port}, /pm2-{port}-stop, /pm2-logs, /pm2-status **Terminal Commands:** ## First time (with config file) pm2 start ecosystem.config.cjs && pm2 save ## After first time (simplified) pm2 start all # Start all pm2 stop all # Stop all pm2 restart all # Restart all pm2 start {name} # Start single pm2 stop {name} # Stop single pm2 logs # View logs pm2 monit # Monitor panel pm2 resurrect # Restore saved processes **Tip:** Run `pm2 save` after first start to enable simplified commands. ```

package/packs/full-harness/rendered/.claude/commands/pr.md

@@ -0,0 +1,6 @@
+---
+description: Create a GitHub PR from current branch with unpushed commits — discovers templates, analyzes changes, pushes
+argument-hint: [base-branch] (default: main)
+---
+
+# Create Pull Request **Input**: `$ARGUMENTS` — optional, may contain a base branch name and/or flags (e.g., `--draft`). **Parse `$ARGUMENTS`**: - Extract any recognized flags (`--draft`) - Treat remaining non-flag text as the base branch name - Default base branch to `main` if none specified --- ## Phase 1 — VALIDATE Check preconditions: ```bash git branch --show-current git status --short git log origin/<base>..HEAD --oneline ``` | Check | Condition | Action if Failed | |---|---|---| | Not on base branch | Current branch ≠ base | Stop: "Switch to a feature branch first." | | Clean working directory | No uncommitted changes | Warn: "You have uncommitted changes. Commit or stash first." | | Has commits ahead | `git log origin/<base>..HEAD` not empty | Stop: "No commits ahead of `<base>`. Nothing to PR." | | No existing PR | `gh pr list --head <branch> --json number` is empty | Stop: "PR already exists: #<number>. Use `gh pr view <number> --web` to open it." | If all checks pass, proceed. --- ## Phase 2 — DISCOVER ### PR Template Search for PR template in order: 1. `.github/PULL_REQUEST_TEMPLATE/` directory — if exists, list files and let user choose (or use `default.md`) 2. `.github/PULL_REQUEST_TEMPLATE.md` 3. `.github/pull_request_template.md` 4. `docs/pull_request_template.md` If found, read it and use its structure for the PR body. ### Commit Analysis ```bash git log origin/<base>..HEAD --format="%h %s" --reverse ``` Analyze commits to determine: - **PR title**: Use conventional commit format with type prefix — `feat: ...`, `fix: ...`, etc. - If multiple types, use the dominant one - If single commit, use its message as-is - **Change summary**: Group commits by type/area ### File Analysis ```bash git diff origin/<base>..HEAD --stat git diff origin/<base>..HEAD --name-only ``` Categorize changed files: source, tests, docs, config, migrations. ### Planning Artifacts Check for related artifacts produced by `/plan-prd`, `/plan`, or the legacy PRP workflow: - `.claude/prds/` — PRDs this PR implements a milestone of - `.claude/plans/` — Plans executed by this PR - `.claude/PRPs/prds/` — legacy PRP PRDs - `.claude/PRPs/plans/` — legacy PRP implementation plans - `.claude/PRPs/reports/` — legacy PRP implementation reports Reference these in the PR body if they exist. --- ## Phase 3 — PUSH ```bash git push -u origin HEAD ``` If push fails due to divergence: ```bash git fetch origin git rebase origin/<base> git push -u origin HEAD ``` If rebase conflicts occur, stop and inform the user. --- ## Phase 4 — CREATE ### With Template If a PR template was found in Phase 2, fill in each section using the commit and file analysis. Preserve all template sections — leave sections as "N/A" if not applicable rather than removing them. ### Without Template Use this default format: ```markdown ## Summary <1-2 sentence description of what this PR does and why> ## Changes <bulleted list of changes grouped by area> ## Files Changed <table or list of changed files with change type: Added/Modified/Deleted> ## Testing <description of how changes were tested, or "Needs testing"> ## Related Issues <linked issues with Closes/Fixes/Relates to #N, or "None"> ``` ### Create the PR ```bash gh pr create \ --title "<PR title>" \ --base <base-branch> \ --body "<PR body>" # Add --draft if the --draft flag was parsed from $ARGUMENTS ``` --- ## Phase 5 — VERIFY ```bash gh pr view --json number,url,title,state,baseRefName,headRefName,additions,deletions,changedFiles gh pr checks --json name,status,conclusion 2>/dev/null || true ``` --- ## Phase 6 — OUTPUT Report to user: ``` PR #<number>: <title> URL: <url> Branch: <head> → <base> Changes: +<additions> -<deletions> across <changedFiles> files CI Checks: <status summary or "pending" or "none configured"> Artifacts referenced: - <any PRDs/plans linked in PR body> Next steps: - gh pr view <number> --web → open in browser - /code-review <number> → review the PR - gh pr merge <number> → merge when ready ``` --- ## Edge Cases - **No `gh` CLI**: Stop with: "GitHub CLI (`gh`) is required. Install: <https://cli.github.com/>" - **Not authenticated**: Stop with: "Run `gh auth login` first." - **Force push needed**: If remote has diverged and rebase was done, use `git push --force-with-lease` (never `--force`). - **Multiple PR templates**: If `.github/PULL_REQUEST_TEMPLATE/` has multiple files, list them and ask user to choose. - **Large PR (>20 files)**: Warn about PR size. Suggest splitting if changes are logically separable.

package/packs/full-harness/rendered/.claude/commands/project-init.md

@@ -0,0 +1,6 @@
+---
+description: Detect a project's stack and produce a dry-run ECC onboarding plan using the repository's install manifests and stack mappings.
+argument-hint: [optional arguments]
+---
+
+# /project-init Create a safe, reviewable ECC onboarding plan for the current project. This command should start in dry-run mode and only write files after explicit user approval. ## Usage ```text /project-init /project-init --dry-run /project-init --target claude /project-init --target cursor /project-init --skills continuous-learning-v2,security-review /project-init --config ecc-install.json ``` ## Safety Rules 1. Default to dry-run. Do not modify `CLAUDE.md`, settings files, rules, skills, or install state until the user approves the concrete plan. 2. Preserve existing project guidance. If `CLAUDE.md`, `.claude/settings.local.json`, `.cursor/`, `.codex/`, `.gemini/`, `.opencode/`, `.codebuddy/`, `.joycode/`, or `.qwen/` already exists, inspect it and propose a merge/append plan instead of overwriting. 3. Use ECC's installer and manifest tooling. Do not hand-copy files or clone arbitrary remotes as an install shortcut. 4. Keep permissions narrow. Any generated settings should match detected build/test/lint tools and avoid broad shell access. 5. Report exactly what would change before applying anything. ## Detection Inputs Read the current project root and detect stack signals from: - package manager files: `package.json`, `package-lock.json`, `pnpm-lock.yaml`, `yarn.lock`, `bun.lockb` - language manifests: `pyproject.toml`, `requirements.txt`, `go.mod`, `Cargo.toml`, `pom.xml`, `build.gradle`, `build.gradle.kts` - framework files: `next.config.*`, `vite.config.*`, `tailwind.config.*`, `Dockerfile`, `docker-compose.yml` - ECC config: `ecc-install.json` - optional stack map: `config/project-stack-mappings.json` in the ECC repo When the ECC checkout is available, use `config/project-stack-mappings.json` as the stack-to-rules/skills reference. If the file is unavailable, fall back to the installed ECC manifests and explicit user choices. ## Planning Flow 1. Identify the target harness. Default to `claude` unless the user asks for `cursor`, `codex`, `gemini`, `opencode`, `codebuddy`, `joycode`, or `qwen`. 2. Detect stacks from project files and show the evidence for each match. 3. Resolve the smallest useful ECC plan: - project has an `ecc-install.json`: `node scripts/install-plan.js --config ecc-install.json --json` - user named a profile: `node scripts/install-plan.js --profile <profile> --target <target> --json` - user named skills: `node scripts/install-plan.js --skills <skill-ids> --target <target> --json` - only language stacks are detected: use the legacy language install dry-run with those language names 4. Run a dry-run apply command before writing: ```bash node scripts/install-apply.js --target <target> --dry-run --json <language-or-profile-args> ``` 5. Summarize detected stacks, selected modules/components/skills, target paths, skipped unsupported modules, and files that would be changed. 6. Ask for approval before applying the non-dry-run command. ## Output Contract Return: 1. detected stack evidence 2. proposed target harness 3. exact dry-run command used 4. exact apply command to run after approval 5. files/directories that would be created or changed 6. warnings about existing files, broad permissions, missing scripts, or unsupported targets ## CLAUDE.md Guidance If the user wants a `CLAUDE.md` starter, generate it separately from the installer plan and keep it minimal: - build command, if detected - test command, if detected - lint/typecheck command, if detected - dev server command, if detected - repo-specific notes from existing package scripts or manifests Never replace an existing `CLAUDE.md` without showing a diff and receiving approval. ## Related - `config/project-stack-mappings.json` for stack-to-surface hints - `scripts/install-plan.js` for deterministic plan resolution - `scripts/install-apply.js` for dry-run and apply operations - `/ecc-guide` for interactive feature discovery before installing

package/packs/full-harness/rendered/.claude/commands/projects.md

@@ -0,0 +1,6 @@
+---
+description: List known projects and their instinct statistics
+argument-hint: [optional arguments]
+---
+
+# Projects Command List project registry entries and per-project instinct/observation counts for continuous-learning-v2. ## Implementation Run the instinct CLI using the plugin root path: ```bash python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" projects ``` Or if `CLAUDE_PLUGIN_ROOT` is not set (manual installation): ```bash python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py projects ``` ## Usage ```bash /projects ``` ## What to Do 1. Read `~/.claude/homunculus/projects.json` 2. For each project, display: - Project name, id, root, remote - Personal and inherited instinct counts - Observation event count - Last seen timestamp 3. Also display global instinct totals

package/packs/full-harness/rendered/.claude/commands/promote.md

@@ -0,0 +1,6 @@
+---
+description: Promote project-scoped instincts to global scope
+argument-hint: [optional arguments]
+---
+
+# Promote Command Promote instincts from project scope to global scope in continuous-learning-v2. ## Implementation Run the instinct CLI using the plugin root path: ```bash python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" promote [instinct-id] [--force] [--dry-run] ``` Or if `CLAUDE_PLUGIN_ROOT` is not set (manual installation): ```bash python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py promote [instinct-id] [--force] [--dry-run] ``` ## Usage ```bash /promote # Auto-detect promotion candidates /promote --dry-run # Preview auto-promotion candidates /promote --force # Promote all qualified candidates without prompt /promote grep-before-edit # Promote one specific instinct from current project ``` ## What to Do 1. Detect current project 2. If `instinct-id` is provided, promote only that instinct (if present in current project) 3. Otherwise, find cross-project candidates that: - Appear in at least 2 projects - Meet confidence threshold 4. Write promoted instincts to `~/.claude/homunculus/instincts/personal/` with `scope: global`

package/packs/full-harness/rendered/.claude/commands/prp-commit.md

@@ -0,0 +1,6 @@
+---
+description: Quick commit with natural language file targeting — describe what to commit in plain English
+argument-hint: [target description] (blank = all changes)
+---
+
+# Smart Commit > Adapted from PRPs-agentic-eng by Wirasm. Part of the PRP workflow series. **Input**: $ARGUMENTS --- ## Phase 1 — ASSESS ```bash git status --short ``` If output is empty → stop: "Nothing to commit." Show the user a summary of what's changed (added, modified, deleted, untracked). --- ## Phase 2 — INTERPRET & STAGE Interpret `$ARGUMENTS` to determine what to stage: | Input | Interpretation | Git Command | |---|---|---| | *(blank / empty)* | Stage everything | `git add -A` | | `staged` | Use whatever is already staged | *(no git add)* | | `*.ts` or `*.py` etc. | Stage matching glob | `git add '*.ts'` | | `except tests` | Stage all, then unstage tests | `git add -A && git reset -- '**/*.test.*' '**/*.spec.*' '**/test_*' 2>/dev/null \|\| true` | | `only new files` | Stage untracked files only | `git ls-files --others --exclude-standard \| grep . && git ls-files --others --exclude-standard \| xargs git add` | | `the auth changes` | Interpret from status/diff — find auth-related files | `git add <matched files>` | | Specific filenames | Stage those files | `git add <files>` | For natural language inputs (like "the auth changes"), cross-reference the `git status` output and `git diff` to identify relevant files. Show the user which files you're staging and why. ```bash git add <determined files> ``` After staging, verify: ```bash git diff --cached --stat ``` If nothing staged, stop: "No files matched your description." --- ## Phase 3 — COMMIT Craft a single-line commit message in imperative mood: ``` {type}: {description} ``` Types: - `feat` — New feature or capability - `fix` — Bug fix - `refactor` — Code restructuring without behavior change - `docs` — Documentation changes - `test` — Adding or updating tests - `chore` — Build, config, dependencies - `perf` — Performance improvement - `ci` — CI/CD changes Rules: - Imperative mood ("add feature" not "added feature") - Lowercase after the type prefix - No period at the end - Under 72 characters - Describe WHAT changed, not HOW ```bash git commit -m "{type}: {description}" ``` --- ## Phase 4 — OUTPUT Report to user: ``` Committed: {hash_short} Message: {type}: {description} Files: {count} file(s) changed Next steps: - git push → push to remote - /prp-pr → create a pull request - /code-review → review before pushing ``` --- ## Examples | You say | What happens | |---|---| | `/prp-commit` | Stages all, auto-generates message | | `/prp-commit staged` | Commits only what's already staged | | `/prp-commit *.ts` | Stages all TypeScript files, commits | | `/prp-commit except tests` | Stages everything except test files | | `/prp-commit the database migration` | Finds DB migration files from status, stages them | | `/prp-commit only new files` | Stages untracked files only |

package/packs/full-harness/rendered/.claude/commands/prp-implement.md

@@ -0,0 +1,6 @@
+---
+description: Execute an implementation plan with rigorous validation loops
+argument-hint: <path/to/plan.md>
+---
+
+> Adapted from PRPs-agentic-eng by Wirasm. Part of the PRP workflow series. # PRP Implement Execute a plan file step-by-step with continuous validation. Every change is verified immediately — never accumulate broken state. **Core Philosophy**: Validation loops catch mistakes early. Run checks after every change. Fix issues immediately. **Golden Rule**: If a validation fails, fix it before moving on. Never accumulate broken state. --- ## Phase 0 — DETECT ### Package Manager Detection | File Exists | Package Manager | Runner | |---|---|---| | `bun.lockb` | bun | `bun run` | | `pnpm-lock.yaml` | pnpm | `pnpm run` | | `yarn.lock` | yarn | `yarn` | | `package-lock.json` | npm | `npm run` | | `pyproject.toml` or `requirements.txt` | uv / pip | `uv run` or `python -m` | | `Cargo.toml` | cargo | `cargo` | | `go.mod` | go | `go` | ### Validation Scripts Check `package.json` (or equivalent) for available scripts: ```bash # For Node.js projects cat package.json | grep -A 20 '"scripts"' ``` Note available commands for: type-check, lint, test, build. --- ## Phase 1 — LOAD Read the plan file: ```bash cat "$ARGUMENTS" ``` Extract these sections from the plan: - **Summary** — What is being built - **Patterns to Mirror** — Code conventions to follow - **Files to Change** — What to create or modify - **Step-by-Step Tasks** — Implementation sequence - **Validation Commands** — How to verify correctness - **Acceptance Criteria** — Definition of done If the file doesn't exist or isn't a valid plan: ``` Error: Plan file not found or invalid. Run /prp-plan <feature-description> to create a plan first. ``` **CHECKPOINT**: Plan loaded. All sections identified. Tasks extracted. --- ## Phase 2 — PREPARE ### Git State ```bash git branch --show-current git status --porcelain ``` ### Branch Decision | Current State | Action | |---|---| | On feature branch | Use current branch | | On main, clean working tree | Create feature branch: `git checkout -b feat/{plan-name}` | | On main, dirty working tree | **STOP** — Ask user to stash or commit first | | In a git worktree for this feature | Use the worktree | ### Sync Remote ```bash git pull --rebase origin $(git branch --show-current) 2>/dev/null || true ``` **CHECKPOINT**: On correct branch. Working tree ready. Remote synced. --- ## Phase 3 — EXECUTE Process each task from the plan sequentially. ### Per-Task Loop For each task in **Step-by-Step Tasks**: 1. **Read MIRROR reference** — Open the pattern file referenced in the task's MIRROR field. Understand the convention before writing code. 2. **Implement** — Write the code following the pattern exactly. Apply GOTCHA warnings. Use specified IMPORTS. 3. **Validate immediately** — After EVERY file change: ```bash # Run type-check (adjust command per project) [type-check command from Phase 0] ``` If type-check fails → fix the error before moving to the next file. 4. **Track progress** — Log: `[done] Task N: [task name] — complete` ### Handling Deviations If implementation must deviate from the plan: - Note **WHAT** changed - Note **WHY** it changed - Continue with the corrected approach - These deviations will be captured in the report **CHECKPOINT**: All tasks executed. Deviations logged. --- ## Phase 4 — VALIDATE Run all validation levels from the plan. Fix issues at each level before proceeding. ### Level 1: Static Analysis ```bash # Type checking — zero errors required [project type-check command] # Linting — fix automatically where possible [project lint command] [project lint-fix command] ``` If lint errors remain after auto-fix, fix manually. ### Level 2: Unit Tests Write tests for every new function (as specified in the plan's Testing Strategy). ```bash [project test command for affected area] ``` - Every function needs at least one test - Cover edge cases listed in the plan - If a test fails → fix the implementation (not the test, unless the test is wrong) ### Level 3: Build Check ```bash [project build command] ``` Build must succeed with zero errors. ### Level 4: Integration Testing (if applicable) ```bash # Start server, run tests, stop server [project dev server command] & SERVER_PID=$! # Wait for server to be ready (adjust port as needed) SERVER_READY=0 for i in $(seq 1 30); do if curl -sf http://localhost:PORT/health >/dev/null 2>&1; then SERVER_READY=1 break fi sleep 1 done if [ "$SERVER_READY" -ne 1 ]; then kill "$SERVER_PID" 2>/dev/null || true echo "ERROR: Server failed to start within 30s" >&2 exit 1 fi [integration test command] TEST_EXIT=$? kill "$SERVER_PID" 2>/dev/null || true wait "$SERVER_PID" 2>/dev/null || true exit "$TEST_EXIT" ``` ### Level 5: Edge Case Testing Run through edge cases from the plan's Testing Strategy checklist. **CHECKPOINT**: All 5 validation levels pass. Zero errors. --- ## Phase 5 — REPORT ### Create Implementation Report ```bash mkdir -p .claude/PRPs/reports ``` Write report to `.claude/PRPs/reports/{plan-name}-report.md`: ```markdown # Implementation Report: [Feature Name] ## Summary [What was implemented] ## Assessment vs Reality | Metric | Predicted (Plan) | Actual | |---|---|---| | Complexity | [from plan] | [actual] | | Confidence | [from plan] | [actual] | | Files Changed | [from plan] | [actual count] | ## Tasks Completed | # | Task | Status | Notes | |---|---|---|---| | 1 | [task name] | [done] Complete | | | 2 | [task name] | [done] Complete | Deviated — [reason] | ## Validation Results | Level | Status | Notes | |---|---|---| | Static Analysis | [done] Pass | | | Unit Tests | [done] Pass | N tests written | | Build | [done] Pass | | | Integration | [done] Pass | or N/A | | Edge Cases | [done] Pass | | ## Files Changed | File | Action | Lines | |---|---|---| | `path/to/file` | CREATED | +N | | `path/to/file` | UPDATED | +N / -M | ## Deviations from Plan [List any deviations with WHAT and WHY, or "None"] ## Issues Encountered [List any problems and how they were resolved, or "None"] ## Tests Written | Test File | Tests | Coverage | |---|---|---| | `path/to/test` | N tests | [area covered] | ## Next Steps - [ ] Code review via `/code-review` - [ ] Create PR via `/prp-pr` ``` ### Update PRD (if applicable) If this implementation was for a PRD phase: 1. Update the phase status from `in-progress` to `complete` 2. Add report path as reference ### Archive Plan ```bash mkdir -p .claude/PRPs/plans/completed mv "$ARGUMENTS" .claude/PRPs/plans/completed/ ``` **CHECKPOINT**: Report created. PRD updated. Plan archived. --- ## Phase 6 — OUTPUT Report to user: ``` ## Implementation Complete - **Plan**: [plan file path] → archived to completed/ - **Branch**: [current branch name] - **Status**: [done] All tasks complete ### Validation Summary | Check | Status | |---|---| | Type Check | [done] | | Lint | [done] | | Tests | [done] (N written) | | Build | [done] | | Integration | [done] or N/A | ### Files Changed - [N] files created, [M] files updated ### Deviations [Summary or "None — implemented exactly as planned"] ### Artifacts - Report: `.claude/PRPs/reports/{name}-report.md` - Archived Plan: `.claude/PRPs/plans/completed/{name}.plan.md` ### PRD Progress (if applicable) | Phase | Status | |---|---| | Phase 1 | [done] Complete | | Phase 2 | [next] | | ... | ... | > Next step: Run `/prp-pr` to create a pull request, or `/code-review` to review changes first. ``` --- ## Handling Failures ### Type Check Fails 1. Read the error message carefully 2. Fix the type error in the source file 3. Re-run type-check 4. Continue only when clean ### Tests Fail 1. Identify whether the bug is in the implementation or the test 2. Fix the root cause (usually the implementation) 3. Re-run tests 4. Continue only when green ### Lint Fails 1. Run auto-fix first 2. If errors remain, fix manually 3. Re-run lint 4. Continue only when clean ### Build Fails 1. Usually a type or import issue — check error message 2. Fix the offending file 3. Re-run build 4. Continue only when successful ### Integration Test Fails 1. Check server started correctly 2. Verify endpoint/route exists 3. Check request format matches expected 4. Fix and re-run --- ## Success Criteria - **TASKS_COMPLETE**: All tasks from the plan executed - **TYPES_PASS**: Zero type errors - **LINT_PASS**: Zero lint errors - **TESTS_PASS**: All tests green, new tests written - **BUILD_PASS**: Build succeeds - **REPORT_CREATED**: Implementation report saved - **PLAN_ARCHIVED**: Plan moved to `completed/` --- ## Next Steps - Run `/code-review` to review changes before committing - Run `/prp-commit` to commit with a descriptive message - Run `/prp-pr` to create a pull request - Run `/prp-plan <next-phase>` if the PRD has more phases

package/packs/full-harness/rendered/.claude/commands/prp-plan.md

@@ -0,0 +1,6 @@
+---
+description: Create comprehensive feature implementation plan with codebase analysis and pattern extraction
+argument-hint: <feature description | path/to/prd.md>
+---
+
+> Adapted from PRPs-agentic-eng by Wirasm. Part of the PRP workflow series. # PRP Plan Create a detailed, self-contained implementation plan that captures all codebase patterns, conventions, and context needed to implement a feature in a single pass. **Core Philosophy**: A great plan contains everything needed to implement without asking further questions. Every pattern, every convention, every gotcha — captured once, referenced throughout. **Golden Rule**: If you would need to search the codebase during implementation, capture that knowledge NOW in the plan. --- ## Phase 0 — DETECT Determine input type from `$ARGUMENTS`: | Input Pattern | Detection | Action | |---|---|---| | Path ending in `.prd.md` | File path to PRD | Parse PRD, find next pending phase | | Path to `.md` with "Implementation Phases" | PRD-like document | Parse phases, find next pending | | Path to any other file | Reference file | Read file for context, treat as free-form | | Free-form text | Feature description | Proceed directly to Phase 1 | | Empty / blank | No input | Ask user what feature to plan | ### PRD Parsing (when input is a PRD) 1. Read the PRD file with `cat "$PRD_PATH"` 2. Parse the **Implementation Phases** section 3. Find phases by status: - Look for `pending` phases - Check dependency chains (a phase may depend on prior phases being `complete`) - Select the **next eligible pending phase** 4. Extract from the selected phase: - Phase name and description - Acceptance criteria - Dependencies on prior phases - Any scope notes or constraints 5. Use the phase description as the feature to plan If no pending phases remain, report that all phases are complete. --- ## Phase 1 — PARSE Extract and clarify the feature requirements. ### Feature Understanding From the input (PRD phase or free-form description), identify: - **What** is being built (concrete deliverable) - **Why** it matters (user value) - **Who** uses it (target user/system) - **Where** it fits (which part of the codebase) ### User Story Format as: ``` As a [type of user], I want [capability], So that [benefit]. ``` ### Complexity Assessment | Level | Indicators | Typical Scope | |---|---|---| | **Small** | Single file, isolated change, no new dependencies | 1-3 files, <100 lines | | **Medium** | Multiple files, follows existing patterns, minor new concepts | 3-10 files, 100-500 lines | | **Large** | Cross-cutting concerns, new patterns, external integrations | 10+ files, 500+ lines | | **XL** | Architectural changes, new subsystems, migration needed | 20+ files, consider splitting | ### Ambiguity Gate If any of these are unclear, **STOP and ask the user** before proceeding: - The core deliverable is vague - Success criteria are undefined - There are multiple valid interpretations - Technical approach has major unknowns Do NOT guess. Ask. A plan built on assumptions fails during implementation. --- ## Phase 2 — EXPLORE Gather deep codebase intelligence. Search the codebase directly for each category below. ### Codebase Search (8 Categories) For each category, search using grep, find, and file reading: 1. **Similar Implementations** — Find existing features that resemble the planned one. Look for analogous patterns, endpoints, components, or modules. 2. **Naming Conventions** — Identify how files, functions, variables, classes, and exports are named in the relevant area of the codebase. 3. **Error Handling** — Find how errors are caught, propagated, logged, and returned to users in similar code paths. 4. **Logging Patterns** — Identify what gets logged, at what level, and in what format. 5. **Type Definitions** — Find relevant types, interfaces, schemas, and how they're organized. 6. **Test Patterns** — Find how similar features are tested. Note test file locations, naming, setup/teardown patterns, and assertion styles. 7. **Configuration** — Find relevant config files, environment variables, and feature flags. 8. **Dependencies** — Identify packages, imports, and internal modules used by similar features. ### Codebase Analysis (5 Traces) Read relevant files to trace: 1. **Entry Points** — How does a request/action enter the system and reach the area you're modifying? 2. **Data Flow** — How does data move through the relevant code paths? 3. **State Changes** — What state is modified and where? 4. **Contracts** — What interfaces, APIs, or protocols must be honored? 5. **Patterns** — What architectural patterns are used (repository, service, controller, etc.)? ### Unified Discovery Table Compile findings into a single reference: | Category | File:Lines | Pattern | Key Snippet | |---|---|---|---| | Naming | `src/services/userService.ts:1-5` | camelCase services, PascalCase types | `export class UserService` | | Error | `src/middleware/errorHandler.ts:10-25` | Custom AppError class | `throw new AppError(...)` | | ... | ... | ... | ... | --- ## Phase 3 — RESEARCH If the feature involves external libraries, APIs, or unfamiliar technology: 1. Search the web for official documentation 2. Find usage examples and best practices 3. Identify version-specific gotchas Format each finding as: ``` KEY_INSIGHT: [what you learned] APPLIES_TO: [which part of the plan this affects] GOTCHA: [any warnings or version-specific issues] ``` If the feature uses only well-understood internal patterns, skip this phase and note: "No external research needed — feature uses established internal patterns." --- ## Phase 4 — DESIGN ### UX Transformation (if applicable) Document the before/after user experience: **Before:** ``` ┌─────────────────────────────┐ │ [Current user experience] │ │ Show the current flow, │ │ what the user sees/does │ └─────────────────────────────┘ ``` **After:** ``` ┌─────────────────────────────┐ │ [New user experience] │ │ Show the improved flow, │ │ what changes for the user │ └─────────────────────────────┘ ``` ### Interaction Changes | Touchpoint | Before | After | Notes | |---|---|---|---| | ... | ... | ... | ... | If the feature is purely backend/internal with no UX change, note: "Internal change — no user-facing UX transformation." --- ## Phase 5 — ARCHITECT ### Strategic Design Define the implementation approach: - **Approach**: High-level strategy (e.g., "Add new service layer following existing repository pattern") - **Alternatives Considered**: What other approaches were evaluated and why they were rejected - **Scope**: Concrete boundaries of what WILL be built - **NOT Building**: Explicit list of what is OUT OF SCOPE (prevents scope creep during implementation) --- ## Phase 6 — GENERATE Write the full plan document using the template below. Save to `.claude/PRPs/plans/{kebab-case-feature-name}.plan.md`. Create the directory if it doesn't exist: ```bash mkdir -p .claude/PRPs/plans ``` ### Plan Template ````markdown # Plan: [Feature Name] ## Summary [2-3 sentence overview] ## User Story As a [user], I want [capability], so that [benefit]. ## Problem → Solution [Current state] → [Desired state] ## Metadata - **Complexity**: [Small | Medium | Large | XL] - **Source PRD**: [path or "N/A"] - **PRD Phase**: [phase name or "N/A"] - **Estimated Files**: [count] --- ## UX Design ### Before [ASCII diagram or "N/A — internal change"] ### After [ASCII diagram or "N/A — internal change"] ### Interaction Changes | Touchpoint | Before | After | Notes | |---|---|---|---| --- ## Mandatory Reading Files that MUST be read before implementing: | Priority | File | Lines | Why | |---|---|---|---| | P0 (critical) | `path/to/file` | 1-50 | Core pattern to follow | | P1 (important) | `path/to/file` | 10-30 | Related types | | P2 (reference) | `path/to/file` | all | Similar implementation | ## External Documentation | Topic | Source | Key Takeaway | |---|---|---| | ... | ... | ... | --- ## Patterns to Mirror Code patterns discovered in the codebase. Follow these exactly. ### NAMING_CONVENTION // SOURCE: [file:lines] [actual code snippet showing the naming pattern] ### ERROR_HANDLING // SOURCE: [file:lines] [actual code snippet showing error handling] ### LOGGING_PATTERN // SOURCE: [file:lines] [actual code snippet showing logging] ### REPOSITORY_PATTERN // SOURCE: [file:lines] [actual code snippet showing data access] ### SERVICE_PATTERN // SOURCE: [file:lines] [actual code snippet showing service layer] ### TEST_STRUCTURE // SOURCE: [file:lines] [actual code snippet showing test setup] --- ## Files to Change | File | Action | Justification | |---|---|---| | `path/to/file.ts` | CREATE | New service for feature | | `path/to/existing.ts` | UPDATE | Add new method | ## NOT Building - [Explicit item 1 that is out of scope] - [Explicit item 2 that is out of scope] --- ## Step-by-Step Tasks ### Task 1: [Name] - **ACTION**: [What to do] - **IMPLEMENT**: [Specific code/logic to write] - **MIRROR**: [Pattern from Patterns to Mirror section to follow] - **IMPORTS**: [Required imports] - **GOTCHA**: [Known pitfall to avoid] - **VALIDATE**: [How to verify this task is correct] ### Task 2: [Name] - **ACTION**: ... - **IMPLEMENT**: ... - **MIRROR**: ... - **IMPORTS**: ... - **GOTCHA**: ... - **VALIDATE**: ... [Continue for all tasks...] --- ## Testing Strategy ### Unit Tests | Test | Input | Expected Output | Edge Case? | |---|---|---|---| | ... | ... | ... | ... | ### Edge Cases Checklist - [ ] Empty input - [ ] Maximum size input - [ ] Invalid types - [ ] Concurrent access - [ ] Network failure (if applicable) - [ ] Permission denied --- ## Validation Commands ### Static Analysis ```bash # Run type checker [project-specific type check command] ``` EXPECT: Zero type errors ### Unit Tests ```bash # Run tests for affected area [project-specific test command] ``` EXPECT: All tests pass ### Full Test Suite ```bash # Run complete test suite [project-specific full test command] ``` EXPECT: No regressions ### Database Validation (if applicable) ```bash # Verify schema/migrations [project-specific db command] ``` EXPECT: Schema up to date ### Browser Validation (if applicable) ```bash # Start dev server and verify [project-specific dev server command] ``` EXPECT: Feature works as designed ### Manual Validation - [ ] [Step-by-step manual verification checklist] --- ## Acceptance Criteria - [ ] All tasks completed - [ ] All validation commands pass - [ ] Tests written and passing - [ ] No type errors - [ ] No lint errors - [ ] Matches UX design (if applicable) ## Completion Checklist - [ ] Code follows discovered patterns - [ ] Error handling matches codebase style - [ ] Logging follows codebase conventions - [ ] Tests follow test patterns - [ ] No hardcoded values - [ ] Documentation updated (if needed) - [ ] No unnecessary scope additions - [ ] Self-contained — no questions needed during implementation ## Risks | Risk | Likelihood | Impact | Mitigation | |---|---|---|---| | ... | ... | ... | ... | ## Notes [Any additional context, decisions, or observations] ``` --- ## Output ### Save the Plan Write the generated plan to: ``` .claude/PRPs/plans/{kebab-case-feature-name}.plan.md ``` ### Update PRD (if input was a PRD) If this plan was generated from a PRD phase: 1. Update the phase status from `pending` to `in-progress` 2. Add the plan file path as a reference in the phase ### Report to User ``` ## Plan Created - **File**: .claude/PRPs/plans/{kebab-case-feature-name}.plan.md - **Source PRD**: [path or "N/A"] - **Phase**: [phase name or "standalone"] - **Complexity**: [level] - **Scope**: [N files, M tasks] - **Key Patterns**: [top 3 discovered patterns] - **External Research**: [topics researched or "none needed"] - **Risks**: [top risk or "none identified"] - **Confidence Score**: [1-10] — likelihood of single-pass implementation > Next step: Run `/prp-implement .claude/PRPs/plans/{name}.plan.md` to execute this plan. ``` --- ## Verification Before finalizing, verify the plan against these checklists: ### Context Completeness - [ ] All relevant files discovered and documented - [ ] Naming conventions captured with examples - [ ] Error handling patterns documented - [ ] Test patterns identified - [ ] Dependencies listed ### Implementation Readiness - [ ] Every task has ACTION, IMPLEMENT, MIRROR, and VALIDATE - [ ] No task requires additional codebase searching - [ ] Import paths are specified - [ ] GOTCHAs documented where applicable ### Pattern Faithfulness - [ ] Code snippets are actual codebase examples (not invented) - [ ] SOURCE references point to real files and line numbers - [ ] Patterns cover naming, errors, logging, data access, and tests - [ ] New code will be indistinguishable from existing code ### Validation Coverage - [ ] Static analysis commands specified - [ ] Test commands specified - [ ] Build verification included ### UX Clarity - [ ] Before/after states documented (or marked N/A) - [ ] Interaction changes listed - [ ] Edge cases for UX identified ### No Prior Knowledge Test A developer unfamiliar with this codebase should be able to implement the feature using ONLY this plan, without searching the codebase or asking questions. If not, add the missing context. --- ## Next Steps - Run `/prp-implement <plan-path>` to execute this plan - Run `/plan` for quick conversational planning without artifacts - Run `/prp-prd` to create a PRD first if scope is unclear ````

package/packs/full-harness/rendered/.claude/commands/prp-pr.md

@@ -0,0 +1,6 @@
+---
+description: Create a GitHub PR from current branch with unpushed commits — discovers templates, analyzes changes, pushes
+argument-hint: [base-branch] (default: main)
+---
+
+# Create Pull Request > Adapted from PRPs-agentic-eng by Wirasm. Part of the PRP workflow series. **Input**: `$ARGUMENTS` — optional, may contain a base branch name and/or flags (e.g., `--draft`). **Parse `$ARGUMENTS`**: - Extract any recognized flags (`--draft`) - Treat remaining non-flag text as the base branch name - Default base branch to `main` if none specified --- ## Phase 1 — VALIDATE Check preconditions: ```bash git branch --show-current git status --short git log origin/<base>..HEAD --oneline ``` | Check | Condition | Action if Failed | |---|---|---| | Not on base branch | Current branch ≠ base | Stop: "Switch to a feature branch first." | | Clean working directory | No uncommitted changes | Warn: "You have uncommitted changes. Commit or stash first. Use `/prp-commit` to commit." | | Has commits ahead | `git log origin/<base>..HEAD` not empty | Stop: "No commits ahead of `<base>`. Nothing to PR." | | No existing PR | `gh pr list --head <branch> --json number` is empty | Stop: "PR already exists: #<number>. Use `gh pr view <number> --web` to open it." | If all checks pass, proceed. --- ## Phase 2 — DISCOVER ### PR Template Search for PR template in order: 1. `.github/PULL_REQUEST_TEMPLATE/` directory — if exists, list files and let user choose (or use `default.md`) 2. `.github/PULL_REQUEST_TEMPLATE.md` 3. `.github/pull_request_template.md` 4. `docs/pull_request_template.md` If found, read it and use its structure for the PR body. ### Commit Analysis ```bash git log origin/<base>..HEAD --format="%h %s" --reverse ``` Analyze commits to determine: - **PR title**: Use conventional commit format with type prefix — `feat: ...`, `fix: ...`, etc. - If multiple types, use the dominant one - If single commit, use its message as-is - **Change summary**: Group commits by type/area ### File Analysis ```bash git diff origin/<base>..HEAD --stat git diff origin/<base>..HEAD --name-only ``` Categorize changed files: source, tests, docs, config, migrations. ### PRP Artifacts Check for related PRP artifacts: - `.claude/PRPs/reports/` — Implementation reports - `.claude/PRPs/plans/` — Plans that were executed - `.claude/PRPs/prds/` — Related PRDs Reference these in the PR body if they exist. --- ## Phase 3 — PUSH ```bash git push -u origin HEAD ``` If push fails due to divergence: ```bash git fetch origin git rebase origin/<base> git push -u origin HEAD ``` If rebase conflicts occur, stop and inform the user. --- ## Phase 4 — CREATE ### With Template If a PR template was found in Phase 2, fill in each section using the commit and file analysis. Preserve all template sections — leave sections as "N/A" if not applicable rather than removing them. ### Without Template Use this default format: ```markdown ## Summary <1-2 sentence description of what this PR does and why> ## Changes <bulleted list of changes grouped by area> ## Files Changed <table or list of changed files with change type: Added/Modified/Deleted> ## Testing <description of how changes were tested, or "Needs testing"> ## Related Issues <linked issues with Closes/Fixes/Relates to #N, or "None"> ``` ### Create the PR ```bash gh pr create \ --title "<PR title>" \ --base <base-branch> \ --body "<PR body>" # Add --draft if the --draft flag was parsed from $ARGUMENTS ``` --- ## Phase 5 — VERIFY ```bash gh pr view --json number,url,title,state,baseRefName,headRefName,additions,deletions,changedFiles gh pr checks --json name,status,conclusion 2>/dev/null || true ``` --- ## Phase 6 — OUTPUT Report to user: ``` PR #<number>: <title> URL: <url> Branch: <head> → <base> Changes: +<additions> -<deletions> across <changedFiles> files CI Checks: <status summary or "pending" or "none configured"> Artifacts referenced: - <any PRP reports/plans linked in PR body> Next steps: - gh pr view <number> --web → open in browser - /code-review <number> → review the PR - gh pr merge <number> → merge when ready ``` --- ## Edge Cases - **No `gh` CLI**: Stop with: "GitHub CLI (`gh`) is required. Install: <https://cli.github.com/>" - **Not authenticated**: Stop with: "Run `gh auth login` first." - **Force push needed**: If remote has diverged and rebase was done, use `git push --force-with-lease` (never `--force`). - **Multiple PR templates**: If `.github/PULL_REQUEST_TEMPLATE/` has multiple files, list them and ask user to choose. - **Large PR (>20 files)**: Warn about PR size. Suggest splitting if changes are logically separable.

package/packs/full-harness/rendered/.claude/commands/prp-prd.md

@@ -0,0 +1,6 @@
+---
+description: Interactive PRD generator - problem-first, hypothesis-driven product spec with back-and-forth questioning
+argument-hint: [feature/product idea] (blank = start with questions)
+---
+
+# Product Requirements Document Generator > Adapted from PRPs-agentic-eng by Wirasm. Part of the PRP workflow series. **Input**: $ARGUMENTS --- ## Your Role You are a sharp product manager who: - Starts with PROBLEMS, not solutions - Demands evidence before building - Thinks in hypotheses, not specs - Asks clarifying questions before assuming - Acknowledges uncertainty honestly **Anti-pattern**: Don't fill sections with fluff. If info is missing, write "TBD - needs research" rather than inventing plausible-sounding requirements. --- ## Process Overview ``` QUESTION SET 1 → GROUNDING → QUESTION SET 2 → RESEARCH → QUESTION SET 3 → GENERATE ``` Each question set builds on previous answers. Grounding phases validate assumptions. --- ## Phase 1: INITIATE - Core Problem **If no input provided**, ask: > **What do you want to build?** > Describe the product, feature, or capability in a few sentences. **If input provided**, confirm understanding by restating: > I understand you want to build: {restated understanding} > Is this correct, or should I adjust my understanding? **GATE**: Wait for user response before proceeding. --- ## Phase 2: FOUNDATION - Problem Discovery Ask these questions (present all at once, user can answer together): > **Foundation Questions:** > > 1. **Who** has this problem? Be specific - not just "users" but what type of person/role? > > 2. **What** problem are they facing? Describe the observable pain, not the assumed need. > > 3. **Why** can't they solve it today? What alternatives exist and why do they fail? > > 4. **Why now?** What changed that makes this worth building? > > 5. **How** will you know if you solved it? What would success look like? **GATE**: Wait for user responses before proceeding. --- ## Phase 3: GROUNDING - Market & Context Research After foundation answers, conduct research: **Research market context:** 1. Find similar products/features in the market 2. Identify how competitors solve this problem 3. Note common patterns and anti-patterns 4. Check for recent trends or changes in this space Compile findings with direct links, key insights, and any gaps in available information. **If a codebase exists, explore it in parallel:** 1. Find existing functionality relevant to the product/feature idea 2. Identify patterns that could be leveraged 3. Note technical constraints or opportunities Record file locations, code patterns, and conventions observed. **Summarize findings to user:** > **What I found:** > - {Market insight 1} > - {Competitor approach} > - {Relevant pattern from codebase, if applicable} > > Does this change or refine your thinking? **GATE**: Brief pause for user input (can be "continue" or adjustments). --- ## Phase 4: DEEP DIVE - Vision & Users Based on foundation + research, ask: > **Vision & Users:** > > 1. **Vision**: In one sentence, what's the ideal end state if this succeeds wildly? > > 2. **Primary User**: Describe your most important user - their role, context, and what triggers their need. > > 3. **Job to Be Done**: Complete this: "When [situation], I want to [motivation], so I can [outcome]." > > 4. **Non-Users**: Who is explicitly NOT the target? Who should we ignore? > > 5. **Constraints**: What limitations exist? (time, budget, technical, regulatory) **GATE**: Wait for user responses before proceeding. --- ## Phase 5: GROUNDING - Technical Feasibility **If a codebase exists, perform two parallel investigations:** Investigation 1 — Explore feasibility: 1. Identify existing infrastructure that can be leveraged 2. Find similar patterns already implemented 3. Map integration points and dependencies 4. Locate relevant configuration and type definitions Record file locations, code patterns, and conventions observed. Investigation 2 — Analyze constraints: 1. Trace how existing related features are implemented end-to-end 2. Map data flow through potential integration points 3. Identify architectural patterns and boundaries 4. Estimate complexity based on similar features Document what exists with precise file:line references. No suggestions. **If no codebase, research technical approaches:** 1. Find technical approaches others have used 2. Identify common implementation patterns 3. Note known technical challenges and pitfalls Compile findings with citations and gap analysis. **Summarize to user:** > **Technical Context:** > - Feasibility: {HIGH/MEDIUM/LOW} because {reason} > - Can leverage: {existing patterns/infrastructure} > - Key technical risk: {main concern} > > Any technical constraints I should know about? **GATE**: Brief pause for user input. --- ## Phase 6: DECISIONS - Scope & Approach Ask final clarifying questions: > **Scope & Approach:** > > 1. **MVP Definition**: What's the absolute minimum to test if this works? > > 2. **Must Have vs Nice to Have**: What 2-3 things MUST be in v1? What can wait? > > 3. **Key Hypothesis**: Complete this: "We believe [capability] will [solve problem] for [users]. We'll know we're right when [measurable outcome]." > > 4. **Out of Scope**: What are you explicitly NOT building (even if users ask)? > > 5. **Open Questions**: What uncertainties could change the approach? **GATE**: Wait for user responses before generating. --- ## Phase 7: GENERATE - Write PRD **Output path**: `.claude/PRPs/prds/{kebab-case-name}.prd.md` Create directory if needed: `mkdir -p .claude/PRPs/prds` ### PRD Template ```markdown # {Product/Feature Name} ## Problem Statement {2-3 sentences: Who has what problem, and what's the cost of not solving it?} ## Evidence - {User quote, data point, or observation that proves this problem exists} - {Another piece of evidence} - {If none: "Assumption - needs validation through [method]"} ## Proposed Solution {One paragraph: What we're building and why this approach over alternatives} ## Key Hypothesis We believe {capability} will {solve problem} for {users}. We'll know we're right when {measurable outcome}. ## What We're NOT Building - {Out of scope item 1} - {why} - {Out of scope item 2} - {why} ## Success Metrics | Metric | Target | How Measured | |--------|--------|--------------| | {Primary metric} | {Specific number} | {Method} | | {Secondary metric} | {Specific number} | {Method} | ## Open Questions - [ ] {Unresolved question 1} - [ ] {Unresolved question 2} --- ## Users & Context **Primary User** - **Who**: {Specific description} - **Current behavior**: {What they do today} - **Trigger**: {What moment triggers the need} - **Success state**: {What "done" looks like} **Job to Be Done** When {situation}, I want to {motivation}, so I can {outcome}. **Non-Users** {Who this is NOT for and why} --- ## Solution Detail ### Core Capabilities (MoSCoW) | Priority | Capability | Rationale | |----------|------------|-----------| | Must | {Feature} | {Why essential} | | Must | {Feature} | {Why essential} | | Should | {Feature} | {Why important but not blocking} | | Could | {Feature} | {Nice to have} | | Won't | {Feature} | {Explicitly deferred and why} | ### MVP Scope {What's the minimum to validate the hypothesis} ### User Flow {Critical path - shortest journey to value} --- ## Technical Approach **Feasibility**: {HIGH/MEDIUM/LOW} **Architecture Notes** - {Key technical decision and why} - {Dependency or integration point} **Technical Risks** | Risk | Likelihood | Mitigation | |------|------------|------------| | {Risk} | {H/M/L} | {How to handle} | --- ## Implementation Phases <!-- STATUS: pending | in-progress | complete PARALLEL: phases that can run concurrently (e.g., "with 3" or "-") DEPENDS: phases that must complete first (e.g., "1, 2" or "-") PRP: link to generated plan file once created --> | # | Phase | Description | Status | Parallel | Depends | PRP Plan | |---|-------|-------------|--------|----------|---------|----------| | 1 | {Phase name} | {What this phase delivers} | pending | - | - | - | | 2 | {Phase name} | {What this phase delivers} | pending | - | 1 | - | | 3 | {Phase name} | {What this phase delivers} | pending | with 4 | 2 | - | | 4 | {Phase name} | {What this phase delivers} | pending | with 3 | 2 | - | | 5 | {Phase name} | {What this phase delivers} | pending | - | 3, 4 | - | ### Phase Details **Phase 1: {Name}** - **Goal**: {What we're trying to achieve} - **Scope**: {Bounded deliverables} - **Success signal**: {How we know it's done} **Phase 2: {Name}** - **Goal**: {What we're trying to achieve} - **Scope**: {Bounded deliverables} - **Success signal**: {How we know it's done} {Continue for each phase...} ### Parallelism Notes {Explain which phases can run in parallel and why} --- ## Decisions Log | Decision | Choice | Alternatives | Rationale | |----------|--------|--------------|-----------| | {Decision} | {Choice} | {Options considered} | {Why this one} | --- ## Research Summary **Market Context** {Key findings from market research} **Technical Context** {Key findings from technical exploration} --- *Generated: {timestamp}* *Status: DRAFT - needs validation* ``` --- ## Phase 8: OUTPUT - Summary After generating, report: ```markdown ## PRD Created **File**: `.claude/PRPs/prds/{name}.prd.md` ### Summary **Problem**: {One line} **Solution**: {One line} **Key Metric**: {Primary success metric} ### Validation Status | Section | Status | |---------|--------| | Problem Statement | {Validated/Assumption} | | User Research | {Done/Needed} | | Technical Feasibility | {Assessed/TBD} | | Success Metrics | {Defined/Needs refinement} | ### Open Questions ({count}) {List the open questions that need answers} ### Recommended Next Step {One of: user research, technical spike, prototype, stakeholder review, etc.} ### Implementation Phases | # | Phase | Status | Can Parallel | |---|-------|--------|--------------| {Table of phases from PRD} ### To Start Implementation Run: `/prp-plan .claude/PRPs/prds/{name}.prd.md` This will automatically select the next pending phase and create an implementation plan. ``` --- ## Question Flow Summary ``` ┌─────────────────────────────────────────────────────────┐ │ INITIATE: "What do you want to build?" │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ FOUNDATION: Who, What, Why, Why now, How to measure │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ GROUNDING: Market research, competitor analysis │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ DEEP DIVE: Vision, Primary user, JTBD, Constraints │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ GROUNDING: Technical feasibility, codebase exploration │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ DECISIONS: MVP, Must-haves, Hypothesis, Out of scope │ └─────────────────────────────────────────────────────────┘ ↓ ┌─────────────────────────────────────────────────────────┐ │ GENERATE: Write PRD to .claude/PRPs/prds/ │ └─────────────────────────────────────────────────────────┘ ``` --- ## Integration with ECC After PRD generation: - Use `/prp-plan` to create implementation plans from PRD phases - Use `/plan` for simpler planning without PRD structure - Use `/save-session` to preserve PRD context across sessions ## Success Criteria - **PROBLEM_VALIDATED**: Problem is specific and evidenced (or marked as assumption) - **USER_DEFINED**: Primary user is concrete, not generic - **HYPOTHESIS_CLEAR**: Testable hypothesis with measurable outcome - **SCOPE_BOUNDED**: Clear must-haves and explicit out-of-scope - **QUESTIONS_ACKNOWLEDGED**: Uncertainties are listed, not hidden - **ACTIONABLE**: A skeptic could understand why this is worth building

package/packs/full-harness/rendered/.claude/commands/prune.md

@@ -0,0 +1,6 @@
+---
+description: Delete pending instincts older than 30 days that were never promoted
+argument-hint: [optional arguments]
+---
+
+# Prune Pending Instincts Remove expired pending instincts that were auto-generated but never reviewed or promoted. ## Implementation Run the instinct CLI using the plugin root path: ```bash python3 "${CLAUDE_PLUGIN_ROOT}/skills/continuous-learning-v2/scripts/instinct-cli.py" prune ``` Or if `CLAUDE_PLUGIN_ROOT` is not set (manual installation): ```bash python3 ~/.claude/skills/continuous-learning-v2/scripts/instinct-cli.py prune ``` ## Usage ``` /prune # Delete instincts older than 30 days /prune --max-age 60 # Custom age threshold (days) /prune --dry-run # Preview without deleting ```

package/packs/full-harness/rendered/.claude/commands/python-review.md

@@ -0,0 +1,6 @@
+---
+description: Comprehensive Python code review for PEP 8 compliance, type hints, security, and Pythonic idioms. Invokes the python-reviewer agent.
+argument-hint: [optional arguments]
+---
+
+# Python Code Review This command invokes the **python-reviewer** agent for comprehensive Python-specific code review. ## What This Command Does 1. **Identify Python Changes**: Find modified `.py` files via `git diff` 2. **Run Static Analysis**: Execute `ruff`, `mypy`, `pylint`, `black --check` 3. **Security Scan**: Check for SQL injection, command injection, unsafe deserialization 4. **Type Safety Review**: Analyze type hints and mypy errors 5. **Pythonic Code Check**: Verify code follows PEP 8 and Python best practices 6. **Generate Report**: Categorize issues by severity ## When to Use Use `/python-review` when: - After writing or modifying Python code - Before committing Python changes - Reviewing pull requests with Python code - Onboarding to a new Python codebase - Learning Pythonic patterns and idioms ## Review Categories ### CRITICAL (Must Fix) - SQL/Command injection vulnerabilities - Unsafe eval/exec usage - Pickle unsafe deserialization - Hardcoded credentials - YAML unsafe load - Bare except clauses hiding errors ### HIGH (Should Fix) - Missing type hints on public functions - Mutable default arguments - Swallowing exceptions silently - Not using context managers for resources - C-style looping instead of comprehensions - Using type() instead of isinstance() - Race conditions without locks ### MEDIUM (Consider) - PEP 8 formatting violations - Missing docstrings on public functions - Print statements instead of logging - Inefficient string operations - Magic numbers without named constants - Not using f-strings for formatting - Unnecessary list creation ## Automated Checks Run ```bash # Type checking mypy . # Linting and formatting ruff check . black --check . isort --check-only . # Security scanning bandit -r . # Dependency audit pip-audit safety check # Testing pytest --cov=app --cov-report=term-missing ``` ## Example Usage ```text User: /python-review Agent: # Python Code Review Report ## Files Reviewed - app/routes/user.py (modified) - app/services/auth.py (modified) ## Static Analysis Results ✓ ruff: No issues ✓ mypy: No errors WARNING: black: 2 files need reformatting ✓ bandit: No security issues ## Issues Found [CRITICAL] SQL Injection vulnerability File: app/routes/user.py:42 Issue: User input directly interpolated into SQL query ```python query = f"SELECT * FROM users WHERE id = {user_id}" # Bad ``` Fix: Use parameterized query ```python query = "SELECT * FROM users WHERE id = %s" # Good cursor.execute(query, (user_id,)) ``` [HIGH] Mutable default argument File: app/services/auth.py:18 Issue: Mutable default argument causes shared state ```python def process_items(items=[]): # Bad items.append("new") return items ``` Fix: Use None as default ```python def process_items(items=None): # Good if items is None: items = [] items.append("new") return items ``` [MEDIUM] Missing type hints File: app/services/auth.py:25 Issue: Public function without type annotations ```python def get_user(user_id): # Bad return db.find(user_id) ``` Fix: Add type hints ```python def get_user(user_id: str) -> Optional[User]: # Good return db.find(user_id) ``` [MEDIUM] Not using context manager File: app/routes/user.py:55 Issue: File not closed on exception ```python f = open("config.json") # Bad data = f.read() f.close() ``` Fix: Use context manager ```python with open("config.json") as f: # Good data = f.read() ``` ## Summary - CRITICAL: 1 - HIGH: 1 - MEDIUM: 2 Recommendation: FAIL: Block merge until CRITICAL issue is fixed ## Formatting Required Run: `black app/routes/user.py app/services/auth.py` ``` ## Approval Criteria | Status | Condition | |--------|-----------| | PASS: Approve | No CRITICAL or HIGH issues | | WARNING: Warning | Only MEDIUM issues (merge with caution) | | FAIL: Block | CRITICAL or HIGH issues found | ## Integration with Other Commands - Use the `tdd-workflow` skill first to ensure tests pass - Use `/code-review` for non-Python specific concerns - Use `/python-review` before committing - Use `/build-fix` if static analysis tools fail ## Framework-Specific Reviews ### Django Projects The reviewer checks for: - N+1 query issues (use `select_related` and `prefetch_related`) - Missing migrations for model changes - Raw SQL usage when ORM could work - Missing `transaction.atomic()` for multi-step operations ### FastAPI Projects The reviewer checks for: - CORS misconfiguration - Pydantic models for request validation - Response models correctness - Proper async/await usage - Dependency injection patterns ### Flask Projects The reviewer checks for: - Context management (app context, request context) - Proper error handling - Blueprint organization - Configuration management ## Related - Agent: `agents/python-reviewer.md` - Skills: `skills/python-patterns/`, `skills/python-testing/` ## Common Fixes ### Add Type Hints ```python # Before def calculate(x, y): return x + y # After from typing import Union def calculate(x: Union[int, float], y: Union[int, float]) -> Union[int, float]: return x + y ``` ### Use Context Managers ```python # Before f = open("file.txt") data = f.read() f.close() # After with open("file.txt") as f: data = f.read() ``` ### Use List Comprehensions ```python # Before result = [] for item in items: if item.active: result.append(item.name) # After result = [item.name for item in items if item.active] ``` ### Fix Mutable Defaults ```python # Before def append(value, items=[]): items.append(value) return items # After def append(value, items=None): if items is None: items = [] items.append(value) return items ``` ### Use f-strings (Python 3.6+) ```python # Before name = "Alice" greeting = "Hello, " + name + "!" greeting2 = "Hello, {}".format(name) # After greeting = f"Hello, {name}!" ``` ### Fix String Concatenation in Loops ```python # Before result = "" for item in items: result += str(item) # After result = "".join(str(item) for item in items) ``` ## Python Version Compatibility The reviewer notes when code uses features from newer Python versions: | Feature | Minimum Python | |---------|----------------| | Type hints | 3.5+ | | f-strings | 3.6+ | | Walrus operator (`:=`) | 3.8+ | | Position-only parameters | 3.8+ | | Match statements | 3.10+ | | Type unions (`x | None`) | 3.10+ | Ensure your project's `pyproject.toml` or `setup.py` specifies the correct minimum Python version.

package/packs/full-harness/rendered/.claude/commands/quality-gate.md

@@ -0,0 +1,6 @@
+---
+description: Run the ECC formatter quality gate for a single file and report remediation steps.
+argument-hint: [optional arguments]
+---
+
+# Quality Gate Command Operator entry point for the formatter quality gate that normally runs as the `post:quality-gate` PostToolUse hook (`scripts/hooks/quality-gate.js`). ## How it actually works The gate is a single-file formatter check driven by hook input, not CLI flags: - The script reads the target from the hook's stdin JSON (`tool_input.file_path`); it does not take a path argument. - Behavior toggles are environment variables: - `ECC_QUALITY_GATE_FIX=true` - apply formatting fixes instead of check-only - `ECC_QUALITY_GATE_STRICT=true` - log formatter failures as gate failures - Coverage by file type: - `.ts/.tsx/.js/.jsx/.json/.md` - Biome `check` or Prettier `--check`, whichever the project ships (JS/TS under Biome is skipped here because `post-edit-format` already runs `biome check --write`) - `.go` - `gofmt` - `.py` - `ruff format` - Lint and type checks are not part of this gate. Use the `verification-loop` skill or the language verification skills for lint/type/test pipelines. ## Usage To run the gate manually against one file, pipe hook-style JSON into the script (set the env toggles first if you want fix or strict behavior): ```bash echo '{"tool_input":{"file_path":"src/example.ts"}}' \ | ECC_QUALITY_GATE_FIX=true node scripts/hooks/quality-gate.js ``` Then report formatter findings and concrete remediation steps. ## Notes Hook wiring lives in `hooks/hooks.json` (`post:quality-gate`, profiles `standard`/`strict` via `run-with-flags.js`). ## Arguments $ARGUMENTS: - `[path]` optional file to check. The script itself takes no CLI arguments - when a path is given, substitute it as `tool_input.file_path` in the stdin JSON shown above before running the command

package/packs/full-harness/rendered/.claude/commands/react-build.md

@@ -0,0 +1,6 @@
+---
+description: Fix React build failures (Vite, webpack, Next.js, CRA, Parcel, esbuild, Bun) incrementally — JSX/TSX compile errors, hydration mismatches, server/client component boundary failures, missing types. Invokes the react-build-resolver agent for minimal, surgical fixes.
+argument-hint: [optional arguments]
+---
+
+# React Build and Fix This command invokes the **react-build-resolver** agent to incrementally fix React build errors with minimal changes. ## What This Command Does 1. **Detect Build System**: Identify Vite, webpack, Next.js, CRA, Parcel, esbuild, or Bun 2. **Run Build**: Execute the project's build script 3. **Parse Errors**: Group by layer (TypeScript / bundler config / runtime / hydration) 4. **Fix Incrementally**: One error at a time, re-running build after each change 5. **Report Summary**: Show what was fixed and what remains ## When to Use Use `/react-build` when: - `npm run build` (or pnpm/yarn/bun equivalent) fails - JSX/TSX compile errors after a TypeScript or React upgrade - Next.js hydration mismatch errors at runtime - Server/Client Component boundary errors in App Router - After installing or upgrading `react`, `react-dom`, `@types/react`, or a bundler - Missing types or "module not found" errors involving React ## Scope This command owns **React build/bundler/runtime hydration** failures. For pure TypeScript type errors with no React involvement, use `/build-fix` (generic) instead. ## Diagnostic Commands Run ```bash # Project build script (preferred) npm run build --if-present pnpm build 2>/dev/null yarn build 2>/dev/null bun run build 2>/dev/null # Standalone typecheck npm run typecheck --if-present tsc --noEmit -p tsconfig.json # Bundler-specific fallback next build # Next.js vite build # Vite react-scripts build # CRA webpack --mode=production # webpack parcel build src/index.html # Parcel bun build ./src/index.tsx --outdir=dist ``` ## Example Session ````text User: /react-build Agent: # React Build Resolution ## Build System Detected Vite (vite.config.ts present, @vitejs/plugin-react in deps) ## Initial Diagnostics ```bash $ npm run build > tsc -b && vite build src/components/UserCard.tsx:1:8 - error TS6133: 'React' is declared but its value is never read. src/components/Modal.tsx:12:15 - error TS7016: Could not find a declaration file for module 'react-portal'. src/pages/Home.tsx:42:5 - error: 'useState' is not defined ``` Errors found: 3 ## Fix 1: Old JSX transform leftover File: src/components/UserCard.tsx:1 Cause: `tsconfig.json` already uses `"jsx": "react-jsx"`; the explicit `import React` is unused. ```tsx // Removed - import React from 'react'; ``` ```bash $ npm run build # 2 errors remaining ``` ## Fix 2: Missing types File: src/components/Modal.tsx Cause: `@types/react-portal` not installed. ```bash $ npm i -D @types/react-portal added 1 package ``` ```bash $ npm run build # 1 error remaining ``` ## Fix 3: Missing hook import File: src/pages/Home.tsx Cause: `useState` referenced but not imported. ```tsx - import { useEffect } from "react"; + import { useEffect, useState } from "react"; ``` ```bash $ npm run build # Build successful! ``` ## Final Verification ```bash $ npm run build ✓ built in 2.34s $ npm test ✓ 47 tests passed ``` ## Summary | Metric | Count | |--------|-------| | Build errors fixed | 3 | | Files modified | 2 | | Dependencies added | 1 (@types/react-portal) | | Remaining issues | 0 | Build Status: PASS: SUCCESS ```` ## Common Errors Fixed | Error | Typical Fix | |---|---| | `'React' is not defined` | Set `"jsx": "react-jsx"` in tsconfig (React 17+) | | Missing `@types/react` | `npm i -D @types/react @types/react-dom` | | `Unexpected token '<'` | Add `@vitejs/plugin-react` / `babel-loader` | | `You're importing a component that needs useState` (Next.js) | Add `"use client"` or move hook to a Client Component child | | `Module not found: Can't resolve 'fs'` (Next.js) | Remove `fs` import or move logic into Server Component / API route | | `Hydration failed because the initial UI does not match` | Move `Date.now()`/`Math.random()`/`window.*` to `useEffect` | | `Invalid hook call` | Multiple React copies — dedupe via `resolutions`/`overrides` | | `Element type is invalid` | Default vs named import mismatch | ## Fix Strategy 1. **Compile errors first** — code must build 2. **Hydration errors second** — affects production correctness 3. **Bundler config third** — restore plugin/loader correctness 4. **One fix at a time** — verify each change 5. **Minimal changes** — never `// @ts-ignore` without explanation 6. **Re-run after each fix** — surface new errors immediately ## Stop Conditions The agent will stop and report if: - Same error persists after 3 attempts - Fix introduces more errors than it resolves - Requires architectural change beyond build resolution (e.g., redesigning the RSC boundary) - Bundler version no longer supports the installed React major ## Related Commands - `/react-test` — run tests after the build is green - `/react-review` — review code quality after the build succeeds - `/build-fix` — generic build fixer (non-React) - `verification-loop` skill — full verification loop ## Related - Agent: `agents/react-build-resolver.md` - Skills: `skills/react-patterns/`, `skills/frontend-patterns/` - Rules: `rules/react/coding-style.md`, `rules/react/patterns.md`

package/packs/full-harness/rendered/.claude/commands/react-review.md

@@ -0,0 +1,6 @@
+---
+description: Comprehensive React/JSX code review for hook correctness, render performance, server/client component boundaries, accessibility, and React-specific security. Invokes the react-reviewer agent (and typescript-reviewer alongside on TSX/JSX changes).
+argument-hint: [optional arguments]
+---
+
+# React Code Review This command invokes the **react-reviewer** agent for React-specific code review. For pull requests touching `.tsx`/`.jsx` files, both `react-reviewer` and `typescript-reviewer` should run — each owns a distinct lane. ## What This Command Does 1. **Identify React Changes**: Find modified `.tsx`/`.jsx` files (and React-containing `.ts`/`.js` files) via `git diff` 2. **Run Lint**: Execute `eslint` with `eslint-plugin-react-hooks` and `eslint-plugin-jsx-a11y` 3. **Typecheck**: Run `tsc --noEmit` or the project's canonical typecheck command 4. **Review React Lanes Only**: Hook rules, RSC boundaries, accessibility, render performance, React-specific security 5. **Generate Report**: Categorize issues by severity (CRITICAL / HIGH / MEDIUM) ## When to Use Use `/react-review` when: - A PR or commit touches `.tsx`/`.jsx` files - After writing or modifying React components, custom hooks, or pages - Before merging React code - Auditing accessibility on UI components - Reviewing a new hook for rules-of-hooks and dependency correctness - Auditing a Next.js App Router server/client component boundary For pure `.ts`/`.js` changes with no React imports, use `/code-review` (general) or invoke `typescript-reviewer` directly. ## Scope vs `/code-review` and TypeScript Review | Tool | Scope | |---|---| | `react-reviewer` (this command) | Hooks rules, JSX, RSC, a11y, React-specific security, render perf | | `typescript-reviewer` | Generic TS/JS — `any` abuse, async correctness, Node security | | `security-reviewer` | Project-wide security audit | | `/code-review` | Generic uncommitted-changes or PR review | On a TSX/JSX PR, invoke both `react-reviewer` and `typescript-reviewer`. Findings from each are non-overlapping by design. ## Review Categories ### CRITICAL (Must Fix) - `dangerouslySetInnerHTML` with unsanitized input - `href`/`src` with unvalidated user URLs (`javascript:`, `data:`) - Server Action without input validation - Secret in client bundle (`NEXT_PUBLIC_*`, `VITE_*`, `REACT_APP_*`) - `localStorage`/`sessionStorage` for session tokens - Conditional hook calls (violates Rules of Hooks) - Direct state mutation - Hook called outside a component or custom hook ### HIGH (Should Fix) - Missing `useEffect`/`useMemo`/`useCallback` deps (disabled `exhaustive-deps` without justification) - Effect for derived state - Effect missing cleanup - Stale closures in handlers/intervals - Server-only imports in Client Components - Sensitive data leaked via props to Client Components - Server Actions without auth checks - Accessibility violations (missing labels, non-semantic interactive elements, ARIA misuse) - `key={index}` in dynamic lists - Duplicated state, useEffect chains ### MEDIUM (Consider) - Over-memoization without measured win - Inline new object/function as prop to memoized child - Suspense at route root only (no progressive reveal) - Long lists without virtualization - High-frequency value via `useContext` - Roll-your-own validation in non-trivial forms - Prop drilling beyond 3 levels - Component over 200 lines - Class components in new code ## Automated Checks Run ```bash # Lint (required for any meaningful review) npx eslint . --ext .tsx,.jsx,.ts,.js # Typecheck (skip cleanly for JS-only projects) npm run typecheck --if-present [ -f tsconfig.json ] && tsc --noEmit -p tsconfig.json # Targeted a11y rules npx eslint . --rule 'jsx-a11y/alt-text: error' \ --rule 'jsx-a11y/anchor-is-valid: error' \ --rule 'jsx-a11y/click-events-have-key-events: error' # Supply-chain npm audit ``` If `eslint-plugin-react-hooks` or `eslint-plugin-jsx-a11y` is not configured, the review will flag the gap as a HIGH config issue and continue. ## Example Usage ````text User: /react-review Agent: # React Code Review Report ## Files Reviewed - src/components/UserCard.tsx (modified) - src/hooks/useUser.ts (new) ## Lint Results PASS: eslint clean PASS: typecheck clean ## Issues Found [CRITICAL] Unsanitized dangerouslySetInnerHTML File: src/components/UserCard.tsx:42 Issue: User-controlled bio rendered as raw HTML. Why: XSS via stored script tags in user input. Fix: Sanitize with DOMPurify or render as text: ```tsx import DOMPurify from "isomorphic-dompurify"; <div dangerouslySetInnerHTML={{ __html: DOMPurify.sanitize(user.bio) }} /> ``` [HIGH] Effect cleanup missing File: src/hooks/useUser.ts:18 Issue: `fetch` call without AbortController; setState on unmounted component possible. Fix: Add AbortController and cleanup: ```ts useEffect(() => { const ac = new AbortController(); fetch(`/api/users/${id}`, { signal: ac.signal }) .then(r => r.json()) .then(setUser); return () => ac.abort(); }, [id]); ``` ## Summary - CRITICAL: 1 - HIGH: 1 - MEDIUM: 0 Recommendation: FAIL: Block merge until CRITICAL issue is fixed ```` ## Approval Criteria | Status | Condition | |---|---| | PASS: Approve | No CRITICAL or HIGH issues | | WARNING: Warning | Only MEDIUM issues (merge with caution) | | FAIL: Block | CRITICAL or HIGH issues found | ## Integration with Other Commands - Run `/react-build` first if the build is broken - Run `/react-test` to ensure component tests pass - Run `/react-review` before merging - Use `/code-review` for non-React-specific concerns on the same PR ## Related - Agent: `agents/react-reviewer.md` - Companion agent: `agents/typescript-reviewer.md` (run alongside for TSX/JSX PRs) - Skills: `skills/react-patterns/`, `skills/react-testing/`, `skills/accessibility/` - Rules: `rules/react/`

package/packs/full-harness/rendered/.claude/commands/react-test.md

@@ -0,0 +1,6 @@
+---
+description: Enforce TDD workflow for React. Write React Testing Library tests first (behavior-focused, accessibility-first), then implement components. Detects Vitest or Jest and verifies coverage targets.
+argument-hint: [optional arguments]
+---
+
+# React TDD Command This command enforces test-driven development for React using React Testing Library plus Vitest or Jest, detected at runtime. ## What This Command Does 1. **Define Component Signature**: Scaffold the component, prop type, and exports 2. **Write Behavior Tests First**: RTL queries (role-first), `userEvent`, MSW for network — RED 3. **Run Tests**: Verify they fail for the right reason 4. **Implement Minimal Code**: Just enough to pass — GREEN 5. **Refactor**: Improve while keeping tests green 6. **Check Coverage**: Hit the targets in [rules/react/testing.md](../rules/react/testing.md) ## When to Use Use `/react-test` when: - Implementing a new React component or custom hook - Adding test coverage to an untested component - Fixing a bug (write failing test first that reproduces it) - Building forms, state machines, or accessibility-critical UI - Onboarding to RTL + Vitest/Jest workflow ## TDD Cycle ``` RED -> Write failing test for the next behavior GREEN -> Implement minimal component code to pass REFACTOR -> Improve component, tests stay green REPEAT -> Next behavior ``` ## Runner Detection ```bash test -f vitest.config.ts -o -f vitest.config.js -o -f vite.config.ts # Vitest grep -l '"jest"' package.json # Jest ``` Prefer Vitest for new Vite-based projects; respect Jest for existing setups. ## Example Session ````text User: /react-test I need a SearchInput component with debounced search Agent: # TDD Session: SearchInput ## Step 1: Define Signature ```tsx // src/components/SearchInput.tsx type Props = { onSearch: (query: string) => void; placeholder?: string; debounceMs?: number; }; export function SearchInput({ onSearch, placeholder, debounceMs }: Props) { throw new Error("not implemented"); } ``` ## Step 2: Write Behavior Tests (RED) ```tsx // src/components/SearchInput.test.tsx import { describe, expect, test, vi } from "vitest"; import { render, screen } from "@testing-library/react"; import userEvent from "@testing-library/user-event"; import { SearchInput } from "./SearchInput"; describe("SearchInput", () => { test("renders with placeholder", () => { render(<SearchInput onSearch={() => {}} placeholder="Search users" />); expect(screen.getByPlaceholderText("Search users")).toBeInTheDocument(); }); test("calls onSearch after typing", async () => { vi.useFakeTimers(); const user = userEvent.setup({ advanceTimers: vi.advanceTimersByTime }); const onSearch = vi.fn(); render(<SearchInput onSearch={onSearch} debounceMs={300} />); await user.type(screen.getByRole("textbox"), "alice"); expect(onSearch).not.toHaveBeenCalled(); // before debounce vi.advanceTimersByTime(300); expect(onSearch).toHaveBeenCalledWith("alice"); // after debounce vi.useRealTimers(); }); test("does not call onSearch when typing pauses then continues", async () => { vi.useFakeTimers(); const user = userEvent.setup({ advanceTimers: vi.advanceTimersByTime }); const onSearch = vi.fn(); render(<SearchInput onSearch={onSearch} debounceMs={300} />); await user.type(screen.getByRole("textbox"), "ali"); vi.advanceTimersByTime(200); // mid-debounce await user.type(screen.getByRole("textbox"), "ce"); vi.advanceTimersByTime(300); expect(onSearch).toHaveBeenCalledTimes(1); expect(onSearch).toHaveBeenCalledWith("alice"); vi.useRealTimers(); }); test("is keyboard reachable and accessible", () => { render(<SearchInput onSearch={() => {}} />); const input = screen.getByRole("textbox"); input.focus(); expect(input).toHaveFocus(); }); }); ``` ## Step 3: Run Tests — Verify FAIL ```bash $ vitest run src/components/SearchInput.test.tsx × src/components/SearchInput.test.tsx (4 tests) ✘ Error: not implemented ``` ✓ Tests fail as expected. ## Step 4: Implement Minimal Code (GREEN) ```tsx import { useEffect, useState } from "react"; export function SearchInput({ onSearch, placeholder, debounceMs = 300 }: Props) { const [query, setQuery] = useState(""); useEffect(() => { const id = setTimeout(() => onSearch(query), debounceMs); return () => clearTimeout(id); }, [query, onSearch, debounceMs]); return ( <input type="text" value={query} placeholder={placeholder} onChange={(e) => setQuery(e.target.value)} /> ); } ``` ## Step 5: Run Tests — Verify PASS ```bash $ vitest run src/components/SearchInput.test.tsx ✓ src/components/SearchInput.test.tsx (4 tests) 47ms ``` ## Step 6: Coverage ```bash $ vitest run --coverage src/components/SearchInput.test.tsx % Stmts: 100 % Branch: 100 % Funcs: 100 % Lines: 100 ``` ## TDD Complete! ```` ## Test Patterns ### Behavior, not implementation Use `getByRole`, `getByLabelText`, `getByText`. Avoid `container.querySelector` and asserting on component state. ### `userEvent.setup()` per test ```tsx const user = userEvent.setup(); await user.click(screen.getByRole("button", { name: /save/i })); ``` ### MSW for network ```tsx beforeAll(() => server.listen({ onUnhandledRequest: "error" })); afterEach(() => server.resetHandlers()); afterAll(() => server.close()); server.use(http.post("/api/users", () => HttpResponse.json({ id: "1" }, { status: 201 }))); ``` ### Custom hooks ```tsx const { result } = renderHook(() => useCounter(0)); act(() => result.current.increment()); expect(result.current.count).toBe(1); ``` ### Accessibility ```tsx import { axe } from "vitest-axe"; expect(await axe(container)).toHaveNoViolations(); ``` ## Coverage Targets | Layer | Target | |---|---| | Pure utilities | >=90% | | Custom hooks | >=85% | | Presentational components | >=80% | | Container components | >=70% | | Pages | E2E covered separately | Configure in `vitest.config.ts` / `jest.config.js` to enforce thresholds in CI. ## Anti-Patterns to Avoid - `container.querySelector(...)` — bypasses accessibility queries - Asserting on render count - Mocking `react` itself (`jest.mock("react", ...)`) - Mocking child components by default (mock only when child has heavy side effects) - Ignoring `act()` warnings — they signal real bugs - Snapshot tests of rendered components (brittle, rubber-stamped) — use Playwright/Cypress visual diff instead ## Test Commands ```bash # Vitest vitest # watch vitest run # one-shot vitest run --coverage # with coverage vitest run path/to/file.test.tsx # single file # Jest jest --watch jest --coverage jest path/to/file.test.tsx # CI mode CI=true vitest run --coverage ``` ## Related Commands - `/react-build` — fix build errors before running tests - `/react-review` — review after implementation - `verification-loop` skill — full verification loop ## Related - Skills: `skills/react-testing/`, `skills/tdd-workflow/`, `skills/accessibility/`, `skills/e2e-testing/` - Rules: `rules/react/testing.md` - Agents: `react-reviewer` (reviews test quality), `tdd-guide` (enforces TDD process)

package/packs/full-harness/rendered/.claude/commands/refactor-clean.md

@@ -0,0 +1,6 @@
+---
+description: Safely identify and remove dead code with verification after each change.
+argument-hint: [optional arguments]
+---
+
+# Refactor Clean Safely identify and remove dead code with test verification at every step. ## Step 1: Detect Dead Code Run analysis tools based on project type: | Tool | What It Finds | Command | |------|--------------|---------| | knip | Unused exports, files, dependencies | `npx knip` | | depcheck | Unused npm dependencies | `npx depcheck` | | ts-prune | Unused TypeScript exports | `npx ts-prune` | | vulture | Unused Python code | `vulture src/` | | deadcode | Unused Go code | `deadcode ./...` | | cargo-udeps | Unused Rust dependencies | `cargo +nightly udeps` | If no tool is available, use Grep to find exports with zero imports: ``` # Find exports, then check if they're imported anywhere ``` ## Step 2: Categorize Findings Sort findings into safety tiers: | Tier | Examples | Action | |------|----------|--------| | **SAFE** | Unused utilities, test helpers, internal functions | Delete with confidence | | **CAUTION** | Components, API routes, middleware | Verify no dynamic imports or external consumers | | **DANGER** | Config files, entry points, type definitions | Investigate before touching | ## Step 3: Safe Deletion Loop For each SAFE item: 1. **Run full test suite** — Establish baseline (all green) 2. **Delete the dead code** — Use Edit tool for surgical removal 3. **Re-run test suite** — Verify nothing broke 4. **If tests fail** — Immediately revert with `git checkout -- <file>` and skip this item 5. **If tests pass** — Move to next item ## Step 4: Handle CAUTION Items Before deleting CAUTION items: - Search for dynamic imports: `import()`, `require()`, `__import__` - Search for string references: route names, component names in configs - Check if exported from a public package API - Verify no external consumers (check dependents if published) ## Step 5: Consolidate Duplicates After removing dead code, look for: - Near-duplicate functions (>80% similar) — merge into one - Redundant type definitions — consolidate - Wrapper functions that add no value — inline them - Re-exports that serve no purpose — remove indirection ## Step 6: Summary Report results: ``` Dead Code Cleanup ────────────────────────────── Deleted: 12 unused functions 3 unused files 5 unused dependencies Skipped: 2 items (tests failed) Saved: ~450 lines removed ────────────────────────────── All tests passing PASS: ``` ## Rules - **Never delete without running tests first** - **One deletion at a time** — Atomic changes make rollback easy - **Skip if uncertain** — Better to keep dead code than break production - **Don't refactor while cleaning** — Separate concerns (clean first, refactor later)

package/packs/full-harness/rendered/.claude/commands/resume-session.md

@@ -0,0 +1,6 @@
+---
+description: Load the most recent session file from ~/.claude/session-data/ and resume work with full context from where the last session ended.
+argument-hint: [optional arguments]
+---
+
+# Resume Session Command Load the last saved session state and orient fully before doing any work. This command is the counterpart to `/save-session`. ## When to Use - Starting a new session to continue work from a previous day - After starting a fresh session due to context limits - When handing off a session file from another source (just provide the file path) - Any time you have a session file and want Claude to fully absorb it before proceeding ## Usage ``` /resume-session # loads most recent file in ~/.claude/session-data/ /resume-session 2024-01-15 # loads most recent session for that date /resume-session ~/.claude/session-data/2024-01-15-abc123de-session.tmp # loads a current short-id session file /resume-session ~/.claude/sessions/2024-01-15-session.tmp # loads a specific legacy-format file ``` ## Process ### Step 1: Find the session file If no argument provided: 1. Check `~/.claude/session-data/` 2. Pick the most recently modified `*-session.tmp` file 3. If the folder does not exist or has no matching files, tell the user: ``` No session files found in ~/.claude/session-data/ Run /save-session at the end of a session to create one. ``` Then stop. If an argument is provided: - If it looks like a date (`YYYY-MM-DD`), search `~/.claude/session-data/` first, then the legacy `~/.claude/sessions/`, for files matching `YYYY-MM-DD-session.tmp` (legacy format) or `YYYY-MM-DD-<shortid>-session.tmp` (current format) and load the most recently modified variant for that date - If it looks like a file path, read that file directly - If not found, report clearly and stop ### Step 2: Read the entire session file Read the complete file. Do not summarize yet. ### Step 3: Confirm understanding Respond with a structured briefing in this exact format: ``` SESSION LOADED: [actual resolved path to the file] ════════════════════════════════════════════════ PROJECT: [project name / topic from file] WHAT WE'RE BUILDING: [2-3 sentence summary in your own words] CURRENT STATE: PASS: Working: [count] items confirmed In Progress: [list files that are in progress] Not Started: [list planned but untouched] WHAT NOT TO RETRY: [list every failed approach with its reason — this is critical] OPEN QUESTIONS / BLOCKERS: [list any blockers or unanswered questions] NEXT STEP: [exact next step if defined in the file] [if not defined: "No next step defined — recommend reviewing 'What Has NOT Been Tried Yet' together before starting"] ════════════════════════════════════════════════ Ready to continue. What would you like to do? ``` ### Step 4: Wait for the user Do NOT start working automatically. Do NOT touch any files. Wait for the user to say what to do next. If the next step is clearly defined in the session file and the user says "continue" or "yes" or similar — proceed with that exact next step. If no next step is defined — ask the user where to start, and optionally suggest an approach from the "What Has NOT Been Tried Yet" section. --- ## Edge Cases **Multiple sessions for the same date** (`2024-01-15-session.tmp`, `2024-01-15-abc123de-session.tmp`): Load the most recently modified matching file for that date, regardless of whether it uses the legacy no-id format or the current short-id format. **Session file references files that no longer exist:** Note this during the briefing — "WARNING: `path/to/file.ts` referenced in session but not found on disk." **Session file is from more than 7 days ago:** Note the gap — "WARNING: This session is from N days ago (threshold: 7 days). Things may have changed." — then proceed normally. **User provides a file path directly (e.g., forwarded from a teammate):** Read it and follow the same briefing process — the format is the same regardless of source. **Session file is empty or malformed:** Report: "Session file found but appears empty or unreadable. You may need to create a new one with /save-session." --- ## Example Output ``` SESSION LOADED: /Users/you/.claude/session-data/2024-01-15-abc123de-session.tmp ════════════════════════════════════════════════ PROJECT: my-app — JWT Authentication WHAT WE'RE BUILDING: User authentication with JWT tokens stored in httpOnly cookies. Register and login endpoints are partially done. Route protection via middleware hasn't been started yet. CURRENT STATE: PASS: Working: 3 items (register endpoint, JWT generation, password hashing) In Progress: app/api/auth/login/route.ts (token works, cookie not set yet) Not Started: middleware.ts, app/login/page.tsx WHAT NOT TO RETRY: FAIL: Next-Auth — conflicts with custom Prisma adapter, threw adapter error on every request FAIL: localStorage for JWT — causes SSR hydration mismatch, incompatible with Next.js OPEN QUESTIONS / BLOCKERS: - Does cookies().set() work inside a Route Handler or only Server Actions? NEXT STEP: In app/api/auth/login/route.ts — set the JWT as an httpOnly cookie using cookies().set('token', jwt, { httpOnly: true, secure: true, sameSite: 'strict' }) then test with Postman for a Set-Cookie header in the response. ════════════════════════════════════════════════ Ready to continue. What would you like to do? ``` --- ## Notes - Never modify the session file when loading it — it's a read-only historical record - The briefing format is fixed — do not skip sections even if they are empty - "What Not To Retry" must always be shown, even if it just says "None" — it's too important to miss - After resuming, the user may want to run `/save-session` again at the end of the new session to create a new dated file

package/packs/full-harness/rendered/.claude/commands/review-pr.md

@@ -0,0 +1,6 @@
+---
+description: Comprehensive PR review using specialized agents
+argument-hint: [optional arguments]
+---
+
+Run a comprehensive multi-perspective review of a pull request. ## Usage `/review-pr [PR-number-or-URL] [--focus=comments|tests|errors|types|code|simplify]` If no PR is specified, review the current branch's PR. If no focus is specified, run the full review stack. ## Steps 1. Identify the PR: - use `gh pr view` to get PR details, changed files, and diff 2. Find project guidance: - look for `CLAUDE.md`, lint config, TypeScript config, repo conventions 3. Run specialized review agents: - `code-reviewer` - `comment-analyzer` - `pr-test-analyzer` - `silent-failure-hunter` - `type-design-analyzer` - `code-simplifier` 4. Aggregate results: - dedupe overlapping findings - rank by severity 5. Report findings grouped by severity ## Confidence Rule Only report issues with confidence >= 80: - Critical: bugs, security, data loss - Important: missing tests, quality problems, style violations - Advisory: suggestions only when explicitly requested

package/packs/full-harness/rendered/.claude/commands/rust-build.md

@@ -0,0 +1,6 @@
+---
+description: Fix Rust build errors, borrow checker issues, and dependency problems incrementally. Invokes the rust-build-resolver agent for minimal, surgical fixes.
+argument-hint: [optional arguments]
+---
+
+# Rust Build and Fix This command invokes the **rust-build-resolver** agent to incrementally fix Rust build errors with minimal changes. ## What This Command Does 1. **Run Diagnostics**: Execute `cargo check`, `cargo clippy`, `cargo fmt --check` 2. **Parse Errors**: Identify error codes and affected files 3. **Fix Incrementally**: One error at a time 4. **Verify Each Fix**: Re-run `cargo check` after each change 5. **Report Summary**: Show what was fixed and what remains ## When to Use Use `/rust-build` when: - `cargo build` or `cargo check` fails with errors - `cargo clippy` reports warnings - Borrow checker or lifetime errors block compilation - Cargo dependency resolution fails - After pulling changes that break the build ## Diagnostic Commands Run ```bash # Primary build check cargo check 2>&1 # Lints and suggestions cargo clippy -- -D warnings 2>&1 # Formatting check cargo fmt --check 2>&1 # Dependency issues cargo tree --duplicates # Security audit (if available) if command -v cargo-audit >/dev/null; then cargo audit; else echo "cargo-audit not installed"; fi ``` ## Example Session ````text User: /rust-build Agent: # Rust Build Resolution ## Initial Diagnostics ```bash $ cargo check error[E0502]: cannot borrow `map` as mutable because it is also borrowed as immutable --> src/service/cache.rs:25:5 error[E0308]: mismatched types --> src/handler/api.rs:42:12 error[E0425]: cannot find value `db` in this scope --> src/handler/api.rs:58:9 ``` Errors found: 3 ## Fix 1: Borrow Checker Error File: src/service/cache.rs:25 Error: E0502 — cannot borrow `map` as mutable because also borrowed as immutable Cause: Immutable borrow still active during mutable insert ```rust // Changed: restructured to end immutable borrow before mutable access if !map.contains_key("key") { map.insert("key".into(), default); } ``` ```bash $ cargo check # 2 errors remaining ``` ## Fix 2: Type Mismatch File: src/handler/api.rs:42 Error: E0308 — mismatched types: expected `usize`, found `&str` ```rust // Changed let count = params.get("count"); // To let count: usize = params.get("count") .and_then(|s| s.parse().ok()) .unwrap_or(0); ``` ```bash $ cargo check # 1 error remaining ``` ## Fix 3: Unresolved Name File: src/handler/api.rs:58 Error: E0425 — cannot find value `db` in this scope Cause: Missing import ```rust // Added use crate::db; ``` ```bash $ cargo check # Build successful! ``` ## Final Verification ```bash $ cargo clippy -- -D warnings # No warnings $ cargo test running 6 tests test service::cache::tests::test_insert ... ok test service::cache::tests::test_get ... ok test handler::api::tests::test_parse_count ... ok test handler::api::tests::test_missing_count ... ok test handler::api::tests::test_db_import ... ok test handler::api::tests::test_response ... ok test result: ok. 6 passed; 0 failed; 0 ignored ``` ## Summary | Metric | Count | |--------|-------| | Build errors fixed | 3 | | Clippy warnings fixed | 0 | | Files modified | 2 | | Remaining issues | 0 | Build Status: SUCCESS ```` ## Common Errors Fixed | Error | Typical Fix | |-------|-------------| | `cannot borrow as mutable` | Restructure to end immutable borrow first; clone only if justified | | `does not live long enough` | Use owned type or add lifetime annotation | | `cannot move out of` | Restructure to take ownership; clone only as last resort | | `mismatched types` | Add `.into()`, `as`, or explicit conversion | | `trait X not implemented` | Add `#[derive(Trait)]` or implement manually | | `unresolved import` | Add to Cargo.toml or fix `use` path | | `cannot find value` | Add import or fix path | ## Fix Strategy 1. **Build errors first** - Code must compile 2. **Clippy warnings second** - Fix suspicious constructs 3. **Formatting third** - `cargo fmt` compliance 4. **One fix at a time** - Verify each change 5. **Minimal changes** - Don't refactor, just fix ## Stop Conditions The agent will stop and report if: - Same error persists after 3 attempts - Fix introduces more errors - Requires architectural changes - Borrow checker error requires redesigning data ownership ## Related Commands - `/rust-test` - Run tests after build succeeds - `/rust-review` - Review code quality - `verification-loop` skill - Full verification loop ## Related - Agent: `agents/rust-build-resolver.md` - Skill: `skills/rust-patterns/`