@codename_inc/spectre 3.7.0

package/plugins/spectre/commands/create_tasks.md

@@ -0,0 +1,374 @@
+---
+description: 👻 | Transform requirements into executable tasks - primary agent
+---
+
+# create_tasks: Unified Task Breakdown
+
+## Description
+- Transform requirements into detailed, actionable task lists with dependency analysis and execution options.
+- Adapts to available context: uses existing research when sufficient, conducts research when needed.
+- Outputs both sequential and parallel execution strategies.
+- Scales naturally: generates as many phases and tasks as the scope requires.
+
+## ARGUMENTS Input
+
+<ARGUMENTS>
+$ARGUMENTS
+</ARGUMENTS>
+
+---
+
+## Step 1 - Establish Context
+
+### 1a. Determine Output Location
+- `branch_name=$(git rev-parse --abbrev-ref HEAD 2>/dev/null || echo unknown)`
+- **If** user specifies path → `TASK_DIR={that value}`
+- **Else** → `TASK_DIR=docs/tasks/{branch_name}`
+- Ensure dirs exist: `mkdir -p "${TASK_DIR}/specs" "${TASK_DIR}/research" "${TASK_DIR}/clarifications"`
+
+### 1b. Scan Available Artifacts
+Inventory what exists in `TASK_DIR/`:
+- [ ] `task_summary.md` — scope/objectives
+- [ ] `prd.md` — detailed requirements
+- [ ] `ux.md` — user experience specs
+- [ ] `plan.md` — technical approach
+- [ ] `task_context.md` — technical research
+- [ ] `research/*.md` — analysis docs
+
+Also note: thread context, user-provided docs, ARGUMENTS content.
+
+### 1c. Assess Complexity
+**Simple task** (research likely unnecessary):
+- Single file/component change
+- Clear pattern already exists in codebase
+- Scope explicitly stated, no ambiguity
+
+**Complex task** (research likely needed):
+- Multi-component or cross-cutting
+- New patterns or integrations
+- Unclear technical approach
+
+---
+
+## Step 2 - Research Decision
+
+### 2a. Do We NEED Research?
+Based on complexity assessment from 1c:
+- **If** simple task with clear scope → `NEED_RESEARCH=false`
+- **If** complex task or unclear approach → `NEED_RESEARCH=true`
+
+### 2b. Do We HAVE Research? (if NEED_RESEARCH=true)
+Assess existing artifacts with judgment:
+
+| Artifact | Check For |
+|----------|-----------|
+| `task_context.md` | "## Technical Research" section with relevant analysis |
+| `research/*.md` | Docs covering codebase patterns, integration points |
+| `plan.md` | Technical approach, file locations, architecture decisions |
+
+**Judgment call**: Do existing artifacts sufficiently cover:
+- Codebase patterns relevant to this scope?
+- Integration points and dependencies?
+- Technical approach and target files?
+
+- **If** sufficient coverage → `HAVE_RESEARCH=true`
+- **If** gaps exist → `HAVE_RESEARCH=false` (note specific gaps)
+
+### 2c. Action
+- **If** `NEED_RESEARCH=false` → proceed to Step 3
+- **If** `NEED_RESEARCH=true` AND `HAVE_RESEARCH=true` → read existing, proceed to Step 3
+- **If** `NEED_RESEARCH=true` AND `HAVE_RESEARCH=false` → conduct research (Step 2d)
+
+### 2d. Conduct Research (conditional)
+- Spawn parallel agents: @codebase-locator, @codebase-analyzer, @codebase-pattern-finder
+- Review: `CLAUDE.md`, `README.md`, architecture docs
+- Identify: patterns, integration points, technical constraints
+- Save to `${TASK_DIR}/task_context.md` under "## Technical Research"
+
+---
+
+## Step 3 - Extract Requirements
+
+### 3a. Gather From All Sources
+Read completely (no limits):
+- Planning docs: `task_summary.md`, `prd.md`, `plan.md`, `ux.md`
+- Thread context: discussed requirements, user goals
+- ARGUMENTS: any provided scope
+
+### 3b. Synthesize Requirements
+- Extract: what must be built, who uses it, success criteria
+- Extract: out of scope, constraints, boundaries
+- Number each: REQ-001, REQ-002, etc.
+- Categorize: Core functionality, UX, Technical constraints
+
+### 3c. Requirements Boundary Check
+- [ ] Clear on what IS explicitly requested?
+- [ ] Clear on what is NOT mentioned (exclude)?
+- [ ] **Scope Litmus Test**: Would user recognize this as exactly what they asked?
+
+**STRICT COMPLIANCE**: Tasks deliver ONLY what's explicitly stated. No performance optimizations, extra features, future-proofing, or "best practices" unless requested.
+
+---
+
+## Step 4 - Generate Tasks
+
+### 4a. Synthesize Architecture Context
+- **Action** — SynthesizeArchitectureContext: Based on research findings, document where this work fits and how we'll approach it.
+  - **Where This Fits**: Which system/component this extends, how it connects to existing architecture (with file references)
+  - **Technical Approach**: Key pattern we're following, why this approach vs alternatives, what existing code we're leveraging
+  - **Key Decisions**: Important technical decisions made and their rationale
+  - This section helps the user understand how the work integrates with the product before diving into tasks
+
+### Task Hierarchy (4 Levels)
+- **📦 Phase**: Organizational header (no checkbox) — groups related parent tasks
+- **📋 Parent Task**: Cohesive deliverable (small-medium scope) — one component/file
+- **✓ Sub-task**: Atomic work (single focused change) — single action, 2-3 acceptance criteria
+- **✓ Acceptance Criteria**: Verifiable outcomes (not implementation steps)
+
+**Numbering**: Phase 1 → Parent 1.1, 1.2 → Sub-tasks 1.1.1, 1.1.2 → Criteria ✓
+
+### Integration-Aware Task Principle
+
+> **"A feature isn't done when pieces exist. It's done when data flows from user action to rendered pixels."**
+
+Every task that creates something must specify:
+1. **What it produces** — exact output (variable, return value, prop, event)
+2. **What consumes it** — exact consumer (component, hook, handler) that uses the output
+3. **What it replaces** — old code path being deprecated (if any)
+
+Tasks without consumers are incomplete. Tasks that don't address old code paths leave dead/duplicate logic.
+
+**Task Types**:
+- **Build tasks**: Create a component/hook/utility/function
+- **Integration tasks**: Wire producer output to consumer input (MANDATORY for every build task)
+- **Cleanup tasks**: Remove/redirect old code paths (MANDATORY when replacing patterns)
+
+### 4b. Create Parent Tasks
+- **Action** — CreateParentTasks: Draft as many phases as needed to logically organize work, each with as many parent tasks (📋) as required to cover complete scope.
+  - Each parent task = single cohesive deliverable (small-medium scope)
+  - Cover ALL extracted requirements with no gaps
+  - Group related work into phases for clarity
+  - Align with technical approach (from research or existing docs)
+
+### 4c. Break Down Sub-tasks
+- **Action** — BreakdownSubTasks: For each parent, generate as many detailed sub-tasks as needed to complete the parent.
+  - **Sub-task structure**:
+    - Start with action verb (Create, Implement, Add, Update, Configure, Enable)
+    - Use technical language freely (components, endpoints, middleware, hooks, schemas)
+    - Specify technical patterns and architecture decisions
+    - Name specific files, components, or modules when helpful
+    - Describe technical behavior and integration points
+    - Be specific enough for junior dev to know where to start
+    - Completable as a single focused change
+
+  - **What to INCLUDE in sub-tasks:**
+    - ✅ Technical terms (JWT, REST, WebSocket, React hooks, SQL queries)
+    - ✅ Architecture patterns (middleware, pub/sub, observer, factory)
+    - ✅ Integration points (which components connect, API contracts)
+    - ✅ File/component names (UserProfileComponent, authMiddleware.ts)
+    - ✅ Technical constraints (max file size, timeout duration, data format)
+    - ✅ **Produces**: What output this creates (variable name, return value, prop)
+    - ✅ **Consumed by**: What uses this output (component, hook, render path)
+    - ✅ **Replaces**: What old code path this supersedes (if any)
+
+  - **What to AVOID in sub-tasks:**
+    - ❌ Code snippets or pseudo-code
+    - ❌ Exact function signatures or variable names
+    - ❌ Line-by-line implementation steps
+    - ❌ Specific library API calls (unless architecturally significant)
+
+  - **Acceptance criteria**:
+    - Describe technical behaviors and observable outcomes
+    - Include integration expectations and error handling
+    - 2-3 verifiable outcomes per sub-task
+    - Be specific about technical requirements
+
+  - **Decomposition**: Split if 5+ criteria or multiple concerns
+
+### 4d. Validate Task Structure
+- **Action** — VerifyCoverage: Cross-reference tasks against extracted requirements.
+  - Map each requirement from Step 3 to at least one task
+  - Flag any uncovered requirements → add missing tasks
+  - Flag any tasks without requirement justification → remove or justify
+
+- **Action** — ValidateTasks: Validate complete task structure.
+  - **Coverage Validation**:
+    - [ ] All extracted requirements from Step 3 addressed by tasks?
+    - [ ] No gaps in requirement coverage?
+  - **Exclusion Validation**:
+    - [ ] Adding anything beyond explicit requests?
+    - [ ] Avoiding "nice-to-have" additions not requested?
+  - **Structure Validation**:
+    - [ ] Parent tasks are small-medium scope, sub-tasks are atomic?
+    - [ ] Each sub-task has 2-3 acceptance criteria?
+    - [ ] Acceptance criteria verifiable (not implementation steps)?
+
+- **Action** — ValidateIntegration: Verify every build task is wired to consumers.
+  - **Consumer Specified**:
+    - [ ] Does every "create X" task specify what consumes X?
+    - [ ] No orphaned computations (values produced but never used)?
+  - **Integration Explicit**:
+    - [ ] Is there a task for wiring producer output → consumer input?
+    - [ ] For UI features: is there a task verifying data reaches the render path?
+  - **Old Paths Addressed**:
+    - [ ] If replacing old code, is removal/redirect a task?
+    - [ ] No duplicate data sources for the same concern?
+  - **Last Mile Covered**:
+    - [ ] For every feature affecting what users SEE: task exists to wire to JSX render?
+
+---
+
+## Step 5 - Dependency Analysis & Execution Strategies
+
+### 5a. Map Dependencies
+- Review parent tasks (📋 level) for dependencies
+- Identify which parent tasks can be completed in parallel vs sequential
+- Dependency rules:
+  - Parent tasks requiring output from other parents must be sequenced
+  - Tasks modifying same files need sequencing or coordination
+  - Testing tasks run after implementation tasks
+  - Setup/configuration tasks complete before dependent work
+
+### 5b. Generate Sequential Execution Order
+Define step-by-step execution order based on dependencies:
+```markdown
+## Sequential Execution
+1. 1.1 - [Name] (no dependencies)
+2. 1.2 - [Name] (depends on 1.1)
+3. 2.1 - [Name] (depends on 1.1)
+4. 2.2 - [Name] (depends on 1.2, 2.1)
+...
+```
+
+### 5c. Generate Parallel Execution Waves
+Group independent parent tasks into waves for parallel execution:
+```markdown
+## Parallel Execution
+
+### Wave 1 (concurrent)
+- 1.1, 2.1 — no dependencies, can start immediately
+- Rationale: {why these can run concurrently}
+
+### Wave 2 (after Wave 1)
+- 1.2, 2.2 — depend on Wave 1 outputs
+- Rationale: {why these depend on Wave 1}
+
+### Wave 3 (after Wave 2)
+- 3.1 — integration, needs prior waves complete
+- Rationale: {why this needs prior waves}
+```
+
+**Note**: Phases (📦) are organizational; execution planning happens at parent task (📋) level.
+
+---
+
+## Step 6 - Document & Output
+
+### 6a. Write tasks.md
+- Determine `TASKS_FILE` (default `${TASK_DIR}/specs/tasks.md`; if it already exists, create a scoped name like `${TASK_DIR}/specs/{task_name}_tasks.md` or `tasks_{timestamp}.md` to avoid overwriting).
+Save to `${TASKS_FILE}`:
+
+```markdown
+# Tasks — {feature name}
+*Generated by create_tasks on {timestamp}*
+
+## Objective
+{single sentence describing outcome}
+
+## Scope
+- **In Scope**: {bullet list}
+- **Out of Scope**: {bullet list}
+
+## Requirements Traced
+| ID | Description | Source | Tasks |
+|----|-------------|--------|-------|
+| REQ-001 | ... | prd.md | 1.1, 1.2 |
+| REQ-002 | ... | task_summary.md | 2.1 |
+
+---
+
+## Architecture Context
+
+### Where This Fits
+- {Which system/component this work extends or modifies}
+- {How it connects to existing architecture — with file references}
+
+### Technical Approach
+- {Key pattern/approach we're following — reference existing code if applicable}
+- {Why this approach vs alternatives}
+- {What existing code we're leveraging}
+
+### Key Decisions
+- {Decision 1 and rationale}
+- {Decision 2 and rationale}
+
+---
+
+## Tasks
+
+### Phase 1: {Phase Name}
+
+#### [1.1] {Parent Task Title}
+- [ ] **1.1.1** {Sub-task with technical specifics}
+  - **Produces**: {output variable/value/prop}
+  - **Consumed by**: {component/hook that uses this}
+  - **Replaces**: {old code path, or "N/A" if new}
+  - [ ] {Technical outcome 1}
+  - [ ] {Technical outcome 2}
+  - [ ] {Technical outcome 3}
+
+- [ ] **1.1.2** {Sub-task with technical specifics}
+  - **Produces**: {output variable/value/prop}
+  - **Consumed by**: {component/hook that uses this}
+  - [ ] {Technical outcome 1}
+  - [ ] {Technical outcome 2}
+
+#### [1.2] {Parent Task Title} — Integration
+*This task wires outputs from 1.1 to consumers*
+- [ ] **1.2.1** {Wire X to Y}
+  - **Wires**: {1.1.1 output} → {consumer component/render}
+  - **Removes**: {old code path being replaced}
+  - [ ] {Consumer uses new data source}
+  - [ ] {Old data source removed/redirected}
+
+### Phase 2: {Phase Name}
+...
+
+---
+
+## Execution Strategies
+
+### Sequential Execution
+1. Task 1.1 - [Name] (no dependencies)
+2. Task 1.2 - [Name] (depends on 1.1)
+3. Task 2.1 - [Name] (depends on 1.1)
+...
+
+### Parallel Execution
+
+**Wave 1 (concurrent)**: 1.1, 2.1
+- Rationale: {why concurrent}
+
+**Wave 2 (after Wave 1)**: 1.2, 2.2
+- Rationale: {why sequenced}
+
+**Wave 3 (after Wave 2)**: 3.1
+- Rationale: {why sequenced}
+
+---
+
+## Coverage Summary
+- Total Requirements Extracted: [X]
+- Requirements with Task Coverage: [X] (100%)
+- Phases: [N]
+- Parent Tasks: [Y]
+- Sub-tasks: [Z]
+```
+
+### 6b. Present Summary
+
+- **Action** — SummarizeStructure: "Task Breakdown Complete. Structure: {X} phases, {Y} parents, {Z} sub-tasks. \[List phases with parent titles\]. Execution: Sequential ({N} steps) | Parallel ({M} waves). Saved to: {path}"
+
+### 6c. Next Steps Footer
+
+Action — RenderFooter: Use @skill-spectre:spectre-guide skill for Next Steps footer

