prizmkit 1.1.106 → 1.1.108

package/bundled/skills/feature-workflow/SKILL.md

@@ -1,75 +1,88 @@
 ---
 name: "feature-workflow"
-description: "One-stop entry point for feature development. Brainstorms requirements with the user until fully clarified, then orchestrates feature-planner → feature-pipeline-launcher → execution. Handles multi-feature batch development from a single request. Use this skill whenever the user wants to build an app, develop multiple features at once, or go from idea to running code in one step. Trigger on: 'build an app', 'develop features', 'implement all features', 'one-stop development', 'batch implement', 'build a new application', 'build a system', 'one-click complete', 'batch implement'."
+description: "Triage-based feature workflow. Clarifies requirements, then lets the user choose Fast Path for simple current-session/current-workspace implementation or Pipeline Path for complex/batch features via feature-planner → feature-pipeline-launcher. Use when the user wants to develop features from idea to running code with the right execution path for the task difficulty. Trigger on: 'build an app', 'develop features', 'implement all features', 'one-stop development', 'batch implement', 'build a new application', 'build a system', 'one-click complete'."
 ---
 
 # Feature Workflow
 
-One-stop entry point for feature development. Covers the complete journey from a vague idea to running code: deep requirement brainstorming → structured planning → autonomous pipeline execution.
+Triage-based entry point for feature development. The workflow clarifies requirements, assesses task difficulty, asks the user to choose an approach, then follows one of two paths:
+
+- **Fast Path** — simple feature work is implemented directly in the **current session** and **current workspace** with the normal PrizmKit lifecycle commands.
+- **Pipeline Path** — complex or batch features are planned with `feature-planner`, launched with `feature-pipeline-launcher`, then monitored.
+
+This skill keeps Fast Path and Pipeline Path separate. Pipeline monitoring only happens after the user selects Pipeline Path and the launcher starts execution.
 
 ## When to Use
 
 User says:
 - "Build a new application", "Build XXX system", "Create a project"
+- "Implement this feature now", "Add this simple feature", "Build one small workflow"
 - "One-click complete these features", "Batch implement these requirements"
-- "Build a task management App from scratch"
 - "Help me implement user login, registration, and avatar upload features"
-- After receiving a batch of related feature requests
+- After receiving either one scoped feature request or a batch of related feature requests
 
 **Do NOT use this skill when:**
-- User only wants to plan features (use `feature-planner` directly)
-- User only wants to launch pipeline for existing .prizmkit/plans/feature-list.json (use `feature-pipeline-launcher`)
-- User wants to fix bugs (use `bug-planner` + `bugfix-pipeline-launcher`)
-- User wants to refactor code (use `refactor-workflow`)
+- User only wants to plan features without execution → use `feature-planner` directly
+- User only wants to launch an existing `.prizmkit/plans/feature-list.json` → use `feature-pipeline-launcher`
+- User wants to fix bugs → use `bug-fix-workflow` or `bug-planner` + `bugfix-pipeline-launcher`
+- User wants to refactor code → use `refactor-workflow`
 
 ---
 
 ## Overview
 
-Given an idea or requirements, the workflow runs four phases:
+The shared contract is:
+
+1. **Brainstorm** — collect reference materials, deep read relevant code/docs, and clarify requirements.
+2. **Assess difficulty** — decide whether the request is simple enough for Fast Path or should use Pipeline Path.
+3. **AskUserQuestion approach selection** — present selectable options; never silently choose the path.
+4. **Execute selected path**:
+   - **Fast Path**: `/prizmkit-plan` → `/prizmkit-implement` → `/prizmkit-code-review` → `/prizmkit-retrospective` → `/prizmkit-committer` in the current workspace.
+   - **Pipeline Path**: `feature-planner` → `feature-pipeline-launcher` → monitoring.
 
-1. **Brainstorm** — collect reference materials, parallel deep read code & docs, discuss requirements grounded in real context → fully clarified requirements
-2. **Plan** — call `feature-planner` with clarified requirements → `.prizmkit/plans/feature-list.json` with N features
-3. **Launch** — call `feature-pipeline-launcher` → pipeline started (execution mode chosen by user via launcher)
-4. **Monitor** — track progress → status updates, completion report
+### Terminology
 
