@codename_inc/spectre 5.2.1 → 5.3.0

package/plugins/spectre-codex/skills/{guide → spectre-guide}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: "guide"
+name: "spectre-guide"
 description: "Use when rendering the Next Steps footer after any spectre command, suggesting next actions, or when users need guidance on which SPECTRE command to run."
 user-invocable: false
 ---
@@ -53,7 +53,7 @@ AI agents are 10x better at working around *working* existing code. That's why t
 ### Your First Feature
 
 ```plaintext
-scope
+spectre-scope
 ```
 
 That's it. Start with scope, follow the prompts, and SPECTRE will guide you through the rest. Every command ends with "Next Steps" suggestions — you never have to remember what to run next.
@@ -63,9 +63,9 @@ That's it. Start with scope, follow the prompts, and SPECTRE will guide you thro
 SPECTRE accumulates context across sessions:
 
 1. Turn off auto-compact in Claude Code `/config`
-2. Run `handoff` before session ends or when context window is getting full
+2. Run `spectre-handoff` before session ends or when context window is getting full
 3. Run `/clear` — next session auto-loads your progress
-4. `forget` when switching gears to start fresh
+4. `spectre-forget` when switching gears to start fresh
 
 ---
 
@@ -75,13 +75,13 @@ SPECTRE accumulates context across sessions:
 
 | Phase | Command | What It Does |
 |-------|---------|--------------|
-| **S**cope | `scope` | Define requirements, constraints, what's IN and OUT |
-| **P**lan | `plan` | Research codebase, create implementation plan + tasks |
-| **E**xecute | `execute` | Parallel subagent development in waves |
-| **C**lean | `clean` | Remove dead code, fix duplication, lint |
-| **T**est | `test` | Risk-aware test coverage (not brute-force 100%) |
-| **R**ebase | `rebase` | Safe merge preparation with conflict handling |
-| **E**valuate | `evaluate` | Architecture review + knowledge capture |
+| **S**cope | `spectre-scope` | Define requirements, constraints, what's IN and OUT |
+| **P**lan | `spectre-plan` | Research codebase, create implementation plan + tasks |
+| **E**xecute | `spectre-execute` | Parallel subagent development in waves |
+| **C**lean | `spectre-clean` | Remove dead code, fix duplication, lint |
+| **T**est | `spectre-test` | Risk-aware test coverage (not brute-force 100%) |
+| **R**ebase | `spectre-rebase` | Safe merge preparation with conflict handling |
+| **E**valuate | `spectre-evaluate` | Architecture review + knowledge capture |
 
 You can use any command standalone — they don't require running in order.
 
@@ -93,30 +93,30 @@ This is how the creator of SPECTRE uses it daily:
 
 ### Building a Feature (the main loop)
 
-1. **`scope`** — Get crisp on what's in/out. Non-negotiable unless it's a one-liner.
-   - If UX is unclear: run `ux` first for user flows and components
+1. **`spectre-scope`** — Get crisp on what's in/out. Non-negotiable unless it's a one-liner.
+   - If UX is unclear: run `spectre-ux` first for user flows and components
 
-2. **`plan`** — Build a well-researched technical design or task set
-   - Once you have scope/plan/tasks, run `handoff` for a fresh context window
+2. **`spectre-plan`** — Build a well-researched technical design or task set
+   - Once you have scope/plan/tasks, run `spectre-handoff` for a fresh context window
 
-3. **`execute`** — Parallel subagents work through the tasks
+3. **`spectre-execute`** — Parallel subagents work through the tasks
    - Execute also calls code review and validation automatically
-   - When done, run `handoff` again for clean context
+   - When done, run `spectre-handoff` again for clean context
 
 4. **Manual testing + fixes** — Test the feature yourself
    - Use Claude Code's built-in `/plan` mode for small fixes
-   - Use `fix` for structured debugging of tough bugs
-   - New scope needed? Run another `scope` cycle
-   - Use `handoff` liberally to keep context clean
+   - Use `spectre-fix` for structured debugging of tough bugs
+   - New scope needed? Run another `spectre-scope` cycle
+   - Use `spectre-handoff` liberally to keep context clean
 
-5. **`sweep`** — Commit accumulated changes with lint + test
+5. **`spectre-sweep`** — Commit accumulated changes with lint + test
    - Groups changes logically with descriptive conventional commits
 
-6. **`clean`** then **`test`** — Deep cleanup and risk-aware testing
+6. **`spectre-clean`** then **`spectre-test`** — Deep cleanup and risk-aware testing
 
-7. **`rebase`** — Rebase onto parent branch, prepare for merge
+7. **`spectre-rebase`** — Rebase onto parent branch, prepare for merge
 