package/plugins/spectre/commands/create_test_guide.md

@@ -0,0 +1,120 @@
+---
+description: 👻 | Generate right-sized manual test guides - primary agent
+---
+
+# create_test_guide: Right-sized manual testing documentation
+
+### Description
+- Description — Generate appropriately scoped manual testing guides that validate completed work, highlight key risks, and keep quality efforts aligned with tas scope. Scale complexity to match change size.
+- Desired Outcome — Feature-based testing guide with actionable checklists organized by user workflows, saved to `docs/tasks/{task_name}/testing/{task_name}_test_guide.md`.
+
+## ARGUMENTS Input
+
+Optional user input to seed this workflow.
+
+<ARGUMENTS>
+$ARGUMENTS
+</ARGUMENTS>
+
+## Step (1/3) - Analyze Context & Determine Testing Strategy
+
+- **Action** — AssessScope: Analyze current task to understand changes and determine complexity.
+  - Extract from task documentation: features/functionality added/modified/removed, technical stack/environment, user personas/use cases, integration points/dependencies
+  - Process ARGUMENTS for specific focus areas (if provided)
+  - **Change Complexity Assessment**:
+    - **Simple**: Basic smoke tests, happy path validation, quick regression check of related features
+    - **Medium**: Edge case testing, error handling validation, basic integration testing
+    - **Complex**: Advanced user scenarios, performance considerations, cross-feature interactions, security implications
+- **Action** — DetermineStrategy: Select required and optional sections based on complexity.
+  - **Required Sections (Always)**:
+    - Testing Overview (scope, environment, prerequisites)
+    - Environment Setup (step-by-step setup and verification)
+    - Core Test Cases (primary functionality validation)
+    - Results Documentation (how to record and report findings)
+  - **Optional Sections (Include Based on Relevance)**:
+    - Known Issues & Limitations (if documented bugs/workarounds)
+    - Rollback Procedures (high-risk changes/production deployments)
+    - Performance Testing (changes affecting load times/resource usage)
+    - Accessibility Testing (UI/UX changes)
+    - Cross-Browser/Device Testing (frontend changes)
+    - Data Validation Testing (changes affecting data handling)
+    - Security Testing (authentication/permissions/data access changes)
+
+## Step (2/3) - Generate Test Guide
+
+- **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/testing"`
+- **Action** — CreateGuide: Generate comprehensive testing guide with feature-based organization.
+  - Save to `{OUT_DIR}/testing/{branch_name}_test_guide.md`
+  - **Guiding Principles**:
+    - Scale appropriately (CSS color change ≠ payment system)
+    - Focus on risk (prioritize areas most likely to break or impact users)
+    - Be practical (completable in reasonable timeframe)
+    - Stay relevant (only include sections that add value)
+  - **Primary Structure**: Organize by user workflows/features (not procedural sections)
+  - **Feature-Based Format**:
+    ```markdown
+    ### 1. Feature Name (User Action/Context)
+    - [ ] Step 1: Action to perform
+    - [ ] Step 2: What to verify/expect
+    - [ ] Step 3: Additional validation
+    - [ ] Step 4: Edge case or error handling
+    ```
+  - **Content Standards**:
+    - **Complete Scenarios**: Structure around complete scenarios (user workflows or technical capabilities); each section validates specific capability end-to-end
+    - **Actionable Steps**: Each checkbox = complete action + verification pair (e.g., "Send POST to /api/users and verify 201 with user ID returned")
+    - **Logical Grouping**: Group related test steps under scenarios (e.g., all "API Rate Limiting" aspects in one section)
+    - **Appropriate Depth**: Scale complexity to match changes (simple UI updates need basic workflows; new features need comprehensive coverage)
+  - **Formatting Requirements**:
+    - Headers: Descriptive feature names explaining user goal
+    - Steps: Combine action and expected result in each checkbox
+    - Grouping: Organize related functionality under same feature section
+    - Checkboxes: Use `[ ]` for progress tracking
+    - Context: Include keyboard shortcuts, button names, UI elements in parentheses
+    - Examples: Provide specific test data (branch names, file paths)
+  - Write instructions clear enough for unfamiliar users; don't over-engineer for straightforward changes
+
+## Step (3/3) - Deliver
+
+- **Action** — PresentDelivery: Present guide with testing coverage summary.
+  > **📋 Test Guide Created**
+  >
+  > **Location**: `docs/tasks/{task_name}/testing/{task_name}_test_guide.md`
+  >
+  > **Coverage**:
+  > - {X} feature workflows/scenarios
+  > - {Y} total test steps
+  > - Estimated time: {Z} minutes
+  >
+  > **Testing Strategy**: {Simple/Medium/Complex} - {brief rationale}
+  >
+  > The guide is organized by user workflows with actionable checklists ready for execution.
+- **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
+
+- [ ] Output directory determined inline (`OUT_DIR`) using branch name or user-specified path
+- [ ] Task context analyzed (features changed, stack, personas, integration points)
+- [ ] ARGUMENTS processed for specific focus areas (if provided)
+- [ ] Change complexity assessed (Simple/Medium/Complex)
+- [ ] Testing strategy determined with required and optional sections identified
+- [ ] Test guide created with feature-based organization
+- [ ] Required sections included (Overview, Setup, Core Tests, Results)
+- [ ] Optional sections evaluated and included based on relevance
+- [ ] Tests organized by user workflows/features with descriptive headers
+- [ ] Steps combine actions with expected results using checklist format
+- [ ] Related functionality logically grouped under coherent scenarios
+- [ ] Keyboard shortcuts and UI elements included as relevant
+- [ ] Guide complexity scaled appropriately to change size
+- [ ] Instructions clear enough for unfamiliar users
+- [ ] Guide saved to `{OUT_DIR}/testing/{branch_name}_test_guide.md`
+ 
+- [ ] Testing coverage summary presented to user
+- [ ] Next steps guide read and relevant options sourced for footer