-The value: the user starts from a rough idea, the skill brainstorms to fill the gaps, and planning + execution happen automatically — no need to manually invoke each planner/launcher and poll for progress.
+| Term | Meaning |
+|------|---------|
+| **Fast Path** | Current-session/current-workspace feature implementation for simple, scoped work. It does not create or consume `.prizmkit/plans/feature-list.json` and does not start the dev-pipeline. |
+| **Pipeline Path** | Complex or batch feature execution. Planner handoff goes to `feature-planner`; launcher handoff goes to `feature-pipeline-launcher`; monitoring follows only after launch. |
+| **Current session** | The interactive AI CLI session that is already talking with the user. |
+| **Current workspace** | The current git checkout and working tree, not a background pipeline worktree/session. |
+| **Monitoring** | Status/log follow-up for a launched pipeline; it is not part of the Fast Path. |
 
-### Branch Management
+### Workspace and Branch Model
 
-The dev-pipeline handles branch management per-feature automatically:
-- Each feature is implemented on its own branch by the pipeline
-- Branches are created, committed, and managed by the pipeline session
-- This workflow does NOT create a top-level branch — the pipeline manages granular per-feature branches
+- **Fast Path**: work happens in the current workspace and current interactive session. Use the current branch unless the project policy or user explicitly asks to create a branch.
+- **Pipeline Path**: `feature-pipeline-launcher` and the dev-pipeline manage per-feature branches/worktrees. This workflow does not create a top-level branch before handing off to the launcher.
 
 ---
 
 ## Input Modes
 
-**Mode A: From natural language requirements** (default)
+**Mode A: Natural language requirements** (default)
 
-Natural language description of the project or features. Can be:
+Natural language description of the project or feature(s). Can be:
+- A single simple feature: "Add CSV export to the reports page"
 - A project vision: "Build a task management App with user login, task CRUD, and task categories"
-- A batch of features: "Implement user registration, login, and password recovery features"
+- A batch of features: "Implement user registration, login, and password recovery"
 - An incremental request: "Add user avatar upload and nickname modification to the existing system"
 
-Flow: brainstorm → feature-planner → feature-pipeline-launcher → monitor
+Flow: brainstorm → complexity assessment → AskUserQuestion → Fast Path or Pipeline Path.
 
-**Mode B: From existing .prizmkit/plans/feature-list.json**
+**Mode B: Existing `.prizmkit/plans/feature-list.json`**
 
-When user says "run pipeline from existing file" or .prizmkit/plans/feature-list.json already exists:
-- Skip brainstorm and `feature-planner` (file already exists)
+When the user says "run pipeline from existing file" or `.prizmkit/plans/feature-list.json` already exists and should be executed:
+- Skip brainstorm and `feature-planner`
 - Invoke `feature-pipeline-launcher` directly
 - Monitor and report progress
 
-**Mode C: Incremental (add to existing project)**
+**Mode C: Incremental feature request**
 
 When user says "add features to existing project" or the project already has features:
-- Brainstorm new feature requirements with the user
-- Invoke `feature-planner` in incremental mode (reads existing .prizmkit/plans/feature-list.json)
-- Append new features to existing list
-- Invoke `feature-pipeline-launcher`
-- Monitor and report progress
+- Brainstorm only the new feature requirements
+- Assess whether the new scope is simple enough for Fast Path
+- For simple work: use Fast Path in the current workspace
+- For complex or batch work: invoke `feature-planner` in incremental mode, then `feature-pipeline-launcher`
 
 ---
 
@@ -77,7 +90,7 @@ When user says "add features to existing project" or the project already has fea
 
 **Goal**: Through interactive Q&A and deep context reading, transform the user's rough idea into fully clarified, implementation-ready requirements. This phase is the foundation for high-quality code generation — vague requirements produce vague code.
 
