@codename_inc/spectre 3.7.0

package/plugins/spectre/commands/quick_dev.md

@@ -0,0 +1,101 @@
+---
+description: 👻 | Quickly scope, research, & plan s/m tasks - primary agent
+---
+
+# 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 `/spectre: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:spectre-guide` skill for Next Steps

package/plugins/spectre/commands/rebase.md

@@ -0,0 +1,73 @@
+---
+description: 👻 | Safe guided rebase w/conflict handling - primary agent
+---
+
+# 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:spectre-guide` skill for Next Steps

package/plugins/spectre/commands/recall.md

@@ -0,0 +1,5 @@
+# /recall - Search Project Knowledge
+
+Load the `spectre-recall` skill and follow its instructions.
+
+**Search query**: $ARGUMENTS

package/plugins/spectre/commands/research.md

@@ -0,0 +1,159 @@
+---
+description: 👻 | Research codebase with parallel agents - primary agent
+---
+
+# 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:spectre-guide` skill (contains format template and spectre command options)
+
+## Next Steps
+
+See `@skill-spectre: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/commands/scope.md

@@ -0,0 +1,119 @@
+---
+description: 👻 | Interactively scope a feature or improvement, generating a complete Scope document that clarifies what's IN and OUT -- primary agent
+---
+# scope: Interactive Feature Scoping
+
+Collaborative workflow for structuring unstructured thoughts into clear scope boundaries through contextual brainstorming and targeted clarifications. Focuses on user value and scope boundaries before technical considerations. Output: comprehensive scope document with clear boundaries, user value, and key decisions saved to `{OUT_DIR}/concepts/scope.md`.
+
+## ARGUMENTS
+
+<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
+
+## Step 1: Immediate Reply & Gather Context
+
+- **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 3**
+  - **Else If** ARGUMENTS empty → probe for context enthusiastically
+  - **Else** → proceed to Step 2
+  - **CRITICAL**: No tool calls except reading kickoff doc when FROM_KICKOFF=true
+
+## Step 2: Interactive Scope Exploration
+
+**SKIP IF FROM_KICKOFF=true**
+
+- **Action** — ExploreScope: Collaborative dialogue focused on boundaries and user experience.
+
+  **CRITICAL**: Focus on WHAT, not HOW. Defer all technical/implementation questions until scope boundaries are finalized. Only ask technical questions if the scope itself is inherently technical (e.g., "migrate database from X to Y").
+
+  **PATTERN**: Lead with a rich initial exploration. In your FIRST response, propose concrete hypotheses AND ask 5-8 questions across multiple dimensions. Give the user a full landscape to react to, not a single thread to follow.
+
+  **FIRST RESPONSE FORMAT**:
+
+  > Here's my initial read on this, plus questions to help us explore the bounds:
+  >
+  > **My hypothesis**: [problem statement, who it affects, proposed IN/OUT]
+  >
+  > **Questions to explore**:
+  > 1. [User problem question]
+  > 2. [UX flow question]
+  > 3. [Boundary edge question]
+  > 4. [Alternative approach question]
+  > 5. [Success criteria question]
+  > 6. [Edge case question]
+  > ...
+  >
+  > Answer any/all that spark thoughts. Skip what's obvious.
+
+  **Question types to include** (aim for 5-8 total, mix from these):
+
+  - **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**: What about [adjacent thing]—IN or OUT? If unlimited time, what else? What's essential for v1?
+  - **Alternatives**: I could see this as [A] or [B]. Which direction?
+  - **Edge cases**: What happens when [unusual situation]? Should we handle [error state]?
+  - **Success**: What makes you say "this shipped well"? What's the one thing we can't get wrong?
+
+  **DO NOT ask about**: implementation approach, technical trade-offs, architecture, or integration details until boundaries are confirmed.
+
+- **Action** — IterateBoundaries: After user responds, refine boundaries and ask targeted follow-ups on gaps.
+
+  > **Current Boundaries**: ✅ **IN**: \[list\] ❌ **OUT**: \[list\] ⚠️ **Unsure**: \[edge cases\]
+  >
+  > Any items to move? Add exclusions? Clarify edges? Reply 'looks good' to continue.
+
+- **Wait** — User confirms Scope boundaries are accurate
+
+## Step 3: Generate 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"`
+
+- **Action** — GenerateTargetedQuestions: Create 3-6 questions based ONLY on remaining scope ambiguities from Step 2 (or kickoff's "Remaining Ambiguities").
+
+  **CRITICAL**: Only ask about unresolved scope ambiguities. Technical questions (architecture, trade-offs, integration) belong in `/spectre:plan`, not here.
+
+- **Action** — SaveClarifications: Create `{OUT_DIR}/clarifications/scope_clarifications_{timestamp}.md`:
+
+  - Header: concept name, confirmed boundaries so far
+  - Questions: Each focused on a scope edge case with `<response></response>` block
+
+- **Action** — PromptUser: "Saved clarifications to `{path}`. Answer in `<response>` blocks. Reply 'Read it' when ready."
+
+- **Wait** — User replies
+
+- **Action** — ReadClarifications: Read file, use responses (proceed with assumptions if empty)
+
+## Step 4: Create Scope Document
+
+- **Action** — CreateScopeDoc: Generate `{OUT_DIR}/concepts/scope.md` (use scoped filename if exists).
+
+  **Priority**: User value and boundaries BEFORE technical details.
+
+  **Sections**: The Problem (pain, impact, current state) → Target Users (primary, secondary, needs) → Success Criteria (outcomes, metrics) → User Experience (journeys, principles, trade-offs) → Scope Boundaries (in/out/maybe/future) → Constraints (platform, perf, a11y, scale) → Integration (touches, avoids, dependencies) → Decisions (from clarifications + rationale) → Risks (UX, scope creep, open questions) → Next Steps (`/spectre:plan` or `/spectre:create_tasks`, complexity S/M/L)
+
+## Step 5: Light Technical Context (Optional)
+
+**Only if scope identifies specific technical/architecture integration points.**
+
+- **Action** — IdentifyTouchpoints: Identify desired areas of research, and dispatch parallel @analyst subagents to research each area. Surface-level only (component names, NOT implementation). List features this interacts with, constraints worth documenting, areas to avoid.
+
+- **Action** — UpdateScopeDoc: Add findings to Integration & Constraints sections if relevant.
+
+## 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\] ⚠️ **Maybe/Future**: \[from doc\]
+  >
+  > Docs saved: `{OUT_DIR}/concepts/scope.md`, `{OUT_DIR}/clarifications/scope_clarifications_{timestamp}.md`
+  >
+  > Reply with any edits, updates, or clarifications — otherwise pick a next step:
+
+- **Action** — RenderFooter: Render Next Steps using `@skill-spectre:spectre-guide` skill.
+
+  > **NOTE**: Do NOT wait for explicit approval. Present next steps immediately inline with the review. User can reply with scope edits OR jump straight into a next step command. If user replies with edits, apply them to the scope doc and re-present.

package/plugins/spectre/commands/ship.md

@@ -0,0 +1,172 @@
+---
+description: 👻 | Autonomous end-to-end: brain dump -> scope -> TDD -> commit -> rebase -> PR
+---
+# ship: Autonomous End-to-End Delivery
+
+Take a brain dump and autonomously produce a reviewable PR. Zero confirmation gates — scope, implement with TDD, sweep, rebase, and open a PR.
+
+**Execution Style**: Fully autonomous. No user approval gates. Parse intent, build it, ship the PR.
+
+## ARGUMENTS
+
+<ARGUMENTS> $ARGUMENTS </ARGUMENTS>
+
+## Step (1/8) - Parse Context
+
+- **Action** — ParseBrainDump: Extract from ARGUMENTS:
+  - `INTENT_TYPE`: `feat` or `fix` (infer from context — new behavior = feat, broken behavior = fix)
+  - `TARGET_BRANCH`: Extract if specified (e.g., "rebase onto develop"), default `origin/main`
+  - `SCOPE_SUMMARY`: 1-2 sentence distillation of what to build/fix
+  - `RELEVANT_FILES`: Any files, components, or areas mentioned
+  - `CONTEXT`: Remaining context, constraints, preferences
+- **Action** — ValidateInput:
+  - **If** ARGUMENTS empty → ask user for brain dump, then proceed autonomously
+  - **Else** → proceed
+
+## Step (2/8) - Ensure Worktree
+
+- **Action** — DetectBranch: `git rev-parse --abbrev-ref HEAD`
+  - **If** already in a worktree or on a non-main branch (not `main`, not `master`) → use current context, proceed
+  - **If** on `main` or `master` → use `EnterWorktree` to create an isolated worktree
+- **Action** — SetBranchName: Capture current branch name as `BRANCH_NAME` for artifact paths
+
+## Step (3/8) - Quick Scope
+
+- **Action** — DispatchResearch: Spawn parallel lightweight agents:
+
+  - `@spectre:finder` — Locate files related to `RELEVANT_FILES` and `SCOPE_SUMMARY`
+  - `@spectre:analyst` — Understand the relevant code area, key interfaces, existing patterns
+
+- **Action** — WriteScopeDoc: Create `docs/tasks/{BRANCH_NAME}/concepts/scope.md`:
+
+  ```markdown
+  # Scope: {SCOPE_SUMMARY}
+  
+  ## Objective
+  {1-2 sentences from brain dump}
+  
+  ## Type
+  {feat or fix}
+  
+  ## In Scope
+  - {bullet list of what will be done}
+  
+  ## Out of Scope
+  - {what this explicitly won't touch}
+  
+  ## Target Branch
+  {TARGET_BRANCH}
+  
+  ## Key Files
+  {from research — relevant files and their roles}
+  ```
+
+  Keep it \~20 lines. This is a lightweight scope, not full `/spectre:scope`.
+
+## Step (4/8) - Create Tasks
+
+- **Action** — CreateTasks: Use `TaskCreate` to create 3-8 tasks proportional to scope complexity.
+  - Each task gets: clear `subject` (imperative), `description` (what to do + acceptance criteria), `activeForm` (present continuous)
+  - Order tasks by dependency — foundational work first
+  - Tasks are ephemeral and operational — no file artifact needed
+
+## Step (5/8) - Execute with TDD
+
+- **Action** — ExecuteLoop: For each task sequentially:
+
+  1. `TaskUpdate` → `in_progress`
+  2. Load `@skill-spectre:spectre-tdd` for TDD methodology
+  3. Execute: RED (write failing test) → GREEN (minimal implementation) → REFACTOR (clean up)
+  4. Commit with conventional format: `{INTENT_TYPE}({scope}): {description}`
+  5. `TaskUpdate` → `completed`
+
+  **Rules**:
+
+  - One commit per task minimum
+  - Conventional commit format always
+  - TDD methodology for implementation tasks (skip for config/doc-only tasks)
+  - If a task reveals new work, create additional tasks rather than scope-creeping the current one
+
+## Step (6/8) - Sweep
+
+Inline sweep — same checklist as `/spectre:sweep`, no subagents:
+
+### 6.1 Diff Sanity Check
+
+- Review full diff for unintentional changes (whitespace-only edits, merge artifacts)
+- Verify no accidentally staged files outside the intended scope
+- Confirm no secrets, API keys, credentials, or sensitive data in diff
+
+### 6.2 Logging Audit
+
+- Remove temporary/debug logging (console.log, print, debug flags)
+- Preserve intentional logs: errors, critical warnings, key state transitions
+- Verify log levels are appropriate for production context
+
+### 6.3 Code Hygiene
+
+- Remove commented-out code (it's in git history if needed)
+- Resolve or document any TODO/FIXME/HACK introduced in this session
+- Remove hardcoded test values that should be config/env
+
+### 6.4 Opportunistic Dead Code Cleanup
+
+- Orphaned imports with no usage in the file
+- Unused variables or functions declared but never referenced
+- Debug artifacts (debugger statements, leftover TODO/FIXME from this work)
+
+### 6.5 Lint (Strict)
+
+- Run the project linter and **fix all violations** — no skipping, no eslint-disable
+- Address structural lint issues by refactoring, not suppressing
+
+### 6.6 Test
+
+- Run affected tests + full test suite
+- Fix any failures caused by the changes
+- Do NOT write new tests here — that was done in Step 5
+
+### 6.7 Commit Sweep Fixes
+
+- If sweep produced changes, commit: `chore({scope}): sweep cleanup`
+
+## Step (7/8) - Rebase
+
+- **Action** — FetchLatest: `git fetch origin`
+- **Action** — CreateSafetyRef: `git branch backup/ship-$(date +%Y%m%d-%H%M%S)`
+- **Action** — Rebase: `git rebase {TARGET_BRANCH}`
+  - **If** conflicts → resolve automatically, favoring target branch conventions
+  - Track resolution decisions for PR summary
+- **Action** — VerifyPostRebase:
+  - Run linter — fix violations
+  - Run full test suite — fix failures
+  - Confirm commit count and no unexpected changes
+
+## Step (8/8) - Create PR
+
+- **Action** — PushBranch: `git push -u origin {BRANCH_NAME}`
+
+- **Action** — CreatePR: `gh pr create` with:
+
+  **Title**: `{INTENT_TYPE}({scope}): {SCOPE_SUMMARY}` (under 70 chars)
+
+  **Body**:
+
+  ```markdown
+  ## Summary
+  {From scope doc — objective and what was done}
+  
+  ## Changes
+  {Bulleted list derived from completed tasks}
+  
+  ## Test Plan
+  {Bulleted checklist — what was tested, what to verify manually}
+  
+  Shipped autonomously via `/spectre:ship`
+  ```
+
+- **Action** — OutputPRUrl: Display the PR URL as the final deliverable
+
+## Next Steps
+
+Use `@skill-spectre:spectre-guide` skill to render the Next Steps footer.