-8. **`evaluate`** — Architecture review + capture knowledge for future sessions
+8. **`spectre-evaluate`** — Architecture review + capture knowledge for future sessions
 
 9. **Merge/PR** — Address PR comments, get it checked in
 
@@ -124,7 +124,7 @@ This is how the creator of SPECTRE uses it daily:
 
 For small/medium changes (1-5 tasks):
 ```plaintext
-quick_dev
+spectre-quick_dev
 ```
 Lightweight scope + plan that gets you to execution fast.
 
@@ -132,7 +132,7 @@ Lightweight scope + plan that gets you to execution fast.
 
 For low-complexity features/fixes where you trust the agent:
 ```plaintext
-ship
+spectre-ship
 ```
 Brain dump context, walk away, review the PR. Zero confirmation gates — scope, TDD, sweep, rebase, and PR creation happen autonomously.
 
@@ -144,118 +144,118 @@ Brain dump context, walk away, review the PR. Zero confirmation gates — scope,
 
 | Command | When to Use |
 |---------|-------------|
-| `scope` | Starting any new feature — interactive scoping with IN/OUT boundaries |
-| `kickoff` | High-ambiguity projects — includes web research for best practices |
-| `research` | Need deep codebase understanding before planning |
-| `ux` | UI-heavy features that need screen layouts, user flows, component states |
+| `spectre-scope` | Starting any new feature — interactive scoping with IN/OUT boundaries |
+| `spectre-kickoff` | High-ambiguity projects — includes web research for best practices |
+| `spectre-research` | Need deep codebase understanding before planning |
+| `spectre-ux` | UI-heavy features that need screen layouts, user flows, component states |
 
 ### Phase: Plan — Research & Task Breakdown
 
 | Command | When to Use |
 |---------|-------------|
-| `plan` | Unified entry — researches, assesses complexity, routes to right workflow |
-| `create_plan` | Complex work needing architectural design before tasking |
-| `create_tasks` | Requirements/plan ready to become concrete tasks |
-| `plan_review` | Sanity check a plan/task list for over-engineering |
+| `spectre-plan` | Unified entry — researches, assesses complexity, routes to right workflow |
+| `spectre-create_plan` | Complex work needing architectural design before tasking |
+| `spectre-create_tasks` | Requirements/plan ready to become concrete tasks |
+| `spectre-plan_review` | Sanity check a plan/task list for over-engineering |
 
 ### Phase: Execute — Development & Verification
 
 | Command | When to Use |
 |---------|-------------|
-| `execute` | Tasks exist, ready for coordinated multi-agent parallel execution |
-| `code_review` | Implementation complete, ready for in-depth review |
-| `validate` | Verify implementation against original scope requirement-by-requirement |
-| `create_test_guide` | Generate manual QA checklist based on features and risks |
+| `spectre-execute` | Tasks exist, ready for coordinated multi-agent parallel execution |
+| `spectre-code_review` | Implementation complete, ready for in-depth review |
+| `spectre-validate` | Verify implementation against original scope requirement-by-requirement |
+| `spectre-create_test_guide` | Generate manual QA checklist based on features and risks |
 
 ### Phase: Clean — Codebase Hygiene
 
 | Command | When to Use |
 |---------|-------------|
-| `clean` | Deep cleanup — dead code, duplication, artifacts |
-| `sweep` | Light pass — lint, test, descriptive commits for accumulated changes |
+| `spectre-clean` | Deep cleanup — dead code, duplication, artifacts |
+| `spectre-sweep` | Light pass — lint, test, descriptive commits for accumulated changes |
 
 ### Phase: Test — Risk-Aware Coverage
 
 | Command | When to Use |
 |---------|-------------|
-| `test` | After changes — analyzes risk tiers (P0-P3), writes behavioral tests |
+| `spectre-test` | After changes — analyzes risk tiers (P0-P3), writes behavioral tests |
 
 ### Phase: Rebase — Merge Preparation
 
 | Command | When to Use |
 |---------|-------------|
-| `rebase` | Rebase working branch onto target with conflict handling |
+| `spectre-rebase` | Rebase working branch onto target with conflict handling |
 
 ### Phase: Evaluate — Review & Learn
 
 | Command | When to Use |
 |---------|-------------|
-| `evaluate` | Full evaluate — architecture review (background) + knowledge capture |
-| `learn` | Just capture knowledge from this session |
-| `architecture_review` | Just run the architecture review |
-| `recall {query}` | Find and load existing knowledge |
+| `spectre-evaluate` | Full evaluate — architecture review (background) + knowledge capture |
+| `spectre-learn` | Just capture knowledge from this session |
+| `spectre-architecture_review` | Just run the architecture review |
+| `spectre-recall {query}` | Find and load existing knowledge |
 
 ### Session & Utilities
 
 | Command | When to Use |
 |---------|-------------|