-Critical rule: the number of questions is unlimited. Do NOT rush through this phase. Ask as many rounds as needed until every aspect is clear. The framework strives for perfect code generation, which requires perfect understanding of requirements.
+Critical rule: the number of questions is unlimited. Do NOT rush through this phase. Ask as many rounds as needed until every aspect is clear. The framework strives for high-quality code generation, which requires strong requirement understanding.
 
 ### Step 1.1: Understand the User's Vision
 
@@ -133,66 +146,69 @@ Once brainstorming is complete, produce a structured requirements summary. Read
 
 ### Step 1.7: Complexity Assessment & Approach Selection
 
-After confirming requirements, assess whether this feature needs the full pipeline or can be done directly in the current session.
+After confirming requirements, assess whether this feature needs the Pipeline Path or can be done directly in the current session/current workspace.
 
-**Simple feature** (Fast Path candidate — ALL must be true):
+**Simple feature work → Fast Path candidate** (ALL must be true):
 - Single module, no cross-module architectural impact
 - ≤2 new files to create
 - No new external dependencies or infrastructure changes
-- Straightforward implementation (CRUD, utility, simple UI component)
+- Straightforward implementation (CRUD endpoint, utility, simple UI component, small workflow)
 - Clear acceptance criteria with existing patterns to follow
 - No dependency on other unbuilt features
 
-**Complex feature** (Planning Path — ANY is true):
+**Complex or batch features → Pipeline Path candidate** (ANY is true):
+- Multiple features or batch implementation request
 - Cross-module impact (>2 modules affected)
 - New infrastructure, dependencies, or architectural patterns required
 - Multiple interrelated features with dependency ordering
 - Data model or API design decisions needed
 - Requires integration with external services
 
-User choice is required (mandatory) — use `AskUserQuestion` to present interactive selectable options. Adjust the question framing to the assessment: for a simple feature, "This feature appears straightforward."; for a complex feature, "This feature is complex and will benefit from structured planning."
+**User choice required (mandatory)** — Use `AskUserQuestion` to present interactive selectable options. Adjust the question framing to the assessment: for a simple feature, "This feature appears straightforward and can use the current-session Fast Path." For a complex or batch request, "This feature set is complex or batch-oriented and should use the Pipeline Path."
 
 ```
 AskUserQuestion:
-  question: "How would you like to proceed?"   # prefix with the framing note above
+  question: "How would you like to proceed?"
   header: "Approach"
   options:
-    - label: "Implement now (fast path)"
-      description: "Plan and implement directly in this session using /prizmkit-plan + /prizmkit-implement"
-    - label: "Add to feature list (pipeline)"
-      description: "Generate .prizmkit/plans/feature-list.json via feature-planner, then launch pipeline for autonomous execution"
+    - label: "Implement now (Fast Path — current session/current workspace)"
+      description: "Run /prizmkit-plan → /prizmkit-implement → /prizmkit-code-review → /prizmkit-retrospective → /prizmkit-committer directly in this workspace"
+    - label: "Use Pipeline Path (feature-planner → feature-pipeline-launcher)"
+      description: "Generate .prizmkit/plans/feature-list.json with feature-planner, then launch autonomous execution with feature-pipeline-launcher"
 ```
 
-- **Implement now** → Fast Path Workflow:
+- **Implement now (Fast Path)**:
   1. Invoke `/prizmkit-plan` with the requirements summary → generates `spec.md` + `plan.md`
-  2. Invoke `/prizmkit-implement` to execute the plan
-  3. After implementation, run `/prizmkit-code-review` for quality check
-  4. Commit via `/prizmkit-committer` with `feat(<scope>):` prefix
-  5. Run `/prizmkit-retrospective` to sync `.prizmkit/prizm-docs/`
-  6. End workflow — skip Phase 2/3/4
-- **Add to feature list** → Continue to Phase 2 (Plan via pipeline)
+  2. Invoke `/prizmkit-implement` to execute the plan in the current workspace
+  3. Run `/prizmkit-code-review` for quality check
+  4. Run `/prizmkit-retrospective` to sync `.prizmkit/prizm-docs/`
+  5. Commit via `/prizmkit-committer` with `feat(<scope>):` prefix
+  6. End workflow — do not call `feature-planner`, do not call `feature-pipeline-launcher`, and do not enter monitoring
+- **Use Pipeline Path** → Continue to Phase 2 (Planner handoff)
 
 Never proceed without explicit user confirmation via `AskUserQuestion`. Do NOT render options as plain text — the user must be able to click/select.
 
