@codename_inc/spectre 5.2.1 → 5.3.0

package/package.json

@@ -1,9 +1,9 @@
 {
   "name": "@codename_inc/spectre",
-  "version": "5.2.1",
+  "version": "5.3.0",
   "type": "module",
   "bin": {
-    "spectre": "./bin/spectre.js"
+    "spectre": "bin/spectre.js"
   },
   "files": [
     "bin",

package/plugins/spectre/.claude-plugin/plugin.json

@@ -1,5 +1,5 @@
 {
   "name": "spectre",
-  "version": "5.2.1",
+  "version": "5.3.0",
   "description": "Agentic coding workflow with session memory. spectre guides you through Scope, Plan, Execute, Clean, Test, Rebase, and Extract phases."
 }

package/plugins/spectre/hooks/scripts/load-knowledge.mjs

@@ -7,7 +7,7 @@
  * AGENTS.override.md and returns a short visible status line.
  *
  * Reads:
- * - Apply skill from plugin: skills/apply/SKILL.md
+ * - Apply skill from plugin: skills/spectre-apply/SKILL.md
  * - Registry from project: .agents/skills/spectre-recall/references/registry.toon
  */
 
@@ -27,6 +27,13 @@ function resolvePluginSkillPath(pluginRoot, skillName, ...parts) {
     path.join(pluginRoot, 'skills', skillName, ...parts),
     path.join(pluginRoot, '..', 'skills', skillName, ...parts),
   ];
+  const legacyBareName = skillName.startsWith('spectre-') ? skillName.slice('spectre-'.length) : null;
+  if (legacyBareName) {
+    candidates.push(
+      path.join(pluginRoot, 'skills', legacyBareName, ...parts),
+      path.join(pluginRoot, '..', 'skills', legacyBareName, ...parts)
+    );
+  }
 
   for (const candidate of candidates) {
     if (fs.existsSync(candidate)) {
@@ -119,7 +126,7 @@ function main() {
   const projectDir = process.env.CLAUDE_PROJECT_DIR || process.cwd();
   const pluginRoot = getPluginRoot();
 
-  const applySkillPath = resolvePluginSkillPath(pluginRoot, 'apply', 'SKILL.md');
+  const applySkillPath = resolvePluginSkillPath(pluginRoot, 'spectre-apply', 'SKILL.md');
 
   if (!fs.existsSync(applySkillPath)) {
     process.exit(0);
@@ -146,7 +153,11 @@ function main() {
   // Read apply skill and strip frontmatter
   let applyContent = fs.readFileSync(applySkillPath, 'utf8');
   applyContent = stripFrontmatter(applyContent);
-  applyContent = applyContent.replaceAll('.claude/skills/', '.agents/skills/').replaceAll('/spectre:', '');
+  applyContent = applyContent
+    .replaceAll('.claude/skills/', '.agents/skills/')
+    .replace(/\/spectre:([A-Za-z0-9_-]+)/g, (_match, skillName) => {
+      return skillName.startsWith('spectre-') ? skillName : `spectre-${skillName}`;
+    });
 
   if (hasProjectKnowledgeSurface(projectDir, registryPath)) {
     writeManagedOverride(

package/plugins/spectre/hooks/scripts/register_learning.mjs

@@ -174,6 +174,13 @@ function resolvePluginSkillPath(pluginRoot, skillName, ...parts) {
     path.join(pluginRoot, 'skills', skillName, ...parts),
     path.join(pluginRoot, '..', 'skills', skillName, ...parts),
   ];
+  const legacyBareName = skillName.startsWith('spectre-') ? skillName.slice('spectre-'.length) : null;
+  if (legacyBareName) {
+    candidates.push(
+      path.join(pluginRoot, 'skills', legacyBareName, ...parts),
+      path.join(pluginRoot, '..', 'skills', legacyBareName, ...parts)
+    );
+  }
 
   for (const candidate of candidates) {
     if (fs.existsSync(candidate)) {
@@ -228,7 +235,7 @@ function main() {
     // Script is at: <plugin_root>/hooks/scripts/register_learning.mjs
     pluginRoot = path.resolve(__dirname, '..', '..');
   }
-  const templatePath = resolvePluginSkillPath(pluginRoot, 'learn', 'references', 'recall-template.md');
+  const templatePath = resolvePluginSkillPath(pluginRoot, 'spectre-learn', 'references', 'recall-template.md');
 
   // Ensure directories exist
   fs.mkdirSync(registryDir, { recursive: true });

package/plugins/spectre/hooks/scripts/test_load-knowledge.mjs

@@ -23,10 +23,10 @@ function createTmpDir() {
 }
 
 function createApplySkill(pluginDir) {
-  const skillPath = path.join(pluginDir, 'skills', 'apply', 'SKILL.md');
+  const skillPath = path.join(pluginDir, 'skills', 'spectre-apply', 'SKILL.md');
   fs.mkdirSync(path.dirname(skillPath), { recursive: true });
   fs.writeFileSync(skillPath,
-    '---\nname: apply\n---\n\n# Apply Knowledge\n\n' +
+    '---\nname: spectre-apply\n---\n\n# Apply Knowledge\n\n' +
     '## How to Find Skills\n\nScan available skills.\n\n' +
     '## Workflow\n\nDo things.\n'
   );
@@ -34,10 +34,10 @@ function createApplySkill(pluginDir) {
 }
 
 function createCodexApplySkill(codexHome) {
-  const skillPath = path.join(codexHome, 'skills', 'apply', 'SKILL.md');
+  const skillPath = path.join(codexHome, 'skills', 'spectre-apply', 'SKILL.md');
   fs.mkdirSync(path.dirname(skillPath), { recursive: true });
   fs.writeFileSync(skillPath,
-    '---\nname: apply\n---\n\n# Apply Knowledge\n\n' +
+    '---\nname: spectre-apply\n---\n\n# Apply Knowledge\n\n' +
     '## How to Find Skills\n\nScan available skills.\n\n' +
     '## Workflow\n\nDo things.\n'
   );

package/plugins/spectre/hooks/scripts/test_register-learning.mjs

@@ -114,7 +114,7 @@ describe('register_learning', () => {
     const pluginRoot = path.join(tmp, 'plugin');
 
     // Create template
-    const templateDir = path.join(pluginRoot, 'skills', 'learn', 'references');
+    const templateDir = path.join(pluginRoot, 'skills', 'spectre-learn', 'references');
     fs.mkdirSync(templateDir, { recursive: true });
     fs.writeFileSync(
       path.join(templateDir, 'recall-template.md'),
@@ -146,7 +146,7 @@ describe('register_learning', () => {
     const codexHome = path.join(tmp, 'codex-home');
     const runtimeRoot = path.join(codexHome, 'spectre');
 
-    const templateDir = path.join(codexHome, 'skills', 'learn', 'references');
+    const templateDir = path.join(codexHome, 'skills', 'spectre-learn', 'references');
     fs.mkdirSync(templateDir, { recursive: true });
     fs.writeFileSync(
       path.join(templateDir, 'recall-template.md'),

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

@@ -1,5 +1,5 @@
 ---
-name: apply
+name: spectre-apply
 description: Use when starting implementation, debugging, or feature work on a project with captured knowledge.
 user-invocable: false
 ---
@@ -21,7 +21,7 @@ DO NOT search the codebase or dispatch agents BEFORE loading relevant knowledge
 
 **When a command explicitly tells you to load a skill, you MUST call the Skill tool to load it.** Do not improvise the workflow based on what you think the skill does. The skill defines a specific workflow with precise steps, output formats, file locations, and integrations. Your improvised version will be wrong.
 
-**You are also responsible for keeping knowledge current.** After completing significant work, proactively check whether loaded skills need updating and whether new skills should be captured via `Skill(learn)`. Do NOT wait for the user to ask.
+**You are also responsible for keeping knowledge current.** After completing significant work, proactively check whether loaded skills need updating and whether new skills should be captured via `Skill(spectre-learn)`. Do NOT wait for the user to ask.
 </CRITICAL>
 
 ## Path Convention
@@ -49,7 +49,7 @@ The registry at `{{project_root}}/.claude/skills/spectre-recall/references/regis
 After completing work, check:
 
 1. **Loaded skill now outdated?** → Update it immediately
-2. **Discovered something capture-worthy?** (gotcha, pattern, decision) → Capture via `Skill(learn)`
+2. **Discovered something capture-worthy?** (gotcha, pattern, decision) → Capture via `Skill(spectre-learn)`
 3. **Changed key files, flows, or architecture?** → Update the relevant feature skill
 4. **Made a decision with non-obvious rationale?** → Capture before the session ends
 

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

@@ -1,5 +1,5 @@
 ---
-name: architecture_review
+name: spectre-architecture_review
 description: 👻 | Conduct principal architecture review
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: clean
+name: spectre-clean
 description: 👻 | Complete cleanup flow - clean, inspect, lint, test - primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: code_review
+name: spectre-code_review
 description: 👻 | Independent LLM Code Review - subagent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: create_plan
+name: spectre-create_plan
 description: 👻 | Create implementation plan from PRD - primary agent
 user-invocable: true
 ---
@@ -27,6 +27,7 @@ Treat the current command arguments as this workflow's input. When invoked from
 - **Action** — CheckExistingResearch: Check if technical research already completed.
   - Read `TASK_DIR/task_context.md`; look for "## Technical Research" section.
   - **If** found with comprehensive analysis → use existing research; skip to Step 3.
+  - **If** ARGUMENTS contains `--depth light` and `TASK_DIR/task_context.md` already contains substantive router research (file locations, code understanding, codebase patterns, and impact summary) → use existing research; skip to Step 3.
   - **Else** → proceed with new research below.
 - **Action** — AutomatedResearch: Spawn parallel research agents for comprehensive analysis.
   - Use `@finder` to find all files related to feature area.
@@ -61,6 +62,8 @@ Treat the current command arguments as this workflow's input. When invoked from
 
 Dynamically generate up to 10 technical questions based on research findings. **IMPORTANT**: Only ask questions genuinely not answered in the PRD or discoverable through code investigation. Goal: eliminate scope and design ambiguity. If a question involves choosing between approaches, present options with Pros/Cons/Trade-offs.
 
+- **Action** — LightModeClarifications: If ARGUMENTS contains `--depth light`, do NOT stop for user clarifications. Use conservative, codebase-consistent defaults and record them in the plan's **Filled Assumptions** section, then skip to Step 3. If an unresolved question would affect canonical scope, security/privacy, data correctness, or public API behavior, return control to `plan` with a tier reassessment recommendation instead of guessing.
+
 - **Action** — DetectClarificationMethod: Check if `AskUserQuestion` tool is available.
   - **If available** → use inline clarification flow (Path A).
   - **If not available** → use file-based clarification flow (Path B).
@@ -94,16 +97,17 @@ Dynamically generate up to 10 technical questions based on research findings. **
 - **Action** — DetermineDepth: Read `--depth` from ARGUMENTS
 
   - Default: `standard` if not specified
-  - Options: `standard`, `comprehensive`
+  - Options: `light`, `standard`, `comprehensive`
+- **Action** — DetectOrchestratedMode: If ARGUMENTS contains `--no-review`, this workflow is being invoked by `plan` as part of the meta-flow. Generate and save the plan, then return control to `plan` without asking for standalone user review.
 
 - **Action** — DesignTechnicalApproach: Create the implementation plan.
 
-  Every plan, regardless of depth, MUST include these seven sections. They are the verification spine — without them, downstream agents cannot self-check their work.
+  Every plan, regardless of depth, MUST include the verification spine. LIGHT is concise, not shallow: keep it brief and decisive, but still explain the solution shape, codebase pattern to follow, risks/assumptions, and how the work will be verified.
 
-  **Required for both STANDARD and COMPREHENSIVE:**
+  **Required for LIGHT, STANDARD, and COMPREHENSIVE:**
   1. **Overview** — 1–2 paragraphs: what problem, what shape the solution takes, why this approach.
   2. **Technical Approach** — How the change actually lands: components touched, data flow, key decisions with rationale. Reference existing patterns from `@patterns` research by file:line (e.g., "follow the shape of `src/widgets/HotDogWidget.ts:42` for the registration step").
-  3. **Critical Files for Implementation** — 3–7 specific files from research. Format: `path/to/file.ts` — *reason* (Core logic to modify / Pattern to follow / Interface to implement / Test to extend). No guesses — only files surfaced during Step 1 research.
+  3. **Critical Files for Implementation** — 1–7 specific files from research. Format: `path/to/file.ts` — *reason* (Core logic to modify / Pattern to follow / Interface to implement / Test to extend). No guesses — only files surfaced during Step 1 research.
   4. **External Dependencies — Verify Before Implementation** — Every third-party package required, with exact version and a one-line existence check. Format: `package@1.2.3 — verify: npm view package@1.2.3` (or pip equivalent). Required even if "no new packages" (write that explicitly). This is the slopsquatting fence: ~20% of AI-suggested packages don't exist; we catch that here, not in production.
   5. **Verification — How We Know This Works** — For each major change in Technical Approach, 1–3 falsifiable signals: a test name, an observable behavior, or a state/file condition. Prose like "the feature works" is not acceptable — it must be checkable. Format: `<change> → verifies by: <test name | observable behavior | state condition>`. These become acceptance criteria in `create_tasks` downstream.
   6. **Out-of-Bounds — DO NOT add** — 4–8 concrete things the implementation must NOT add, even if "best practice." Examples: rate limiting, retry/backoff, caching layer, optimistic UI, soft-delete, telemetry events, feature flags, admin UI. This is the YAGNI fence against familiar-shape bias (agents reproduce mature-system patterns unprompted). Be specific to this feature, not generic.
@@ -111,6 +115,12 @@ Dynamically generate up to 10 technical questions based on research findings. **
      - *Risks*: what could go wrong (e.g., concurrent write race, migration ordering, third-party rate limit). Each with a one-line mitigation or "accept and monitor."
      - *Filled Assumptions*: things the plan defaulted because the spec didn't say (e.g., "Assumed Postgres; spec didn't specify DB." "Assumed retry count = 0; spec didn't mention failure modes."). Reviewer-visible by design — these are the silent decisions that bite at execution.
 
+  **LIGHT constraints:**
+  - Keep the seven required sections compact: usually 1 short paragraph or 3–5 bullets per section.
+  - Prefer one clear implementation path that follows existing codebase patterns; do not enumerate broad alternatives.
+  - Do not add standalone clarification gates, review gates, plan_review, or expanded architecture sections.
+  - If the plan needs more than 3 critical files, a new abstraction, data migration, public API change, or unresolved scope/security/data correctness decision, stop and return a tier reassessment recommendation to `plan`.
+
   **COMPREHENSIVE additionally requires:**
   8. **Current State** — How the affected code path works today, with file:line refs. Anchored to research findings.
   9. **Implementation Phases** — Ordered phases, each with its own Verification subsection (Phase N succeeds when …). Phases must be sequenced by dependency, not by file. Migration phases come before consumer phases.
@@ -125,14 +135,28 @@ Dynamically generate up to 10 technical questions based on research findings. **
 
 - **Action** — RequestReview:
 
-  > "Implementation plan saved to `{path}`. Review and reply with feedback or 'Approved' to proceed."
+  - **If `--no-review` is present**:
+
+    > "Draft implementation plan saved to `{path}`. Returning to `plan` for the next routed step."
+
+    Do NOT wait for user approval. Return control to the invoking `plan` workflow.
+
+  - **Else**:
 
-- **Wait** — User provides feedback or approval
+    > "Implementation plan saved to `{path}`. Review and reply with feedback or 'Approved' to proceed."
+
+- **Wait** — User provides feedback or approval, unless `--no-review` is present.
 
 ## Step (4/4) - Finalize and Present Next Steps
 
 - **Action** — ConfirmCompletion:
 
+  - **If `--no-review` is present**:
+
+    > "Draft implementation plan saved to `{plan_path}`. Returning to `plan`."
+
+    Stop here. Do not render the standalone Next Steps footer.
+
   > "🎯 Implementation Planning Complete. Documents: {plan_path}, task_context.md"
 
-- **Action** — RenderFooter: Use `@skill-spectre:spectre-guide` skill for Next Steps footer
+- **Action** — RenderFooter: Use `@skill-spectre:spectre-guide` skill for Next Steps footer

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

@@ -1,5 +1,5 @@
 ---
-name: create_tasks
+name: spectre-create_tasks
 description: 👻 | Transform requirements into executable tasks - primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: create_test_guide
+name: spectre-create_test_guide
 description: 👻 | Generate right-sized manual test guides - primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: evaluate
+name: spectre-evaluate
 description: "\ud83d\udc7b | Architecture review + knowledge capture"
 user-invocable: true
 ---
@@ -27,7 +27,7 @@ $ARGUMENTS
 
 This command runs two activities in parallel:
 
-1. **Architecture Review** — dispatched as a background Opus 4.6 subagent via `Skill(architecture_review)` (Claude slash route: `/spectre:architecture_review`)
+1. **Architecture Review** — dispatched as a background Opus 4.6 subagent via `Skill(spectre-architecture_review)` (Claude slash route: `/spectre:architecture_review`)
 2. **Learn** — run directly by loading the `spectre-learn` skill
 
 ## Step (1/2) - Dispatch Architecture Review
@@ -44,7 +44,7 @@ This command runs two activities in parallel:
 ## Step (2/2) - Capture Learnings
 
 - **Action** — Learn: Load the spectre-learn skill and follow its workflow
-  - Load skill: `Skill(learn)`
+  - Load skill: `Skill(spectre-learn)`
   - **If** ARGUMENTS is provided: use it as the learning topic
   - **If** ARGUMENTS is empty: the skill will analyze recent conversation to identify what's worth capturing
   - Follow the full learning workflow from the skill (categorize, propose, write, register)

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

@@ -1,5 +1,5 @@
 ---
-name: execute
+name: spectre-execute
 description: 👻 | Adaptive Wave-Based Build with Per-Wave Verification Gate
 user-invocable: true
 ---
@@ -118,7 +118,7 @@ $ARGUMENTS
 
 ## Step 2 - Cross-Wave Validate
 
-- **Action** — SpawnValidation: @analyst runs `Skill(validate)` (Claude slash route: `/spectre:validate`) with **narrowed scope**:
+- **Action** — SpawnValidation: @analyst runs `Skill(spectre-validate)` (Claude slash route: `/spectre:validate`) with **narrowed scope**:
   - Focus: cross-wave integration audit (did later waves silently break earlier waves' wiring?) + scope-creep audit (anything implemented that is NOT in the acceptance criteria?) + dead-computation sweep across the full cumulative diff
   - Skip: per-area wiring verification (already done per-wave in Step 1.3b's wiring lens)
 
@@ -126,7 +126,7 @@ $ARGUMENTS
 
 ## Step 3 - Prepare for QA
 
-- **Action** — GenerateTestGuide: @dev runs `Skill(create_test_guide)` (Claude slash route: `/spectre:create_test_guide`)
+- **Action** — GenerateTestGuide: @dev runs `Skill(spectre-create_test_guide)` (Claude slash route: `/spectre:create_test_guide`)
   - Save to `{OUT_DIR}/test_guide.md`
 
 ## Step 4 - Report

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

@@ -1,5 +1,5 @@
 ---
-name: fix
+name: spectre-fix
 description: Investigate bugs & implement fixes - primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: forget
+name: spectre-forget
 description: Clear session memory - archive all session files so next session starts fresh
 user-invocable: true
 ---

package/plugins/spectre/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
 ---

package/plugins/spectre/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/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
 ---

package/plugins/spectre/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`, `/spectre: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/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: `/spectre:create_plan` and `/spectre: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
 
@@ -187,6 +189,7 @@ Goal: align on the *shape* of the solution before generating a full plan. This c
 │                                                                        │
 │  ✅ 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:spectre-guide` skill for Next Steps