accelint-qrspi-apply

What this skill does

# Accelint QRSPI Apply

Implement OpenSpec changes with intelligent parallelization. This skill orchestrates parallel sub-agent execution based on dependency analysis in the OpenSpec task file, validates implementation, and manages the complete apply workflow.

## What This Skill Does

**Automates**: The implementation phase of spec-driven development with parallel execution
**Scope**: Task implementation → Validation → Archive readiness
**Output**: Fully implemented change ready for archival

**Does NOT**: Create plans, modify specs, or automatically archive (suggests archival when ready)

## Prerequisites

- OpenSpec CLI installed and initialized
- OpenSpec change created via `accelint-qrspi` skill (includes "Parallelization Strategy" in tasks.md)
- Sub-agent support (for parallel execution)
- The expanded OpenSpec workflows (`explore`, `new`, `continue`) enabled

**Important**: This skill is specifically designed for QRSPI-planned changes. Standard OpenSpec changes without parallelization strategies should use the regular `/opsx:apply` command directly.

## Workflow Overview

```
┌─────────────────────────────────────────────────────────────────┐
│  Phase          Action                        Output            │
├─────────────────────────────────────────────────────────────────┤
│  Parse          Extract parallelization       Dependency graph  │
│  Dependencies   Identify blocking tasks       Execution plan    │
│  Execute        Run slices (parallel/serial)  Implemented code  │
│  Verify         Run opsx:verify               Verification rpt  │
│  Report         Show results + next steps     Archive or fix    │
└─────────────────────────────────────────────────────────────────┘
```

## Phase Breakdown

### Phase 0: Preflight and Change Selection

**Steps**:

1. If a change name is provided in the skill arguments, use it
2. Otherwise, try to infer from conversation context (recent mentions of change names)
3. If ambiguous or missing:
   ```bash
   openspec list --json
   ```
   Parse the JSON and use **AskUserQuestion** to let the user select the change
4. Announce: "Applying change: `<name>`" and how to override (e.g., re-invoke with different name)
5. Check that tasks.md exists:
   ```bash
   openspec status --change "<name>" --json
   ```
   If `state: "blocked"` (missing tasks), exit with: "Tasks artifact is missing. Run `/opsx:continue` to generate tasks before applying."

### Phase 1: Parse Tasks and Parallelization Strategy

**Goal**: Extract task structure and identify parallel vs sequential execution opportunities. Detect if work has already started and resume from the correct level.

**Steps**:

1. Read the tasks.md file from `openspec/changes/<change-name>/tasks.md`

2. **Validate checklist format** (CRITICAL for progress tracking):
   - Check that tasks use markdown checklist format: `- [ ] task` or `- [x] task`
   - If tasks use numbered lists (1. 2. 3.) or plain bullets (- without [ ]):
     ```
     ❌ Invalid tasks.md format
     
     This skill requires tasks in markdown checklist format (`- [ ] task`) for
     progress tracking and resumption detection.
     
     Found format: [numbered lists / plain bullets / other]
     
     Please regenerate tasks.md using the accelint-qrspi-propose skill or convert
     manually to checklist format before applying.
     ```
   - Exit if format is invalid — do not proceed with invalid task format

3. **Check for partial completion** (resumption detection):
   - Count completed tasks (marked `- [x]`) vs total tasks
   - Parse which slices have all their tasks marked complete
   - If any slices are complete, announce: "Detected partial completion. Resuming from Slice N."
   - Adjust the execution plan to skip completed slices

4. Look for the "Parallelization Strategy" section (usually at the end of the file)
5. Parse the strategy to build a dependency graph:

   **Example strategy:**
   ```md
   ## Parallelization Strategy

   - **Slice 1** must complete first (establishes infrastructure)
   - **Slice 2** and **Slice 3** can run in parallel after Slice 1
   - **Slice 2** (implementation cleanup) is independent of **Slice 3** (docs/verification)
   - Final integration: merge both slices, run full pre-commit checklist
   ```

   **Parsed dependency graph:**
   ```
   Level 0 (must run first):
     - Slice 1

   Level 1 (can run in parallel after Level 0):
     - Slice 2
     - Slice 3

   Level 2 (after all previous):
     - Final integration
   ```

6. If no "Parallelization Strategy" section exists:
   - Assume all tasks must run sequentially (safe default)
   - Inform user: "No parallelization strategy found. Running tasks sequentially."

7. Build an execution plan showing:
   - Which slices run in which order
   - Which slices can run in parallel (and which are already complete)
   - Total estimated parallelization speedup
   - Starting point (Level 0 or resuming from Level N)

**Output**: Dependency graph, execution plan, and resumption point if applicable

### Phase 2: Execute Tasks (Sequential + Parallel)

**Goal**: Implement tasks following the dependency graph, spawning parallel sub-agents where possible.

**Sequential execution** (when tasks have dependencies):

For each level in the dependency graph (starting from level 0):

1. If the level has only one slice:
   - Spawn a single sub-agent with this prompt:
     ```
     /opsx:apply <change-name>

     CRITICAL: You MUST use the /opsx:apply command to implement tasks.
     DO NOT implement tasks directly yourself. The /opsx:apply workflow will
     load context and guide implementation.

     IMPORTANT: This is Slice N of a parallelized QRSPI implementation.
     
     Context: This slice must complete before other slices can proceed.
     Other slices will start after you finish.

     Instructions:
     - Work ONLY on tasks in Slice N: [list slice N tasks/sections]
     - Do NOT implement tasks from other slices (Slices X, Y, Z will be handled separately)
     - Follow the normal OpenSpec apply workflow:
       * OpenSpec will load context files (proposal, design, specs, tasks)
       * Implement the tasks assigned to Slice N
       * Mark tasks complete as you go: `- [ ]` → `- [x]`
       * Test your changes if tests are specified in the tasks
     - Report completion with summary of changes made

     Focus exclusively on Slice N. Leave other slice tasks unchecked.
     ```

2. Wait for completion before proceeding to the next level

**Parallel execution** (when multiple slices are independent):

For each level with multiple independent slices:

1. Spawn all sub-agents in parallel in a single turn (one per slice):
   ```
   /opsx:apply <change-name>

   CRITICAL: You MUST use the /opsx:apply command to implement tasks.
   DO NOT implement tasks directly yourself. The /opsx:apply workflow will
   load context and guide implementation.

   IMPORTANT: This is Slice N of a parallelized QRSPI implementation.
   
   Context: This slice is independent and runs in parallel with Slices X, Y.
   Other agents are working on those slices simultaneously.

   Instructions:
   - Work ONLY on tasks in Slice N: [list slice N tasks/sections]
   - Do NOT implement tasks from other slices - they are being handled in parallel
   - Follow the normal OpenSpec apply workflow:
       * OpenSpec will load context files (proposal, design, specs, tasks)
       * Implement the tasks assigned to Slice N
       * Mark tasks complete as you go: `- [ ]` → `- [x]`
       * Test your changes if tests are specified in the tasks
   - Report completion with summary of changes made

   Focus exclusively on Slice N. Leave other slice tasks unchecked.
   Your work is independent and should not block or depend on other slices.
   ```

2. Track completion as each sub-agent finishes
3. When all slices in the level are done, **pause and offer context management**:
   ```
   ✅ Level N complete
   
   Completed slices:
   - Slice X: [summary]
   - Slice Y: [summary]