-**CHECKPOINT CP-FW-0.5**: Approach selected by user (fast path or pipeline).
+**CHECKPOINT CP-FW-0.5**: Approach selected by user (Fast Path or Pipeline Path).
 
 ---
 
-## Phase 2: Plan
+## Phase 2: Plan — Pipeline Path Only
+
+**Goal**: Generate structured `.prizmkit/plans/feature-list.json` from the clarified requirements.
 
-**Goal**: Generate structured .prizmkit/plans/feature-list.json from the clarified requirements.
+Run this phase only when the user selected Pipeline Path or provided a batch/complex request that they chose to send through the pipeline.
 
 **STEPS**:
 
-1. **Invoke `feature-planner` skill** with the full requirements summary from Phase 1:
+1. **Planner handoff — invoke `feature-planner`** with the full requirements summary from Phase 1:
    - Pass the structured requirements summary as input — NOT the raw user conversation
    - For new projects: standard planning mode
    - For existing projects with `--incremental`: incremental planning mode
    - **Input**: Markdown requirements summary (feature descriptions, goals, constraints)
    - **Output**: `.prizmkit/plans/feature-list.json` (schema: `dev-pipeline-feature-list-v1`) containing `project_name`, `features[]` with id (F-NNN), title, description, priority, dependencies, acceptance_criteria, status
 
-2. **Interactive planning** (if feature-planner requires clarification):
-   - Because Phase 1 was thorough, feature-planner should need minimal clarification
+2. **Interactive planning** (if `feature-planner` requires clarification):
+   - Because Phase 1 was thorough, `feature-planner` should need minimal clarification
    - If questions arise, answer from the Phase 1 context or pass through to user
 
 3. **Validate output**:
@@ -201,19 +217,19 @@ Never proceed without explicit user confirmation via `AskUserQuestion`. Do NOT r
 
 **CHECKPOINT CP-FW-1**: `.prizmkit/plans/feature-list.json` generated and validated.
 
-**If user says `--from <file>`**: Skip Phase 1 and Phase 2 entirely.
+**If user says `--from <file>`**: Skip Phase 1 and Phase 2 entirely and go to Phase 3.
 
 ---
 
-## Phase 3: Launch
+## Phase 3: Launch — Pipeline Path Only
 
-**Goal**: Start the development pipeline.
+**Goal**: Start the development pipeline after planner handoff has produced a validated feature list.
 
 **STEPS**:
 
 1. **Show feature summary** before launching:
    ```
-   Ready to launch pipeline with N features:
+   Ready to launch Pipeline Path with N features:
      F-001: User authentication (high complexity)
      F-002: Task CRUD (medium complexity)
      F-003: Task categories (low complexity)
@@ -221,9 +237,9 @@ Never proceed without explicit user confirmation via `AskUserQuestion`. Do NOT r
    Proceed? (Y/n)
    ```
 
-2. **Invoke `feature-pipeline-launcher` skill**:
+2. **Launcher handoff — invoke `feature-pipeline-launcher`**:
    - **Input**: Path to validated `.prizmkit/plans/feature-list.json`
-   - The launcher handles all prerequisites checks
+   - The launcher handles all prerequisite checks
    - The launcher presents execution mode choices to the user (foreground/background/manual)
    - The launcher asks whether to enable Critic Agent (adversarial review) — passes `--critic` flag if chosen
    - Do NOT duplicate execution mode or critic selection here — let the launcher handle it
@@ -237,9 +253,9 @@ Never proceed without explicit user confirmation via `AskUserQuestion`. Do NOT r
 
 ---
 
-## Phase 4: Monitor
+## Phase 4: Monitor — Pipeline Path Only
 
-**Goal**: Track pipeline progress and report to user.
+**Goal**: Track pipeline progress and report to user. Monitoring applies only after `feature-pipeline-launcher` has started a pipeline.
 
 **STEPS**:
 