package/plugins/spectre/commands/evaluate.md

@@ -0,0 +1,50 @@
+---
+description: "\ud83d\udc7b | Architecture review + knowledge capture"
+---
+
+# evaluate: Review architecture and capture learnings
+
+## Description
+- **What** — Meta command that runs an architecture review in the background while you capture learnings from the session
+- **Outcome** — Architecture review report + captured knowledge for future sessions
+
+## ARGUMENTS
+
+<ARGUMENTS>
+$ARGUMENTS
+</ARGUMENTS>
+
+## Instructions
+
+This command runs two activities in parallel:
+
+1. **Architecture Review** — dispatched as a background Opus 4.6 subagent via `/spectre:architecture_review`
+2. **Learn** — run directly by loading the `spectre-learn` skill
+
+## Step (1/2) - Dispatch Architecture Review
+
+- **Action** — DispatchReview: Launch architecture review as a background subagent
+  - Use the Task tool with `subagent_type="general-purpose"`, `model="opus"`, `run_in_background=true`
+  - The subagent prompt should include the full architecture_review command instructions
+  - Pass ARGUMENTS to the subagent as the review scope (feature description, paths, context)
+  - **If** ARGUMENTS is empty: instruct the subagent to infer the review scope from recent work in the repository (e.g., git diff, recent commits)
+  - Note the background task ID so the user can check results later
+
+- **Output**: Inform the user that the architecture review is running in the background and they'll be notified when it completes.
+
+## Step (2/2) - Capture Learnings
+
+- **Action** — Learn: Load the spectre-learn skill and follow its workflow
+  - 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)
+
+## Completion
+
+When the learn flow completes:
+1. Check if the background architecture review has finished (read the output file)
+2. **If finished**: Present the architecture review report to the user
+3. **If still running**: Let the user know they can check back later or continue working
+
+- **Action** — RenderFooter: Use @skill-spectre:spectre-guide for Next Steps

