@codename_inc/spectre 5.2.1 → 5.3.0

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

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

@@ -1,5 +1,5 @@
 ---
-name: prototype
+name: spectre-prototype
 description: 👻 | Generate a self-contained HTML prototype to validate a feature visually before planning - primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: quick_dev
+name: spectre-quick_dev
 description: 👻 | Quickly scope, research, & plan s/m tasks - primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: rebase
+name: spectre-rebase
 description: 👻 | Safe guided rebase w/conflict handling - primary agent
 user-invocable: true
 ---

package/plugins/spectre/skills/spectre-recall/SKILL.md

@@ -0,0 +1,22 @@
+---
+name: spectre-recall
+description: "👻 | Search Project Knowledge"
+user-invocable: true
+---
+
+# recall
+
+## Input Handling
+
+Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
+
+# /recall - Search Project Knowledge
+
+Read the project knowledge recall skill directly, then follow its instructions for the query below:
+
+- Claude Code path: `{{project_root}}/.claude/skills/spectre-recall/SKILL.md`
+- Codex path: `{{project_root}}/.agents/skills/spectre-recall/SKILL.md`
+
+If neither file exists, report that no project knowledge registry exists yet and suggest `/spectre:learn` after the current work produces something worth preserving.
+
+**Search query**: $ARGUMENTS

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

@@ -1,5 +1,5 @@
 ---
-name: research
+name: spectre-research
 description: 👻 | Research codebase with parallel agents - primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: scope
+name: spectre-scope
 description: 👻 | Interactively scope a feature or improvement, generating a complete Scope document with IN, OUT, and ANTI-SCOPE boundaries -- primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: ship
+name: spectre-ship
 description: 👻 | Autonomous end-to-end: brain dump -> scope -> TDD -> commit -> rebase -> PR
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: sweep
+name: spectre-sweep
 description: 👻 | Light pass cleanup - clean, lint, test, commit
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: tdd
+name: spectre-tdd
 description: "Load this skill when executing TDD (Test-Driven Development) methodology. Use when implementing features via strict RED-GREEN-REFACTOR cycles, or when a prompt instructs execution via TDD."
 ---
 

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

@@ -1,5 +1,5 @@
 ---
-name: test
+name: spectre-test
 description: 👻 | Risk-aware test coverage & commit - primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: ux
+name: spectre-ux
 description: 👻 | Define user flows, components, and UX behavior — generates the UX spec for a feature - primary agent
 user-invocable: true
 ---

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

@@ -1,5 +1,5 @@
 ---
-name: validate
+name: spectre-validate
 description: 👻 | Comprehensive post implementation requirement validation using subagents
 user-invocable: true
 ---

package/plugins/spectre-codex/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-codex/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-codex/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}}/.agents/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-codex/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-codex/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-codex/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-codex/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-guide)` skill for Next Steps footer
+- **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps footer

package/plugins/spectre-codex/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-codex/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-codex/skills/{evaluate → spectre-evaluate}/SKILL.md

@@ -1,5 +1,5 @@
 ---
-name: "evaluate"
+name: "spectre-evaluate"
 description: "👻 | 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: `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-codex/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: `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: `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-codex/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-codex/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
 ---