@@ -282,13 +298,14 @@ Never proceed without explicit user confirmation via `AskUserQuestion`. Do NOT r
 The workflow supports resuming by detecting existing state:
 
 | State Found | Resume From |
-|-------------|------------|
-| No `.prizmkit/plans/feature-list.json` | Phase 1: Brainstorm |
+|-------------|-------------|
+| Fast Path `spec.md` + `plan.md` exist, code not committed | Resume `/prizmkit-implement` / review / retrospective / commit based on current state |
+| No `.prizmkit/plans/feature-list.json` and no Fast Path artifacts | Phase 1: Brainstorm |
 | `.prizmkit/plans/feature-list.json` exists, no pipeline state | Phase 3: Launch |
 | `.prizmkit/plans/feature-list.json` + pipeline state exists | Phase 4: Monitor (check status) |
 | All features completed | Report completion, suggest next steps |
 
-**Resume**: If `.prizmkit/plans/feature-list.json` exists, ask user: "Existing feature plan found with N features. Resume pipeline or re-plan?"
+**Resume**: If `.prizmkit/plans/feature-list.json` exists, ask user: "Existing feature plan found with N features. Resume Pipeline Path or re-plan?" If Fast Path artifacts exist, ask whether to continue the current-workspace implementation or discard/re-plan.
 
 ---
 
@@ -311,6 +328,7 @@ While the pipeline runs, the user can continue the conversation:
 |-------|--------|
 | User's idea is too vague to brainstorm | Ask for more context: "Can you describe the main problem this solves?" |
 | Brainstorming stalls | Offer concrete options: "Would you prefer A or B?" |
+| Fast Path starts looking complex | Pause and ask whether to switch to Pipeline Path (`feature-planner` → `feature-pipeline-launcher`) |
 | `feature-planner` cannot parse requirements | Refine the requirements summary and retry |
 | `.prizmkit/plans/feature-list.json` generation failed | Show error, retry with refined input |
 | Pipeline launch failed | Show daemon log, suggest manual start with `python3 ./.prizmkit/dev-pipeline/cli.py feature run .prizmkit/plans/feature-list.json` or `python3 ./.prizmkit/dev-pipeline/cli.py daemon feature start .prizmkit/plans/feature-list.json` |
@@ -319,15 +337,18 @@ While the pipeline runs, the user can continue the conversation:
 
 ---
 
-## Relationship to Other Skills
+## HANDOFF
 
-| Skill | Relationship |
-|-------|-------------|
-| `feature-planner` | **Called by Phase 2** — generates .prizmkit/plans/feature-list.json from clarified requirements |
-| `feature-pipeline-launcher` | **Called by Phase 3** — starts pipeline (handles execution mode selection) |
-| `bug-planner` | **Alternative** — for bug fix workflows |
-| `bugfix-pipeline-launcher` | **Alternative** — for bug fix pipelines |
-| `refactor-workflow` | **Alternative** — for code restructuring |
+| From | To | Condition |
+|------|----|-----------|
+| **this skill** | `/prizmkit-plan` | User selects Fast Path for simple feature work in the current workspace |
+| **this skill** | `/prizmkit-implement` | Fast Path plan is ready for current-session implementation |
+| **this skill** | `/prizmkit-code-review` | Fast Path implementation is complete and needs quality review |
+| **this skill** | `/prizmkit-retrospective` | Fast Path feature changes need `.prizmkit/prizm-docs/` sync before commit |
+| **this skill** | `/prizmkit-committer` | Fast Path feature changes are reviewed and docs are synced |
+| **this skill** | `feature-planner` | User selects Pipeline Path for complex or batch features |
+| `feature-planner` | `feature-pipeline-launcher` | Planner handoff produced validated `.prizmkit/plans/feature-list.json` |
+| `feature-pipeline-launcher` | **this skill** | Launcher handoff completed and monitoring/status follow-up is needed |
 
 ---
 
@@ -343,9 +364,7 @@ All internal asset paths use `${SKILL_DIR}` placeholder for cross-IDE compatibil
 
 ## Output
 