-| `handoff` | Save session state — end of session, context full, switching gears |
-| `forget` | Clear memory, archive logs, start fresh |
-| `fix` | Structured debugging for tough bugs |
-| `quick_dev` | Lightweight scope + plan for small/medium tasks |
-| `ship` | Autonomous end-to-end: brain dump → scope → TDD → commit → rebase → PR |
+| `spectre-handoff` | Save session state — end of session, context full, switching gears |
+| `spectre-forget` | Clear memory, archive logs, start fresh |
+| `spectre-fix` | Structured debugging for tough bugs |
+| `spectre-quick_dev` | Lightweight scope + plan for small/medium tasks |
+| `spectre-ship` | Autonomous end-to-end: brain dump → scope → TDD → commit → rebase → PR |
 
 ---
 
 ## Quick Decision Tree
 
 **Starting a feature?**
--> `scope` (always start here unless it's trivial)
+-> `spectre-scope` (always start here unless it's trivial)
 
 **Feature has complex UI?**
--> `ux` after scope, before plan
+-> `spectre-ux` after scope, before plan
 
 **High ambiguity / new project?**
--> `kickoff` (includes web research)
+-> `spectre-kickoff` (includes web research)
 
 **Need to understand code first?**
--> `research`
+-> `spectre-research`
 
 **Have scope, need plan?**
--> `plan` (auto-routes based on complexity)
+-> `spectre-plan` (auto-routes based on complexity)
 
 **Have tasks, ready to build?**
--> `execute`
+-> `spectre-execute`
 
 **Code complete, need review?**
--> `code_review` then `validate`
+-> `spectre-code_review` then `spectre-validate`
 
 **Accumulated uncommitted changes?**
--> `sweep` (light) or `clean` (deep)
+-> `spectre-sweep` (light) or `spectre-clean` (deep)
 
 **Need test coverage?**
--> `test`
+-> `spectre-test`
 
 **Ready to merge?**
--> `rebase`
+-> `spectre-rebase`
 
 **Feature done?**
--> `evaluate` (review + learn)
+-> `spectre-evaluate` (review + learn)
 
 **Ending session?**
--> `handoff`
+-> `spectre-handoff`
 
 **Switching contexts?**
--> `forget`
+-> `spectre-forget`
 
 **Bug to fix?**
--> `fix`
+-> `spectre-fix`
 
 **Small task, skip ceremony?**
--> `quick_dev`
+-> `spectre-quick_dev`
 
 **Low-complexity task, full autonomy?**
--> `ship` (brain dump → PR, zero gates)
+-> `spectre-ship` (brain dump → PR, zero gates)
 
 ---
 
@@ -282,14 +282,14 @@ SPECTRE generates these documents in `docs/tasks/{branch_name}/`:
 
 | Document | Generated By | Purpose |
 |----------|-------------|---------|
-| `concepts/scope.md` | `scope` | What's IN and OUT |
-| `specs/ux.md` | `ux` | User flows, components, interactions |
-| `specs/plan.md` | `create_plan` | Technical design and phasing |
-| `specs/tasks.md` | `create_tasks` | Concrete tasks with acceptance criteria |
-| `reviews/code_review.md` | `code_review` | Severity-based code review findings |
-| `validation/validation_gaps.md` | `validate` | Gaps between scope and implementation |
-| `testing/*_test_guide.md` | `create_test_guide` | Manual QA checklists |
-| `session_logs/*_handoff.json` | `handoff` | Session state snapshots |
+| `concepts/scope.md` | `spectre-scope` | What's IN and OUT |
+| `specs/ux.md` | `spectre-ux` | User flows, components, interactions |
+| `specs/plan.md` | `spectre-create_plan` | Technical design and phasing |
+| `specs/tasks.md` | `spectre-create_tasks` | Concrete tasks with acceptance criteria |
+| `reviews/code_review.md` | `spectre-code_review` | Severity-based code review findings |
+| `validation/validation_gaps.md` | `spectre-validate` | Gaps between scope and implementation |
+| `testing/*_test_guide.md` | `spectre-create_test_guide` | Manual QA checklists |
+| `session_logs/*_handoff.json` | `spectre-handoff` | Session state snapshots |
 
 Keep these checked into git — they're the context in context engineering.
 
@@ -310,9 +310,9 @@ Keep these checked into git — they're the context in context engineering.
 ║ Next — {concise recommendation; 1–2 lines max}           ║
 ║                                                          ║
 ║ Options:                                                 ║
-║ - {command or action} — {why}                   ║
-║ - {command or action} — {why}                   ║
-║ - {command or action} — {why}                   ║
+║ - {spectre-command or action} — {why}                   ║
+║ - {spectre-command or action} — {why}                   ║
+║ - {spectre-command or action} — {why}                   ║
 ║   … up to 5 total; max 2 manual actions                  ║
 ║                                                          ║
 ║ Reply — {only if textual reply expected}                  ║
@@ -340,14 +340,14 @@ Keep these checked into git — they're the context in context engineering.
 
 **CRITICAL:**
 
-1. **All SPECTRE commands use `/spectre:` prefix** (e.g., `scope`, `execute`)
+1. **All SPECTRE commands use `/spectre:` prefix** (e.g., `spectre-scope`, `spectre-execute`)
 2. **Manual actions are NOT slash commands** (e.g., "Run tests", "Review PR feedback")
 3. **Never invent slash commands** — only suggest commands listed in this guide
 
 **Correct:**
 ```
-scope — Interactive feature scoping
-execute — Parallel agent execution
+spectre-scope — Interactive feature scoping
+spectre-execute — Parallel agent execution
 Run manual tests — Execute test guide checklist
 ```
 

package/plugins/spectre-codex/skills/{handoff → spectre-handoff}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: "handoff"
+name: "spectre-handoff"
 description: "Save state snapshot to session_logs for session resume"
 user-invocable: true
 ---

package/plugins/spectre-codex/skills/{kickoff → spectre-kickoff}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: "kickoff"
+name: "spectre-kickoff"
 description: "👻 | Project kickoff with deep research & MVP pathfinding - primary agent"
 user-invocable: true
 ---
@@ -114,11 +114,11 @@ $ARGUMENTS
   > **Established**: User problem, user value, key findings (file:line), decisions made, remaining ambiguities
   >
   > **Options**:
-  > 1. "Proceed with scope" → `scope` with FROM_KICKOFF=true, SKIP_EXPLORATION=true
-  > 2. "Skip to planning" → `plan` with kickoff doc context
-  > 3. "Need to think" → `handoff`
+  > 1. "Proceed with scope" → `spectre-scope` with FROM_KICKOFF=true, SKIP_EXPLORATION=true
+  > 2. "Skip to planning" → `spectre-plan` with kickoff doc context
+  > 3. "Need to think" → `spectre-handoff`
 
 - **Action** — ExecuteChoice:
-  - **If** scope → invoke `scope` with: FROM_KICKOFF=true, KICKOFF_DOC={path}, SKIP_EXPLORATION=true, context summary
-  - **If** planning → suggest `plan`
-  - **If** pause → run `handoff`
+  - **If** scope → invoke `spectre-scope` with: FROM_KICKOFF=true, KICKOFF_DOC={path}, SKIP_EXPLORATION=true, context summary
+  - **If** planning → suggest `spectre-plan`
+  - **If** pause → run `spectre-handoff`

package/plugins/spectre-codex/skills/{learn → spectre-learn}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: "learn"
+name: "spectre-learn"
 description: "Use when user invokes /learn or wants to save patterns, decisions, gotchas, procedures, or feature knowledge from a conversation for later re-use. Look for user requests like \"please remember\" or \"what did we learn from this?\"."
 user-invocable: true
 ---
@@ -11,7 +11,7 @@ You capture durable project knowledge into Skills that Claude Code loads on-dema
 <CRITICAL>
 ## Exclusive Knowledge Handler
 
-When this skill is invoked (via `/learn`, `learn`, or `Skill(learn)`), it is the **exclusive handler** for knowledge capture. It supersedes ALL other memory systems.
+When this skill is invoked (via `/learn`, `spectre-learn`, or `Skill(spectre-learn)`), it is the **exclusive handler** for knowledge capture. It supersedes ALL other memory systems.
 
 **Do NOT**:
 - Write to `MEMORY.md` or any auto-memory directory

package/plugins/spectre-codex/skills/{plan → spectre-plan}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: "plan"
+name: "spectre-plan"
 description: "👻 | Unified planning entry point - researches, assesses complexity, routes to workflow - primary agent"
 user-invocable: true
 ---
@@ -15,7 +15,7 @@ Treat the current command arguments as this workflow's input. When invoked from
 ## Description
 
 - **What** — Research codebase, assess complexity, route to appropriate workflow (direct tasks or plan-first)
-- **Outcome** — Detailed task breakdown ready for execution
+- **Outcome** — A right-sized `plan.md` + `tasks.md`; STANDARD/COMPREHENSIVE include review and a final execution gate, while LIGHT stays non-blocking.
 
 ## ARGUMENTS Input
 
@@ -23,7 +23,7 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 ## MANDATORY COMPLIANCE RULES
 
-> **⚠️ NON-NEGOTIABLE**: This workflow MUST invoke nested workflows via the Skill tool. Failure to invoke `Skill(create_plan)` and `Skill(create_tasks)` (Claude slash route: `create_plan` and `create_tasks`) is a critical error. Do NOT summarize, describe, or skip these workflows. INVOKE THEM.
+> **⚠️ NON-NEGOTIABLE**: After tier routing, this workflow MUST invoke nested workflows via the Skill tool. LIGHT must invoke `Skill(spectre-create_plan)` and `Skill(spectre-create_tasks)`; STANDARD/COMPREHENSIVE must invoke `Skill(spectre-create_plan)`, `Skill(spectre-create_tasks)`, and `Skill(spectre-plan_review)` (Claude slash route: `spectre-create_plan`, `spectre-create_tasks`, and `spectre-plan_review`). Failure to invoke the required skills is a critical error. Do NOT summarize, describe, or skip these workflows. INVOKE THEM.
 
 **After ANY user conversation or questions:**
 
@@ -33,14 +33,16 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 **You MUST call these skills (not describe them):**
 
-- Use the **Skill** tool with `skill: "spectre-create_plan"` and `args: "{path} --depth {tier}"` — generates plan.md
+- Use the **Skill** tool with `skill: "spectre-create_plan"` and `args: "{path} --depth {tier}"` — generates plan.md, including LIGHT
 - Use the **Skill** tool with `skill: "spectre-create_tasks"` and `args: "{path}"` — generates tasks.md
+- Use the **Skill** tool with `skill: "spectre-plan_review"` and `args: "{OUT_DIR} --auto-apply scope-safe"` — reviews and integrates scope-safe feedback for STANDARD/COMPREHENSIVE
 
 ## Instructions
 
 - Research before routing; present architectural options for user buy-in
 - Route based on hard-stops and clarity, not point-scoring
 - Never overwrite existing `tasks.md` or `plan.md` — use scoped names
+- Treat `concepts/scope.md` (then `specs/prd.md` / `specs/ux.md` when present) as canonical. Plan generation, task generation, review, and feedback integration may change implementation approach, sequencing, verification, references, and YAGNI fences, but MUST NOT cut, narrow, expand, or reinterpret the agreed scope without an explicit user scope-change gate.
 
 ## Step 1 - Research Codebase
 
@@ -124,7 +126,7 @@ Use research findings from Step 1 to determine appropriate planning depth.
 
 ## Step 3 - High-Level Design
 
-**SKIP IF LIGHT** — proceed directly to Step 4.
+**SKIP IF LIGHT** — proceed directly to Step 4. LIGHT still generates a real plan in Step 4; it only skips this human alignment gate.
 
 Goal: align on the *shape* of the solution before generating a full plan. This catches misalignments early and gives the user a chance to redirect before reading a long plan doc.
 
@@ -171,7 +173,7 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 - **Action** — PersistDesign: Append a "Selected Design" section to `{OUT_DIR}/task_context.md` capturing the agreed approach, key decisions, and resolved questions. This is what `create_plan` consumes.
 
-> **CHECKPOINT**: After alignment, proceed IMMEDIATELY to Step 4. The ONLY valid next action is invoking a Skill.
+> **CHECKPOINT**: After alignment, proceed IMMEDIATELY to Step 4. This is the early gate. The next valid actions are Skill invocations that generate the draft plan, generate tasks, run plan_review, integrate scope-safe feedback, and then present the final plan/tasks for the user's final gate.
 
 ## Step 4 - Route to Workflow
 
@@ -182,11 +184,12 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 │  YOU MUST USE THE SKILL TOOL TO INVOKE THESE COMMANDS                  │
 │                                                                        │
 │  ❌ WRONG: "I'll now create the plan..."                               │
-│  ❌ WRONG: "The next step would be to run create_plan"        │
+│  ❌ WRONG: "The next step would be to run spectre-create_plan"        │
 │  ❌ WRONG: Ending turn without invoking Skill tool                     │
 │                                                                        │
 │  ✅ CORRECT: Skill tool with skill: "spectre-create_plan", args: "..." │
 │  ✅ CORRECT: Skill tool with skill: "spectre-create_tasks", args: "..."│
+│  ✅ CORRECT: Skill tool with skill: "spectre-plan_review", args: "..." │
 └────────────────────────────────────────────────────────────────────────┘
 ```
 
@@ -202,6 +205,7 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 - Use the Skill tool: `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth {tier}"`
 - Use the Skill tool: `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
+- For STANDARD/COMPREHENSIVE, use the Skill tool: `skill: "spectre-plan_review"`, `args: "{OUT_DIR} --auto-apply scope-safe"`
 
 ---
 
@@ -209,27 +213,34 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 
 - **If LIGHT**:
 
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth light --no-review"`
+  - **Wait** — Returns concise plan with solution shape, patterns, risks, and verification approach
   - **INVOKE NOW** → Skill tool with `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md --depth light"`
-  - **Wait** — Returns task breakdown with brief implementation approach
+  - **Wait** — Returns task breakdown grounded in the light plan
+  - **Action** — PresentLightArtifacts: Summarize `{OUT_DIR}/specs/plan.md` and `{OUT_DIR}/specs/tasks.md`. State that LIGHT skipped `plan_review` and the human execution gate by design.
   - Skip to footer
 
 - **ElseIf STANDARD**:
 
-  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth standard"`
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth standard --no-review"`
   - **Wait** — Returns focused plan (Overview, Approach, Out of Scope)
-  - **Action** — PromptUser: "Review plan. Reply 'Approved' or provide feedback."
-  - **Wait** — User approval
   - **INVOKE NOW** → Skill tool with `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
   - **Wait** — Returns task breakdown
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-plan_review"`, `args: "{OUT_DIR} --auto-apply scope-safe"`
+  - **Wait** — Returns findings, applied edits, skipped scope-changing recommendations, and updated artifacts
+  - **Action** — IntegratePlanReviewFeedback: Read the plan_review report path returned by `plan_review`. Confirm every scope-safe Blocker/High finding is reflected in `plan.md` and/or `tasks.md`. If `plan_review` produced a scope-safe suggested edit but did not apply it because it needed minor adaptation, apply the smallest artifact edit now and record it in the final summary. Do not apply Scope Change Required findings.
+  - Continue to Final Gate
 
 - **ElseIf COMPREHENSIVE**:
 
-  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth comprehensive"`
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-create_plan"`, `args: "{OUT_DIR}/task_context.md --depth comprehensive --no-review"`
   - **Wait** — Returns full plan (all sections: Architecture, Phases, API Design, Testing Strategy, etc.)
-  - **Action** — PromptUser: "Review plan. Reply 'Approved' or provide feedback."
-  - **Wait** — User approval
   - **INVOKE NOW** → Skill tool with `skill: "spectre-create_tasks"`, `args: "{OUT_DIR}/task_context.md"`
   - **Wait** — Returns task breakdown
+  - **INVOKE NOW** → Skill tool with `skill: "spectre-plan_review"`, `args: "{OUT_DIR} --auto-apply scope-safe"`
+  - **Wait** — Returns findings, applied edits, skipped scope-changing recommendations, and updated artifacts
+  - **Action** — IntegratePlanReviewFeedback: Read the plan_review report path returned by `plan_review`. Confirm every scope-safe Blocker/High finding is reflected in `plan.md` and/or `tasks.md`. If `plan_review` produced a scope-safe suggested edit but did not apply it because it needed minor adaptation, apply the smallest artifact edit now and record it in the final summary. Do not apply Scope Change Required findings.
+  - Continue to Final Gate
 
 ---
 
@@ -253,4 +264,19 @@ Only proceed past this checkpoint when the user confirms.
 
 ---
 
+### Final Gate
+
+- **Action** — PresentFinalArtifacts:
+  - Summarize final artifact paths: `{OUT_DIR}/specs/plan.md`, `{OUT_DIR}/specs/tasks.md`, and the saved plan_review report under `{OUT_DIR}/reviews/`.
+  - Summarize review integration: findings applied by `plan_review`, any additional plan-orchestrator edits applied to integrate feedback, skipped edits, and any recommendations that were blocked because they would change canonical scope.
+  - If plan_review surfaced a scope-changing recommendation, state: "This requires a scope change; I did not apply it." Ask the user whether to reopen scope or approve the current canonical-scope-preserving plan/tasks.
+  - Otherwise prompt: "Final reviewed plan/tasks are ready. Reply `Approved` to proceed to execution, or provide final feedback."
+
+- **Wait** — User final approval or feedback.
+
+- **If feedback preserves canonical scope** — apply the smallest edits to `plan.md`/`tasks.md`, re-run `plan_review {OUT_DIR} --auto-apply scope-safe` if the feedback changes implementation approach, verification, dependencies, task sequencing, or references, then present the Final Gate again.
+- **If feedback changes canonical scope** — stop and route back to `spectre-scope` (or explicitly update the canonical scope artifact if the user directs it). Do not silently update plan/tasks against stale scope.
+
+---
+
 - **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps

package/plugins/spectre-codex/skills/{plan_review → spectre-plan_review}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: "plan_review"
+name: "spectre-plan_review"
 description: "👻 | Independent multi-lens review of plan.md and/or tasks.md — finds overengineering, missing verification, hallucinated deps, weak references"
 user-invocable: true
 ---
@@ -16,8 +16,15 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 - **What** — Independent review of any available planning artifacts (`plan.md`, `tasks.md`, and optional `task_context.md`) from four specialized lenses, dispatched in parallel
 - **Outcome** — Structured findings with concrete edit suggestions; optional write-back to update the available artifacts
+- **Artifact** — Always save a Markdown review report before any write-back so pre-integration findings are auditable
 - **Role** — Senior staff engineer + reviewer panel; bias toward pragmatic problem-solving, YAGNI enforcement, and verifiability
 
+## Canonical Scope Invariant
+
+`concepts/scope.md` is canonical when present. If absent, use `specs/prd.md`, `specs/ux.md`, and explicit requirements in `task_context.md` as the scope source, in that order.
+
+Reviewers may recommend deleting unrequested implementation details, unnecessary abstractions, weak verification, hallucinated references, bad dependencies, or task sequencing problems. They MUST NOT cut, narrow, expand, or reinterpret agreed scope. If a reviewer believes the agreed scope itself is too large, internally inconsistent, or missing a requirement, phrase that as a **Scope Change Required** recommendation for the user. Do not apply it to `plan.md` or `tasks.md` during write-back.
+
 ## ARGUMENTS Input
 
 <ARGUMENTS>
@@ -46,12 +53,15 @@ A single reviewer biases toward the issues it notices first. Published practice
   - `PLAN=${TASK_DIR}/specs/plan.md` (or scoped name)
   - `TASKS=${TASK_DIR}/specs/tasks.md` (or scoped name)
   - `CONTEXT=${TASK_DIR}/task_context.md`
+  - `SCOPE=${TASK_DIR}/concepts/scope.md` when present; otherwise use `specs/prd.md` / `specs/ux.md` as available
+  - `REVIEWS_DIR=${TASK_DIR}/reviews`
+  - `REVIEW_REPORT=${REVIEWS_DIR}/plan_review.md`; if that exists, use `plan_review_{YYYY-MM-DD_HHMMSS}.md` to avoid overwriting prior review evidence.
   - `plan.md` and `tasks.md` are independently reviewable. It is valid to review only `plan.md`, only `tasks.md`, or both.
   - `task_context.md` is helpful context but is not required. If it is missing, continue and note that requirements traceability is limited.
-  - If both `plan.md` and `tasks.md` are missing, stop and suggest the user run `plan` or `create_tasks` first.
+  - If both `plan.md` and `tasks.md` are missing, stop and suggest the user run `spectre-plan` or `spectre-create_tasks` first.
   - If exactly one of `plan.md` or `tasks.md` is missing, list it as absent context and continue. Do not decline, stop, or ask the user to create the missing artifact.
 
-- **Action** — ReadAvailable: Read each available file completely into context before dispatching reviewers. Reviewers receive curated excerpts plus an artifact manifest that says which files are present and absent. Every reviewer must review the artifacts that exist and must not treat absent artifacts as a blocker.
+- **Action** — ReadAvailable: Read each available file completely into context before dispatching reviewers. Reviewers receive curated excerpts plus an artifact manifest that says which files are present and absent. Every reviewer must review the artifacts that exist and must not treat absent artifacts as a blocker. The manifest must label the canonical scope source and state that review findings may not remove or narrow scope.
 
 ## Step 2 — Dispatch Four Parallel Reviewers
 
@@ -64,13 +74,15 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
 > Review the available plan and/or task list for unrequested complexity. Agents have a documented "familiar-shape bias": shown a feature, they reproduce the mature-system shape from their training data (auth → adds rate-limiting; CRUD → adds soft-delete; form → adds optimistic UI; service → adds telemetry; module → adds feature flags). Your job is to find that bias here.
 >
 > Find:
-> 1. When `plan.md` is present: anything in Technical Approach that isn't traceable to a requirement in available context (`task_context.md` / scope / PRD). If context is absent, use the plan's own requirements and boundaries.
+> 1. When `plan.md` is present: anything in Technical Approach that isn't traceable to a requirement in available context (`scope.md` / `task_context.md` / PRD / UX). If context is absent, use the plan's own requirements and boundaries.
 > 2. When `tasks.md` is present: tasks that implement something the available requirements don't ask for. If requirements context is absent, use the task list's stated goals and boundaries.
 > 3. Abstractions, interfaces, or layers introduced for a single concrete caller.
 > 4. Generality (config files, plugin points, factories) where the actual need is one specific behavior.
 > 5. Overlap with the `Out-of-Bounds — DO NOT add` list (if anything violates that list, it's a hard fail).
 >
-> Required output: nominate the SINGLE highest-leverage thing to delete and justify it. You must pick one. Then list other simplifications ranked by impact. For each finding, cite the exact file:line or section header it lives in.
+> Scope guard: you may nominate implementation detail to delete only when it is not required by canonical scope. Do not nominate an agreed requirement, user-approved behavior, or required task as the thing to delete. If the best "cut" would change canonical scope, label it **Scope Change Required** and do not include it as an auto-applicable deletion.
+>
+> Required output: nominate the SINGLE highest-leverage implementation detail to delete and justify it. You must pick one unless every possible deletion would change canonical scope; in that case, say "No scope-safe deletion found" and provide the nearest Scope Change Required recommendation separately. Then list other simplifications ranked by impact. For each finding, cite the exact file:line or section header it lives in.
 
 ### Lens 2 — Verifiability (`@analyst`)
 
@@ -118,6 +130,7 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
   - **High** — meaningfully reduces output quality (missing RED test, weak canonical reference, prose criterion)
   - **Medium** — overengineering or reuse miss without functional blast radius
   - **Low** — stylistic or nice-to-have
+  - **Scope Change Required** — may be valid feedback, but would cut, expand, or reinterpret canonical scope and therefore needs explicit user approval before any artifact edit
 
 - **Action** — RenderFindingsTable: Output a single structured table. Schema is fixed.
 
@@ -143,11 +156,24 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
   - Low: {N}
   ```
 
+- **Action** — SaveReviewArtifact: Before applying any edits to `plan.md` or `tasks.md`, save the pre-integration review findings as a Markdown report.
+  - Create `${REVIEWS_DIR}` if missing.
+  - Write `${REVIEW_REPORT}` using the RenderFindingsTable content plus:
+    - Reviewed artifacts: exact plan/tasks/context/scope paths present and absent.
+    - Canonical scope source used.
+    - Auto-apply mode: enabled/disabled.
+    - Timestamp.
+    - Explicit note: "This report captures plan_review findings before any write-back to plan.md or tasks.md."
+  - Do not overwrite an existing report. Use the timestamped filename if the default already exists.
+  - Include the saved report path in all subsequent summaries and in `ReportApplied`.
+
 ## Step 4 — Surface Findings & Apply Edits
 
-- **Action** — PresentFindings: Render the findings table inline.
+- **Action** — PresentFindings: Render the findings table inline and include `Review report saved: {REVIEW_REPORT}`.
+
+- **Action** — DetectAutoApplyMode: If ARGUMENTS contains `--auto-apply scope-safe`, skip the user selection prompt and apply all scope-safe Blocker and High findings, plus Medium/Low findings only when the Suggested Edit is unambiguous and cannot change canonical scope. Do not apply findings marked Scope Change Required. Continue to ApplyEdits and SelfCheck, then return the applied/skipped summary to the invoking workflow.
 
-- **Action** — OfferWriteBack: After the table, prompt:
+- **Action** — OfferWriteBack: Unless `--auto-apply scope-safe` is present, after the table prompt:
 
   > Reply with which findings to apply:
   > - `all` — apply every suggested edit
@@ -163,17 +189,21 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
   - Open the named artifact (`plan.md` or `tasks.md`)
   - Apply the Suggested Edit verbatim where possible; if the edit needs adaptation, make the minimum change consistent with the finding's intent
   - Track which findings were applied
+  - Before writing, confirm the edit preserves every requirement and boundary in the canonical scope source. If it would remove, narrow, expand, or reinterpret scope, skip it and record it as "skipped: requires scope change."
 
 - **Action** — SelfCheck: After edits, run a fast pass over the modified sections:
   - Re-verify any file:line refs touched
   - Re-verify acceptance criteria are still executable
   - Confirm no edit introduced a new Out-of-Bounds violation
+  - Confirm canonical scope is still fully represented by the resulting plan/tasks
   - If any check fails, surface it and ask the user before continuing
 
 - **Action** — ReportApplied:
 
   > Applied: {list of finding numbers}. Skipped: {list}.
+  > Review report: {REVIEW_REPORT}.
   > {Path to updated artifact(s)}.
+  > Scope-change recommendations not applied: {list or "none"}.
 
 ## Step 5 — Next Steps
 
@@ -183,6 +213,6 @@ Missing-artifact rule for every lens: review what exists. If a finding depends o
 
 ## Notes
 
-- This skill does NOT generate plans or tasks. It reviews available planning artifacts. If only one of `plan.md` or `tasks.md` exists, review that artifact. Only route the user to `plan` or `create_tasks` when neither reviewable artifact exists.
+- This skill does NOT generate plans or tasks. It reviews available planning artifacts. If only one of `plan.md` or `tasks.md` exists, review that artifact. Only route the user to `spectre-plan` or `spectre-create_tasks` when neither reviewable artifact exists.
 - The four lenses are intentionally non-overlapping by design but will surface overlap in practice — dedupe at synthesis, don't ask reviewers to coordinate.
 - The "Must-Delete" nomination from Lens 1 is mandatory output — even on a tight plan, naming the single weakest element is a forcing function against under-review.