package/plugins/spectre/commands/execute.md

@@ -0,0 +1,87 @@
+---
+description: 👻 | Adaptive Wave-Based Build -> Code_Review -> Validate Flow
+---
+
+# execute: Adaptive Task Execution with Quality Gates
+
+Execute tasks in parallel waves with full scope context, adapt based on learnings, code review loop, validate requirements. Outcome: complete implementation with verified quality and E2E requirement coverage.
+
+## ARGUMENTS
+
+<ARGUMENTS>
+$ARGUMENTS
+</ARGUMENTS>
+
+## Step 1 - Adaptive Wave Execution
+
+- **Action** — LoadScopeContext: Identify available scope docs in `{OUT_DIR}/`:
+  - `concepts/scope.md`, `specs/prd.md`, `specs/ux.md`, `specs/plan.md`, `specs/tasks.md`, `task_summary.md`
+  - Store existing paths as `SCOPE_DOCS` for subagent dispatch
+
+- **Action** — LoadTaskList: Read `docs/tasks/{branch}/specs/tasks.md` or Beads tasks
+  - Identify wave structure and first wave
+
+- **Action** — ExecuteAdaptiveLoop: Until all tasks complete:
+
+  1. **Batch Tasks**: Assign up to 3 sequential parent tasks per subagent
+     - **Batching Rule**: Group sequential tasks (e.g., 1.1→1.2→1.3) to one agent
+     - **Parallelization Boundary**: If task N must complete before parallel wave W starts, end the batch at N
+     - Example: Tasks 1.1-1.5 sequential, then 2.1-2.3 parallel → Agent A: 1.1-1.3, Agent B: 1.4-1.5, then parallel dispatch for wave 2
+
+  2. **Dispatch Wave**: Launch parallel @dev subagents (1 per task batch)
+     - **CRITICAL**: Each subagent MUST read `SCOPE_DOCS` before executing
+     - Each receives: task batch assignment, dependency completion reports, SCOPE_DOCS paths
+     - Instruct: "Read scope docs first to understand E2E UX and integration points. Load @skill-spectre:spectre-tdd, then execute tasks sequentially using its TDD methodology. **Commit after each parent task** with conventional commit format (e.g., `feat(module): add X`, `fix(module): resolve Y`). Return completion report with **Implementation Insights** + **E2E Completeness Check**."
+
+     **E2E Completeness Check** (subagent returns one per batch):
+     - ⚪ Complete — tasks sufficient to deliver spec intent
+     - 🟡 Gap — [specific functionality missing for E2E UX]
+     - 🔴 Blocker — [cannot deliver spec without changes to other tasks]
+
+  3. **Mark Complete**: Update tasks doc with `[x]` for completed tasks
+
+  4. **Reflect**: Review completion reports for:
+     - Scope signals (🟡/🟠/🔴) from implementation insights
+     - E2E completeness gaps (🟡/🔴) from completeness checks
+     - **If** all ⚪ across both → skip to step 6
+     - **Else** → adapt tasks
+
+  5. **Adapt** (only if triggered):
+     - Modify future tasks with learned context
+     - Add tasks for E2E gaps with `[ADDED - E2E gap]` prefix
+     - Add required sub-tasks with `[ADDED]` prefix
+     - Mark obsoleted with `[SKIPPED - reason]`
+     - Flag cross-task integration issues to remaining waves
+     - **Guardrails**: ❌ No "nice-to-have" additions, ❌ No scope expansion, ✅ Only adapt for spec compliance
+
+  6. **Next Wave**: Identify next tasks, gather relevant completion reports, return to step 1
+
+## Step 2 - Code Review Loop
+
+- **Action** — ExecutedeveviewLoop: Until no critical/high feedback:
+
+  1. **Spawn Review**: @dev subagent runs `/spectre:code_review`
+  2. **Analyze**: Identify critical/high items
+     - **If** none → exit loop
+  3. **Address**: Parallel @dev subagents fix feedback
+  4. **Re-verify**: Return to step 1
+
+## Step 3 - Validate Requirements
+
+- **Action** — SpawnValidation: @reviewer runs `/spectre:validate` with task list
+- **Action** — AddressGaps: If high priority gaps → dispatch @dev subagents to fix
+
+## Step 4 - Prepare for QA
+
+- **Action** — GenerateTestGuide: @dev runs `/spectre:create_test_guide`
+  - Save to `{OUT_DIR}/test_guide.md`
+
+## Step 5 - Report
+
+- **Action** — SummarizeCompletion:
+  - Tasks completed, waves executed, code review iterations, validation status
+  - Test guide location
+  - **Task Evolution Summary**: Adaptations made (or "None - original plan executed")
+  - **E2E Gaps Addressed**: Summary of completeness issues found and resolved
+
+- **Action** — RenderFooter: Use `@skill-spectre:spectre-guide` skill for Next Steps