-- Structured requirements summary (Phase 1 artifact)
-- `.prizmkit/plans/feature-list.json` (Phase 2 artifact)
-- Pipeline execution (Phase 3)
-- Progress updates (Phase 4)
-- Multiple git commits with `feat(<scope>):` prefix
-- Updated `.prizmkit/prizm-docs/` (via prizmkit-retrospective per feature)
+Output depends on the selected path:
+
+- **Fast Path**: `spec.md` + `plan.md`, current-workspace code changes, `/prizmkit-code-review` result, updated `.prizmkit/prizm-docs/`, and one `feat(<scope>):` commit from `/prizmkit-committer`.
+- **Pipeline Path**: structured requirements summary, `.prizmkit/plans/feature-list.json`, pipeline execution via `feature-pipeline-launcher`, monitoring updates, and per-feature commits managed by the dev-pipeline.

package/bundled/skills/{prizm-kit → prizmkit}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: "prizm-kit"
+name: "prizmkit"
 description: "Full-lifecycle dev toolkit index. Routes to the right PrizmKit skill for spec-driven development, Prizm docs, code quality, deployment, and knowledge management. Use when the user asks 'which command?', 'help', 'how do I start a feature', 'get started', 'what tools', 'dev workflow', 'lifecycle', or '/prizmkit'. Use this as the entry point for the full PrizmKit development lifecycle. (project)"
 ---
 

package/bundled/skills/prizmkit-code-review/SKILL.md

@@ -1,15 +1,14 @@
 ---
 name: "prizmkit-code-review"
-description: "Iterative review-fix loop against spec and plan. Spawns a read-only Reviewer agent, filters findings, then a Dev agent applies fixes. Loops until PASS (max 3 rounds). Use after /prizmkit-implement as quality gate. Trigger on: 'review', 'check code', 'code review', 'is it ready to commit'. (project)"
+description: "Iterative review-fix loop against spec and plan. Spawns the dedicated prizm-dev-team-reviewer agent, filters findings, then the main orchestrator applies accepted fixes directly. Loops until PASS (max 3 rounds). Use after /prizmkit-implement as quality gate. Trigger on: 'review', 'check code', 'code review', 'is it ready to commit'. (project)"
 ---
 
 # PrizmKit Code Review
 
-An iterative review-fix loop that reviews code changes against the spec and plan, then automatically fixes issues. Uses three separated roles:
+An iterative review-fix loop that reviews code changes against the spec and plan, then automatically fixes accepted issues. Uses two separated roles:
 
-- **Reviewer Agent** (read-only): analyzes git diff against spec goals and plan decisions, produces structured findings
-- **Main Agent** (orchestrator): filters Reviewer findings for reasonableness, coordinates the loop
-- **Dev Agent** (read-write): applies fixes for accepted findings
+- **Reviewer Agent** (`prizm-dev-team-reviewer`, read-only): analyzes orchestrator-provided workspace context against spec goals and plan decisions, then produces structured findings
+- **Main Agent** (orchestrator): filters Reviewer findings for reasonableness, applies accepted fixes directly in the active checkout, and coordinates the loop
 
 The loop repeats until the Reviewer finds no issues or the max round limit is reached.
 
@@ -36,7 +35,7 @@ The loop repeats until the Reviewer finds no issues or the max round limit is re
    - If `{artifact_dir}/test-report-path.txt` exists, read the path, then read that `/prizmkit-test` report.
    - Extract `Scope`, `Generated / Updated Tests`, `In-Scope Failures`, `Baseline Failures`, `Out of Scope Gaps`, `Boundary Matrix` / `Boundary Completion Gate` when present, and `Verdict`.
    - If `context-snapshot.md` contains `## PrizmKit Test Gate`, read that summary too.
