@codename_inc/spectre 3.7.0 → 5.0.0

package/plugins/spectre-codex/skills/quick_dev/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: "quick_dev"
+description: "👻 | Quickly scope, research, & plan s/m tasks - primary agent"
+user-invocable: true
+---
+
+# quick_dev
+
+## Input Handling
+
+Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
+
+
+# quick_dev: Scope → Research → Plan for Small/Medium Tasks
+
+## Description
+- **What** — Lightweight workflow for bug fixes and small features: confirm scope, research via parallel agents, create implementation plan
+- **Outcome** — Validated scope, research synthesis, `quick_task_plan.md` with parent/sub-task structure
+
+## ARGUMENTS Input
+
+<ARGUMENTS>
+$ARGUMENTS
+</ARGUMENTS>
+
+## Step 1 - Gather Context
+
+- **Action** — ImmediateReply: Respond before running tools
+  - **If** ARGUMENTS has task context → proceed to Step 2
+  - **Else** → ask: "What are you trying to build or fix? Share any docs or context."
+  - **CRITICAL**: No tool calls here. No technical questions — research answers those.
+- **Wait** — Only if ARGUMENTS empty
+
+- **Action** — ReadFiles: Read any files mentioned by user completely (no limit/offset)
+
+## Step 2 - Confirm Scope (Functional Only)
+
+**Scope is about WHAT we're building, not HOW.** Technical approach comes from research.
+
+**DO NOT ask about**: implementation approach or technical decisions — research answers those.
+
+- **Action** — PresentScope:
+  > **📋 Scope Confirmation**
+  >
+  > **Objective**: {functional outcome}
+  >
+  > **✅ In Scope**: {what the feature does — behaviors, not implementation}
+  >
+  > **❌ Out of Scope**: {what we're NOT building}
+  >
+  > **UX Assumptions**: {how you imagine the user flow working}
+  >
+  > **Constraints**: {user-provided only}
+  >
+  > Any items to move between IN/OUT? Clarify UX flow? Reply with changes or 'Confirmed'.
+
+- **Wait** — User confirms or provides changes (apply and proceed)
+
+## Step 3 - Research
+
+- **Action** — SpawnAgents: Launch parallel research agents
+  - `@finder` — find WHERE files/components live
+  - `@analyst` — understand HOW code works
+  - `@patterns` — find similar implementations
+  - `@web-research` — external docs (only if user asks)
+  - **Wait** for ALL agents to complete
+
+- **Action** — Synthesize: Compile findings with file paths, patterns, architectural decisions
+
+## Step 4 - Clarify Ambiguities
+
+- **Action** — AskClarifyingQuestions: Use AskUserQuestion tool for 2-4 questions
+  - **Only ask** what research revealed needs user decision: UX preferences, behavioral trade-offs
+  - For multi-option questions: include Pros/Cons/Trade-offs
+  - **Never ask** scope questions (settled in Step 2) or technical questions answerable by code
+
+## Step 5 - Create Plan
+
+- **Action** — DetermineOutputDir:
+  - `OUT_DIR=docs/tasks/{branch_name}` (or user-specified)
+  - `mkdir -p "${OUT_DIR}/specs"`
+
+- **Action** — GeneratePlan: Create `{OUT_DIR}/specs/quick_task_plan.md` (use scoped name if exists)
+
+  **Plan Structure**:
+  1. Agreed Scope (Objective, In/Out of Scope, Constraints)
+  2. Research Summary (key codebase findings)
+  3. Approach Summary (strategy, integration points)
+  4. Implementation Tasks (see format below)
+  5. Success Criteria
+
+  **Task Format**: `## Phase` → `### [1.1] Parent Task` → `- [ ] **1.1.1** Sub-task` → `- [ ] Criterion`
+
+  **Sub-task guidance**:
+  - Start with action verb, use technical terms, name files/components
+  - Include: patterns, integration points, constraints
+  - Exclude: code snippets, line-by-line steps
+  - 2-3 acceptance criteria per sub-task
+
+  **Bounds**: ~3 phases, ~8 parent tasks max. If exceeds → suggest `create_tasks`
+
+- **Action** — ValidateCoverage: Verify all in-scope items have tasks; no out-of-scope tasks added
+
+## Step 6 - Document & Handoff
+
+- **Action** — PresentSummary:
+  > **Task Plan Created**: `{path}`
+  > ✅ Scope | ✅ Research | ✅ Plan
+
+- **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps

package/plugins/spectre-codex/skills/rebase/SKILL.md

@@ -0,0 +1,82 @@
+---
+name: "rebase"
+description: "👻 | Safe guided rebase w/conflict handling - primary agent"
+user-invocable: true
+---
+
+# rebase
+
+## Input Handling
+
+Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
+
+
+# rebase: Safe Git Rebase with Automatic Conflict Resolution
+
+## Description
+- **What** — Guide rebase with safety refs, automatic conflict resolution, test verification
+- **Outcome** — Successfully rebased branch with resolved conflicts, passing tests, smoketest guide
+
+## ARGUMENTS Input
+
+Optional target branch to rebase onto.
+
+<ARGUMENTS>
+$ARGUMENTS
+</ARGUMENTS>
+
+## Instructions
+- Auto-commit uncommitted changes (no confirmation)
+- Auto-resolve conflicts favoring target branch conventions (no prompts)
+- Track every resolution decision for summary
+- Actually run tests, don't just suggest
+
+## Step 1 - Confirm Target Branch
+
+- **Action** — CheckArguments:
+  - **If** ARGUMENTS has branch → proceed
+  - **Else** → ask: "What branch to rebase onto? (e.g., `origin/main`)"
+- **Wait** — If needed
+
+## Step 2 - Prepare
+
+- **Action** — EnsureCleanTree:
+  - **If** uncommitted changes → `git commit -am "chore: snapshot before rebase"`
+- **Action** — FetchLatest: `git fetch origin`
+- **Action** — CreateSafetyRef: `git branch backup/rebase-$(date +%Y%m%d-%H%M%S)`
+- **Action** — AssessComplexity: Light (≤5 commits), Moderate (5-20), Large (>20)
+
+## Step 3 - Execute Rebase
+
+- **Action** — StartRebase: `git rebase {target_branch}`
+  - **If** no conflicts → skip to Step 4
+
+- **Action** — ResolveAllConflicts: For each conflict:
+  1. Read conflict markers
+  2. Resolve (favor target branch patterns)
+  3. Track: `{file}: {decision} — {rationale}`
+  4. `git add {file}`
+  5. `git rebase --continue`
+  - Repeat until complete
+
+## Step 4 - Verify
+
+- **Action** — RunLint: Fix violations
+- **Action** — RunTestSuite: Detect command (npm test, pytest, cargo test, go test), run full suite
+- **Action** — ValidateRebase: Confirm commit count, no unexpected changes
+
+## Step 5 - Summary
+
+- **Action** — GenerateSummary:
+  > **Rebase Summary**
+  > - Branch: {current} → {target}
+  > - Commits: {count} | Conflicts: {count} | Tests: {PASS/FAIL}
+  >
+  > **Decisions**: | File | Decision | Rationale |
+  >
+  > **Smoketest Guide** (based on files touched):
+  > - {Feature Area}: [ ] {behavior to verify}
+  >
+  > **Safety**: Backup `{branch}` | Restore: `git reset --hard {backup}`
+
+- **Action** — RenderFooter: Use `Skill(spectre-guide)` skill for Next Steps

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

@@ -0,0 +1,17 @@
+---
+name: "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
+
+Load the `spectre-recall` skill and follow its instructions.
+
+**Search query**: $ARGUMENTS

package/plugins/spectre-codex/skills/research/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: "research"
+description: "👻 | Research codebase with parallel agents - primary agent"
+user-invocable: true
+---
+
+# research
+
+## Input Handling
+
+Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
+
+
+# research_codebase: Parallel Evidence-Based Codebase Analysis
+
+## Description
+- Description — Conduct comprehensive codebase research by spawning parallel specialized sub-agents and synthesizing their findings into structured documentation. Prioritizes direct readings of live code with specific file paths and line numbers. Supports follow-up questions with document updates.
+- Desired Outcome — Complete research document with YAML frontmatter, concrete evidence (file paths/line numbers), architectural insights, GitHub permalinks (when applicable), saved to `TASK_DIR/research/{topic}_{date}.md`, ready for task formalization or planning.
+
+## ARGUMENTS Input
+
+Optional user input to seed this workflow.
+
+<ARGUMENTS>
+$ARGUMENTS
+</ARGUMENTS>
+
+## Step (1/8) - Immediate Reply & Gather Context
+
+- **Action** — ImmediateReply: Respond immediately before running any commands or tools.
+  - Check for ARGUMENTS and extract research topic
+  - **If** ARGUMENTS exists → acknowledge topic; extract research question
+  - **Else** → prompt user: "I'm ready to research the codebase. Please provide your research question or area of interest, and I'll analyze it thoroughly by exploring relevant components and connections."
+  - **CRITICAL**: Do NOT run any tool calls in this step
+- **Wait** — User provides research query (if needed)
+
+## Step (2/8) - Read Mentioned Files
+
+- **Action** — ReadMentionedFiles: Read any directly mentioned files FULLY before decomposition.
+  - **If** user mentions specific files (tickets, docs, JSON) → read them FULLY using Read tool WITHOUT limit/offset
+  - **CRITICAL**: Read these files in main context before spawning sub-agents
+  - Ensures full context before decomposing research
+
+## Step (3/8) - Decompose & Plan Research
+
+- **Action** — AnalyzeQuestion: Break down research query into composable areas.
+  - Ultrathink about underlying patterns, connections, architectural implications user seeking
+  - Identify specific components, patterns, concepts to investigate
+  - Consider relevant directories, files, architectural patterns
+  - Create research plan using TodoWrite to track all subtasks
+- **Action** — SpawnSpecializedAgents: Launch parallel sub-agents for comprehensive research.
+  - **Codebase Research**:
+    - **finder**: Find WHERE files and components live
+    - **analyst**: Understand HOW specific code works
+    - **patterns**: Find examples of similar implementations
+  - **Web Research** (when task requires 3rd party frameworks/platforms/services/libraries/SDKs):
+    - **web-research**: External documentation and resources
+    - **IMPORTANT**: Instruct to return LINKS with findings; include links in final report
+  - **3rd Party Libraries** (only if user explicitly asks):
+    - Use Context 7 MCP tool to search external documentation
+  - **Linear Tickets** (if relevant):
+    - **linear-ticket-reader**: Get full details of specific ticket
+    - **linear-searcher**: Find related tickets or historical context
+  - **Agent Strategy**: Start with locator → use analyzer on promising findings → run multiple agents in parallel for different searches; each agent knows its job (tell what you're looking for, not how to search)
+
+## Step (4/8) - Synthesize Findings
+
+- **Action** — WaitForAgents: Wait for ALL sub-agent tasks to complete before proceeding.
+- **Action** — CompileResults: Synthesize all sub-agent results into coherent findings.
+  - Prioritize live codebase findings as primary source of truth
+  - Connect findings across different components
+  - Include specific file paths and line numbers for reference
+  - Highlight patterns, connections, architectural decisions
+  - Answer user's specific questions with concrete evidence
+- **Action** — GatherMetadata: Collect document metadata for YAML frontmatter.
+  - Current date/time with timezone (ISO format)
+  - Current commit hash (`git rev-parse HEAD`)
+  - Current branch name (`git rev-parse --abbrev-ref HEAD`)
+  - Repository name
+
+## Step (5/8) - Generate Research Document
+
+- **Output Location** — DetermineOutputDir: Decide where to save artifacts for this workflow.
+  - `branch_name=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)`
+  - **If** user specifies `target_dir/path` → `OUT_DIR={that value}`
+  - **Else** → `OUT_DIR=docs/tasks/{branch_name}`
+  - `mkdir -p "OUT_DIR/research"`
+- **Action** — CreateDocument: Structure research document with YAML frontmatter and comprehensive findings.
+  - **Frontmatter** (YAML at top):
+    - date: [ISO format with timezone]
+    - git_commit: [commit hash]
+    - branch: [branch name]
+    - repository: [repo name]
+    - topic: "[User's Question/Topic]"
+    - tags: [research, codebase, relevant-component-names]
+    - status: complete
+    - last_updated: [YYYY-MM-DD]
+    - last_updated_by: [Researcher name]
+  - **Document Sections** (in order):
+    1. Title: `# Research: [User's Question/Topic]`
+    2. Metadata header (Date, Git Commit, Branch, Repository)
+    3. Research Question (original user query)
+    4. Summary (high-level findings answering question)
+    5. Detailed Findings (by Component/Area with file:line references)
+    6. Code References (path/to/file:line with descriptions)
+    7. Architecture Insights (patterns, conventions, design decisions)
+    8. Related Research (links to other research docs in `docs/` (look for /research directories))
+    9. Open Questions (areas needing further investigation)
+
+## Step (6/8) - Add Permalinks & Save
+
+- **Action** — AddGitHubPermalinks: Generate GitHub permalinks if applicable.
+  - Check if on main branch or commit pushed: `git branch --show-current` and `git status`
+  - **If** on main/master OR pushed → generate permalinks:
+    - Get repo info: `gh repo view --json owner,name`
+    - Create: `https://github.com/{owner}/{repo}/blob/{commit}/{file}#L{line}`
+    - Replace local file references with permalinks in document
+  - **Else** → keep local file references
+- **Action** — SaveDocument: Save research document to standardized location under `{OUT_DIR}/research/`.
+  - Filename: `{research_topic}_{MMDDYY}.md`
+  - Path: `{OUT_DIR}/research/{filename}`
+- **Action** — PresentFindings: Present concise summary to user.
+  - Concise summary of key findings
+  - Include key file references for easy navigation
+  - Ask if they have follow-up questions or need clarification
+
+## Step (7/8) - Handle Follow-ups & Handoff
+
+- **Action** — HandleFollowUps: If user has follow-up questions, update same document.
+  - **If** follow-up questions asked:
+    - Update frontmatter: `last_updated`, `last_updated_by`, add `last_updated_note: "Added follow-up research for [brief description]"`
+    - Add new section: `## Follow-up Research [timestamp]`
+    - Spawn new sub-agents as needed for additional investigation
+    - Continue updating document
+ - **Else** → proceed to handoff
+- **Action** — RenderFooter: Render Next Steps footer using `Skill(spectre-guide)` skill (contains format template and spectre command options)
+
+## Next Steps
+
+See `Skill(spectre-guide)` skill for footer format and command options.
+
+## Success Criteria
+
+- [ ] Immediate reply sent; research topic requested (Step 1 - no tool calls)
+- [ ] User research query received
+- [ ] Output directory determined inline (`OUT_DIR`) using branch name or user-specified path
+- [ ] Directly mentioned files read FULLY in main context before decomposition
+- [ ] Research question decomposed into composable areas with ultra-thinking about patterns/connections
+- [ ] Research plan created using TodoWrite to track subtasks
+- [ ] Specialized sub-agents spawned in parallel (finder, analyst, patterns, web-research as needed, linear agents if relevant)
+- [ ] Agent strategy followed (locator → analyzer → parallel execution)
+- [ ] Web research agents instructed to return LINKS (if used)
+- [ ] ALL sub-agents completed before synthesis
+- [ ] Findings compiled with live codebase prioritized as source of truth
+- [ ] Results include specific file paths and line numbers
+- [ ] Cross-component connections and patterns highlighted
+- [ ] Concrete evidence provided for user's questions
+- [ ] Metadata gathered for frontmatter (date/time ISO, commit hash, branch, repo name)
+- [ ] Research document created with YAML frontmatter at top
+- [ ] Frontmatter fields consistent (snake_case for multi-word: git_commit, last_updated)
+- [ ] Document includes all 9 required sections in order
+- [ ] GitHub permalinks generated if on main/master or pushed commit
+- [ ] Local file references replaced with permalinks (when applicable)
+- [ ] Document saved to `{OUT_DIR}/research/{topic}_{MMDDYY}.md`
+- [ ] Concise findings summary presented to user with key file references
+- [ ] Follow-up questions handled with document updates (frontmatter updated, new section added)
+ 
+- [ ] Next steps guide read and relevant options sourced for footer

package/plugins/spectre-codex/skills/scope/SKILL.md

@@ -0,0 +1,174 @@
+---
+name: "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
+---
+
+# scope
+
+## Input Handling
+
+Treat the current command arguments as this workflow's input. When invoked from a slash command, use the forwarded `$ARGUMENTS` value.
+
+# scope: Interactive Feature Scoping
+
+Collaborative workflow for structuring unstructured thoughts into clear scope boundaries through a grounded hypothesis and targeted clarifications. Focuses on user value and scope boundaries before technical considerations. Output: scope document with clear boundaries (IN / OUT / ANTI-SCOPE), user value, load-bearing assumptions, and key decisions saved to `{OUT_DIR}/concepts/scope.md`.
+
+## ARGUMENTS
+
+<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
+
+## Step 1: Immediate Reply & Context Pickup
+
+- **Action** — ImmediateReply: Respond before any tools.
+  - **If** `FROM_KICKOFF=true` → acknowledge kickoff context, read `KICKOFF_DOC`, extract (Core Problem, User Value, Decisions Made, Remaining Ambiguities, Key Code Refs), **SKIP to Step 4**
+  - **Else If** ARGUMENTS empty → probe for context enthusiastically and **WAIT** for user
+  - **Else** → proceed with the steps below
+  - **CRITICAL**: No tool calls in this step except reading the kickoff doc when `FROM_KICKOFF=true`.
+
+- **Action** — DetectExistingArtifacts: Before proposing a hypothesis, check for prior context that may already answer questions.
+  - `branch_name=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)`
+  - Look for: `docs/tasks/{branch_name}/concepts/scope.md`, `docs/tasks/{branch_name}/task_context.md`
+  - **If** prior `scope.md` exists → read fully; treat this invocation as a re-scope. Surface what was already settled and ask only about what's new or changed.
+  - **If** captured project knowledge is available (via `apply`-style memory or session logs) → surface decisions/patterns/gotchas relevant to this area before asking the user.
+
+## Step 2: Ground the Hypothesis (Fast)
+
+**SKIP IF FROM_KICKOFF=true** — kickoff already grounded.
+
+- **Action** — FastGround: Run ONE fast lookup to ground the hypothesis in repo reality. Pick the most informative single call:
+  - **`@finder` for one targeted query** — when you need to know what files/components exist for this area
+  - **One `grep` or `glob`** — when you need to verify a specific assumption ("does X already exist?")
+
+  **Constraints**:
+  - **One call only.** This is grounding, not research. Tech research is `plan`'s job.
+  - **Fast.** If the call would take more than a few seconds, skip it and ask the user instead.
+  - If you need more than one signal, that's a sign this should be a `kickoff` rather than a `scope`.
+
+## Step 3: Interactive Scope Exploration
+
+**SKIP IF FROM_KICKOFF=true**
+
+- **Action** — ExploreScope: Collaborative dialogue focused on boundaries, user experience, and anti-scope.
+
+  **CRITICAL**: Focus on WHAT, not HOW. Defer all technical/implementation questions to `plan`. Only ask technical questions if the scope itself is inherently technical (e.g., "migrate database from X to Y").
+
+  **PATTERN**: Lead with a grounded hypothesis (informed by Step 2's lookup) AND ask 5–8 questions across multiple dimensions. Mark each question as **(blocking)** or *(optional)* so the user can skim and skip.
+
+  **FIRST RESPONSE FORMAT**:
+
+  > Here's my read on this, grounded in {one-line of what Step 2 surfaced}:
+  >
+  > **Hypothesis**: [problem statement, who it affects, proposed IN / OUT / ANTI-SCOPE]
+  >
+  > **Questions**:
+  > 1. **(blocking)** [User problem question]
+  > 2. **(blocking)** [Boundary edge question]
+  > 3. **(blocking)** [Anti-scope question]
+  > 4. *(optional)* [UX flow question]
+  > 5. *(optional)* [Alternative approach question]
+  > 6. *(optional)* [Edge case question]
+  > 7. *(optional)* [Success criteria question]
+  >
+  > Answer the blocking ones; skip optional if obvious.
+
+  **Question types** (mix from these; lean on blocking for boundaries and anti-scope):
+
+  - **User & Problem**: Who feels this most? What triggers the need? What's the cost of not solving it?
+  - **UX & Feel**: Should this feel fast or thorough? Guided or flexible? What's the ideal flow?
+  - **Boundaries (IN/OUT)**: What about [adjacent thing]—IN or OUT? What's essential for v1?
+  - **Anti-Scope**: What problem are we *intentionally not solving* here? (Different from OUT — anti-scope clarifies the philosophical edge of the feature, not just deferred work.)
+  - **Alternatives**: I could see this as [A] or [B]. Which direction?
+  - **Edge cases**: What happens when [unusual situation]?
+  - **Success**: What makes you say "this shipped well"?
+
+  **DO NOT ask about**: implementation approach, technical trade-offs, architecture, or integration details — those belong in `plan`.
+
+- **Action** — IterateBoundaries: After user responds, refine boundaries and ask targeted follow-ups on gaps.
+
+  > **Current Scope**:
+  > ✅ **IN**: [list]
+  > ❌ **OUT**: [list]
+  > 🚫 **ANTI-SCOPE**: [problems we're intentionally not solving]
+  > ⚠️ **Unsure**: [edge cases]
+  >
+  > Any items to move? Add exclusions? Clarify edges? Reply 'looks good' to continue.
+
+- **Wait** — User confirms scope boundaries are accurate.
+
+## Step 4: Targeted Clarifications
+
+- **Action** — DetermineOutputDir:
+  - **If** FROM_KICKOFF → use same dir as kickoff doc
+  - **Else** → `OUT_DIR = user_specified || docs/tasks/{branch_name}`
+  - `mkdir -p "$OUT_DIR/concepts" "$OUT_DIR/clarifications"`
+
+- **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)
+
+### Path A: Inline Clarifications (AskUserQuestion available)
+
+- **Action** — AskInline: Generate 3–6 questions based ONLY on remaining scope ambiguities from Step 3 (or kickoff's "Remaining Ambiguities").
+  - Ask the most critical first (up to 4 at a time, the tool limit).
+  - For trade-off decisions, present options with concise pros/cons.
+  - If more than 4 questions, ask in batches — most important first.
+
+  **CRITICAL**: Only ask about unresolved scope ambiguities. Technical questions belong in `plan`, not here.
+
+### Path B: File-Based Clarifications (no AskUserQuestion)
+
+- **Action** — GenerateTargetedQuestions: Create 3–6 questions in `{OUT_DIR}/clarifications/scope_clarifications_{YYYY-MM-DD_HHMMSS}.md`:
+  - Header: concept name, confirmed boundaries so far
+  - Each question with a `<response></response>` block
+
+- **Action** — PromptUser: "Saved clarifications to `{path}`. Answer in `<response>` blocks. Reply 'Read it' when ready."
+
+- **Wait** — User replies.
+
+- **Action** — ReadClarifications: Read the file; use responses (proceed with intelligent assumptions if blocks are empty).
+
+## Step 5: Create Scope Document
+
+- **Action** — CreateScopeDoc: Generate `{OUT_DIR}/concepts/scope.md` (use scoped filename if one exists).
+
+  **Priority**: User value and boundaries BEFORE technical details.
+
+  **Sections**:
+
+  1. **The Problem** — pain, impact, current state
+  2. **Target Users** — primary, secondary, needs
+  3. **Success Criteria** — outcomes; prefer measurable assertions over prose
+  4. **User Experience** — journeys, principles, trade-offs
+  5. **Scope Boundaries** — IN / OUT / ANTI-SCOPE / Maybe / Future
+  6. **Load-Bearing Assumptions** — assumptions that, if wrong, invalidate this scope. Each assumption gets a short *"if this is false, …"* consequence so future-you can recognize when to come back.
+  7. **Constraints** — platform, perf, a11y, scale (user-provided only)
+  8. **Decisions** — from clarifications + rationale
+  9. **Risks** — UX, scope creep, open questions
+  10. **Next Steps** — `plan` or `create_tasks`, complexity S/M/L
+
+  **Note on ANTI-SCOPE vs OUT**:
+  - **OUT** = we're not building it (yet, or for this release).
+  - **ANTI-SCOPE** = we're intentionally not solving this *problem* — it clarifies the philosophical edge of what this feature is for.
+
+## Step 6: Final Review & Next Steps
+
+- **Action** — PresentDocForReview: Show final boundaries and next steps together.
+
+  > **Scope Complete**: `{OUT_DIR}/concepts/scope.md`
+  >
+  > **Final Boundaries**:
+  > ✅ **IN**: [from doc]
+  > ❌ **OUT**: [from doc]
+  > 🚫 **ANTI-SCOPE**: [from doc]
+  > ⚠️ **Maybe/Future**: [from doc]
+  >
+  > **Load-Bearing Assumptions** (top 1–3 — if any prove false, return to scope): [from doc]
+  >
+  > Docs saved: `{OUT_DIR}/concepts/scope.md`, clarifications under `{OUT_DIR}/clarifications/`
+  >
+  > Reply with edits — otherwise pick a next step:
+
+- **Action** — RenderFooter: Render Next Steps using `Skill(spectre-guide)` skill.
+
+  > **NOTE**: Do NOT wait for explicit approval. Present next steps inline with the review. The user can reply with scope edits OR jump straight into a next step command. If they reply with edits, apply them to the scope doc and re-present.