-   - If this is a feature artifact under `.prizmkit/specs/` and no test report pointer or summary exists, pass `No scoped /prizmkit-test report found` into the Reviewer context so the reviewer can flag the missing gate.
+   - If this is a feature artifact under `.prizmkit/specs/` and no test report pointer or summary exists, pass `No scoped /prizmkit-test report found (expected for pre-test review)` into the Reviewer context as informational scope context only. Do not ask the Reviewer to report it as a missing gate unless the calling workflow explicitly requires a prior test report.
 4. **Read dev rules** (if configured): If `.prizmkit/prizm-docs/root.prizm` exists, read it and check for a `RULES:` line. If present, read all referenced `.prizmkit/rules/<layer>-rules.md` files. If `root.prizm` or a referenced rules file does not exist, continue with "No custom dev rules configured — use general best practices."
 5. **Capture workspace diff**: run `git diff` (unstaged) + `git diff --cached` (staged) + `git status` to understand the full scope of changes. For new files in git status, note their paths for the Reviewer to read.
    - If no changes are detected, skip Phase 1 and proceed to Phase 2 with verdict PASS, rounds 0, and an empty findings list. Always write `review-report.md`; downstream pipeline steps use it as the review gate.
@@ -64,12 +63,12 @@ The script is stateless — no `--reset` or runtime files. Initialize these valu
 ### Loop Flow
 
 ```
-1. Spawn Reviewer Agent (read-only) → findings or PASS
+1. Spawn Reviewer Agent (`subagent_type: prizm-dev-team-reviewer`) → findings or PASS
 2. Parse result:
    - PASS → Call Loop Exit Gate → Phase 2
    - NEEDS_FIXES → count findings → Step 3 (do not call gate yet)
 3. Main Agent filters findings → Call Loop Exit Gate → if endLoop: Phase 2
-4. Spawn Dev Agent (read-write) → apply fixes
+4. Main Agent applies accepted fixes directly in the active checkout
 5. Increment round and return to Step 1
 ```
 
@@ -116,7 +115,7 @@ When Python is unavailable, apply these rules exactly — they match the script'
 
 ### Step 1: Spawn Reviewer Agent
 
-Include the dev rules read in Phase 0 step 3 in the `## Dev Rules` section of the prompt. Spawn a platform-supported **read-only** reviewer agent; use `subagent_type: Explore` only on platforms that support it. If no read-only agent is available, perform the review in the Main Agent without editing files. Read `${SKILL_DIR}/references/reviewer-agent-prompt.md` for the full prompt template — fill `{goals}`, `{plan decisions}`, `{dev rules}`, `{round N}`, and `{round_context}` before spawning.
+Include the dev rules read in Phase 0 step 4 and the workspace diff/status captured in Phase 0 step 5 in the Reviewer prompt. In Claude Code, spawn the dedicated PrizmKit Reviewer with `subagent_type: prizm-dev-team-reviewer`, `run_in_background=false`, and default/no worktree isolation. Do not request worktree isolation; this prevents AI tool-created `.claude/worktrees/...` subagent worktrees. PrizmKit pipeline-managed linked git worktrees under `.prizmkit/state/worktrees/...` are separate and controlled by `USE_WORKTREE`. Do not route the PrizmKit reviewer flow through `Explore` or a generic code-explorer agent. If the current platform has no dedicated Reviewer agent, perform the review pass in the Main Agent without editing files during that pass. Read `${SKILL_DIR}/references/reviewer-agent-prompt.md` for the full prompt template — fill `{goals}`, `{plan decisions}`, `{scoped test report}`, `{workspace context}`, `{dev rules}`, `{round N}`, and `{round_context}` before spawning.
 
 Round context varies by round:
 - Round 1: "This is the first review. Examine all changes comprehensively."
@@ -138,16 +137,16 @@ Review each finding and decide whether it's reasonable. This prevents unnecessar
 - Would fixing this improve the code without introducing risk? (Reject fixes that require large refactors outside scope.)
 
 **Output per finding:**
-- **Accepted**: The finding is reasonable — include it in the Dev Agent's task.
+- **Accepted**: The finding is reasonable — queue it for direct Main Agent fix work.
 - **Rejected** (with reason): Brief explanation (e.g., "Out of scope", "Style preference, not a defect").
 
 After filtering: call the **Loop Exit Gate** with `{"reviewer_result": "NEEDS_FIXES", "accepted_count": <N>, "findings_count": <total findings this round>, "round": <current_round>, "findings_history": <current_history>, "max_rounds": 3, "filtering_done": true}`. If `endLoop=true`, proceed to Phase 2.
 
-### Step 4: Spawn Dev Agent
+### Step 4: Main Agent Applies Accepted Fixes
 
-Spawn a platform-supported **read-write** developer agent. If no write-capable agent is available, the Main Agent applies accepted fixes directly. Read `${SKILL_DIR}/references/dev-agent-prompt.md` for the full prompt template — fill `{spec context}` and `{accepted findings}` before spawning.
+Do not spawn a Dev Agent or any review-fix developer subagent. The Main Agent applies accepted findings directly in the active checkout, using the spec context and filtered findings as the fix list. If an accepted finding cannot be safely fixed within scope, record the reason and carry it into `review-report.md` as unresolved.
 
-After the Dev Agent returns, record results and return to Step 1 for the next round.
+After direct fixes are complete, record results and return to Step 1 for the next round.
 
 ## Phase 2: Output
 

package/bundled/skills/prizmkit-code-review/references/reviewer-agent-prompt.md

@@ -1,9 +1,9 @@
 # Reviewer Agent Prompt Template
 
-Used in Phase 1 Step 1 of `/prizmkit-code-review`. The orchestrator fills `{goals}`, `{plan decisions}`, `{dev rules}`, `{round N}`, and `{round_context}` before spawning the Reviewer Agent.
+Used in Phase 1 Step 1 of `/prizmkit-code-review`. The orchestrator fills `{goals}`, `{plan decisions}`, `{scoped test report}`, `{workspace context}`, `{dev rules}`, `{round N}`, and `{round_context}` before spawning the dedicated `prizm-dev-team-reviewer` agent.
 
 ```
-You are a code reviewer. Review workspace changes against the spec goals, plan decisions, and per-layer dev rules.
+You are the dedicated PrizmKit Reviewer agent (`prizm-dev-team-reviewer`). Review workspace changes against the spec goals, plan decisions, scoped test evidence, and per-layer dev rules. Do not modify files and do not apply fixes; the Main Agent will filter findings and apply accepted fixes directly.
 
 ## Spec Goals
 {goals and acceptance criteria from spec.md}
@@ -12,7 +12,10 @@ You are a code reviewer. Review workspace changes against the spec goals, plan d
 {architecture decisions and task list from plan.md}
 
 ## Scoped Test Report
-{summary from artifact_dir/test-report-path.txt and test-report.md, including Scope, Generated / Updated Tests, In-Scope Failures, Baseline Failures, Out of Scope Gaps, Boundary Matrix / Boundary Completion Gate if present, and Verdict. If no scoped report exists for a feature artifact, write "No scoped /prizmkit-test report found."}
+{summary from artifact_dir/test-report-path.txt and test-report.md, including Scope, Generated / Updated Tests, In-Scope Failures, Baseline Failures, Out of Scope Gaps, Boundary Matrix / Boundary Completion Gate if present, and Verdict. If no scoped report exists for a feature artifact, write "No scoped /prizmkit-test report found (expected for pre-test review)." Treat that absence as informational unless the calling workflow explicitly requires a prior test report.}
+
+## Workspace Context
+{git status, unstaged diff summary, staged diff summary, and new-file paths captured by the Main Agent in Phase 0. Use this context as the review scope; request targeted file context only when needed instead of re-running broad discovery.}
 
 ## Dev Rules (per-layer conventions)
 {rules from .prizmkit/rules/<layer>-rules.md, or "No custom dev rules configured — use general best practices."}
@@ -21,13 +24,10 @@ You are a code reviewer. Review workspace changes against the spec goals, plan d
 Round {N}. {round_context}
 
 ## What to Review
-Run these commands to see the current workspace changes:
-- `git diff` (unstaged changes)
-- `git diff --cached` (staged changes)
-- `git status` (new/deleted files)
-
-For new files shown in git status, read their full content.
-For modified files, read enough surrounding context to understand the change.
+Use the orchestrator-provided workspace context as the source of truth for changed files:
+- For new files listed in workspace status, read their full content.
+- For modified files, read enough surrounding context to understand the change.
+- Do not edit files, stage changes, run test suites, or spawn other agents.
 
 ## Review Dimensions
 Evaluate the changes across these dimensions (focus on what's relevant):