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 openspec-apply-change skill directly.

Workflow Overview

┌─────────────────────────────────────────────────────────────────┐
│  Stage          Action                        Output            │
├─────────────────────────────────────────────────────────────────┤
│  Preflight      Select and validate change    Ready to proceed  │
│  Start Time     Record started_at timestamp   Telemetry marker  │
│  Parse          Extract parallelization       Dependency graph  │
│  Dependencies   Identify blocking tasks       Execution plan    │
│  Load Context   Read config.yaml context      Project context   │
│  Execute        Run slices (parallel/serial)  Implemented code  │
│  Update Docs    Sync living documents         Updated docs      │
│  Complete Time  Record completed_at timestamp Telemetry marker  │
│  Verify         Run opsx:verify               Verification rpt  │
└─────────────────────────────────────────────────────────────────┘

Implementation Steps

Preflight and Change Selection

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:

   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:

   openspec status --change "<name>" --json
   

   If state: "blocked" (missing tasks), exit with: "Tasks artifact is missing. Run openspec-continue-change to generate tasks before applying."

Record Implementation Start

Goal: Mark when implementation begins for telemetry tracking.

6. Read the design.md file from openspec/changes/<change-name>/design.md to check if started_at timestamp exists in frontmatter

7. If started_at is NOT present in the frontmatter (first time applying this change):

   • Add the started_at timestamp to the frontmatter using ISO 8601 format with Z suffix
   • CRITICAL: Generate the timestamp deterministically using this command:

     python3 -c "from datetime import datetime, timezone; print(datetime.now(timezone.utc).isoformat(timespec='seconds').replace('+00:00', 'Z'))"
     

   • Insert started_at immediately after the created_at field to keep all timestamps grouped together
   • Preserve all other frontmatter fields (change, created_at, specs_touched, decisions) in their original order
   • Inform user: "Recording implementation start time..."

8. If started_at IS present (resuming after context clear or pause):

   • Do not modify the timestamp — preserve the original start time
   • Inform user: "Resuming implementation (started at [timestamp])..."

Example frontmatter after adding started_at:

---
change: <change-name>
created_at: "2026-08-17T15:00:00.000Z"
started_at: "2026-08-17T16:30:00.000Z"
specs_touched: [<capability-a>, <capability-b>]
decisions:
  - id: D1
    choice: <decision>
    rationale: <why>
    alternatives: [<option>]
---

Output: Timestamp written to design.md frontmatter (if this is first application), or confirmation of resumption

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.

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

10. 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

11. 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

12. Look for the "Parallelization Strategy" section (usually at the end of the file)

13. Parse the strategy to build a dependency graph:

Example strategy:

## 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

14. If no "Parallelization Strategy" section exists:

• Assume all tasks must run sequentially (safe default)
• Inform user: "No parallelization strategy found. Running tasks sequentially."

15. 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

Load Project Context

Goal: Load project context from openspec/config.yaml to inject into sub-agent prompts. This compensates for OpenSpec CLI's limitation where the apply skill doesn't automatically load project context (unlike artifact creation skills).

Background: OpenSpec's openspec instructions apply skill does NOT inject the context field from config.yaml (confirmed via code inspection and testing). This means sub-agents implementing tasks don't receive Stack Facts, coding patterns, testing conventions, or anti-patterns that should guide implementation. We work around this limitation by manually loading and injecting the context.

16. Check if openspec/config.yaml exists:

test -f openspec/config.yaml && echo "exists" || echo "missing"

17. If the file exists, read it:

cat openspec/config.yaml

18. Parse and extract the context section (YAML block under context: |):

• The context starts after the line context: |
• The context continues until the next top-level YAML key (e.g., rules:, schema:)
• Lines in the context block are indented (usually 2 spaces)
• Preserve all whitespace and newlines in the context block
• You MUST inform the user that you found and loaded the config.

19. Store the extracted context for injection into sub-agent prompts in the next steps

20. If no context field exists or the file is missing:

• Set context to empty string
• Proceed without context injection (sub-agents will rely on OpenSpec's default behavior)
• You MUST inform the user that you could NOT find and load the config.

Example config.yaml structure:

schema: spec-driven

context: |
  # STACK FACTS
  ## Project Identity
  auditkit-cli: TypeScript-based code quality audit CLI

  ## Dependencies
  - @fission-ai/openspec: ^1.2.0
  - vitest: ^2.1.8

  # CODING PATTERNS
  - Use Result<T,E> for fallible operations (never throw)
  - Data-last parameter ordering for currying
  - No `any` types — use `unknown` with type guards

  # TESTING CONVENTIONS
  - AAA pattern (Arrange/Act/Assert)
  - One assertion per test
  - Use descriptive test names

rules:
  proposal: [...]
  design: [...]

Output: Extracted project context string (may be empty if not present)

Execute Tasks (Sequential + Parallel)

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

Sequential execution (when tasks have dependencies):

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

21. If the level has only one slice:

• Use the Agent tool to spawn a single sub-agent with this prompt (inject project context loaded in step 16):

  <project_context>
  <!-- Background constraints for your implementation. Do NOT copy into code. -->
  {INJECTED_CONFIG_CONTEXT}
  </project_context>
  
  Invoke the openspec-apply-change skill.
  
  <change-name>
  
  CRITICAL: You MUST use the openspec-apply-change skill to implement tasks.
  DO NOT implement tasks directly yourself. The openspec-apply-change 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)
  - Before you add or change code, apply this simplicity ladder and stop at the first rung that holds:
    1. Does this need to exist at all? Speculative need = skip it, say so in one line. (YAGNI)
    2. Already in this codebase? A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
    3. Stdlib does it? Use it.
    4. Non-UI code: does a native platform or language feature cover it? Use it before a library.
    5. UI code: if this codebase already has a design-system or UI-library primitive for it, use that before raw native elements or hand-rolled UI behavior.
    6. Already-installed dependency solves it outside the above cases? Use it. Never add a new one for what a few lines can do.
    7. Can it be one line? One line.
    8. Only then: the minimum code that works.
  - Never simplify away trust-boundary input validation, error handling that prevents data loss, security checks, accessibility basics, or other explicit project constraints — the minimalism heuristics above never override this.
  - Apply the code patterns, conventions, and constraints from <project_context>
  - 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
  - The <project_context> provides Stack Facts, coding patterns, testing conventions,
    and anti-patterns to avoid. These are constraints for YOU, not content to include in files.
  
  Focus exclusively on Slice N. Leave other slice tasks unchecked.
  

  Note: If no project context was loaded earlier, omit the <project_context> block entirely

22. Wait for completion before proceeding to the next level

Parallel execution (when multiple slices are independent):

For each level with multiple independent slices:

23. Use the Agent tool to spawn all sub-agents in parallel in a single turn (one per slice, inject project context from earlier steps):

<project_context>
<!-- Background constraints for your implementation. Do NOT copy into code. -->
{INJECTED_CONFIG_CONTEXT}
</project_context>

Invoke the openspec-apply-change skill.

<change-name>

CRITICAL: You MUST use the openspec-apply-change skill to implement tasks.
DO NOT implement tasks directly yourself. The openspec-apply-change 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
- Before you add or change code, apply this simplicity ladder and stop at the first rung that holds:
  1. Does this need to exist at all? Speculative need = skip it, say so in one line. (YAGNI)
  2. Already in this codebase? A helper, util, type, or pattern that already lives here → reuse it. Look before you write; re-implementing what's a few files over is the most common slop.
  3. Stdlib does it? Use it.
  4. Non-UI code: does a native platform or language feature cover it? Use it before a library.
  5. UI code: if this codebase already has a design-system or UI-library primitive for it, use that before raw native elements or hand-rolled UI behavior.
  6. Already-installed dependency solves it outside the above cases? Use it. Never add a new one for what a few lines can do.
  7. Can it be one line? One line.
  8. Only then: the minimum code that works.
- Never simplify away trust-boundary input validation, error handling that prevents data loss, security checks, accessibility basics, or other explicit project constraints — the minimalism heuristics above never override this.
- Apply the code patterns, conventions, and constraints from <project_context>
- 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
- The <project_context> provides Stack Facts, coding patterns, testing conventions,
  and anti-patterns to avoid. These are constraints for YOU, not content to include in files.

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

Note: If no project context was loaded earlier, omit the <project_context> block entirely

24. Track completion as each sub-agent finishes

25. Context management decision point - When all slices in the level are done, pause and offer context management:

✅ Level N complete

Completed slices:
- Slice X: <summary>
- Slice Y: <summary>

Next: Level N+1 has M slice(s) to run [list slices]

Options:
(a) Continue to next level
(b) Clear context and resume — I'll pick up from Level N+1
(c) Pause here — you can resume later with this skill

26. If user chooses (b), instruct them:

Run `/clear` to reset context, then re-invoke this skill.
I'll detect that Level N is complete and resume from Level N+1.

27. If user chooses (c), exit and remind them how to resume:

Paused at Level N+1. To resume, re-invoke this skill.
Progress is tracked in tasks.md checkboxes.

Slice targeting approach: OpenSpec's openspec-apply-change skill does not have native "slice targeting" (no --slice N flag). This skill achieves parallelization by:

1. Using the full OpenSpec CLI workflow: Each sub-agent invokes openspec-apply-change <change-name>, which:

   • Runs openspec instructions apply --change "<name>" --json to get context
   • Loads all context files (proposal, design, specs, tasks)
   • Provides dynamic instructions based on current state
   • Handles task progress tracking and status checks

2. Slice isolation via instructions: The orchestrating skill:

   • Parses the parallelization strategy to identify independent slices
   • Spawns sub-agents with explicit instructions to work ONLY on their assigned slice
   • Relies on QRSPI's vertical slicing to ensure slices are truly independent
   • Each sub-agent marks only its slice's tasks as complete

3. Why this works: QRSPI's vertical slicing methodology ensures each slice is:

   • A complete end-to-end feature increment
   • Independent with minimal file overlap
   • Testable in isolation
   • Safe to implement in parallel

The slice boundaries are clearly marked in tasks.md (e.g., "## Slice 1: Remove CLI Surface", "## Slice 2: Remove Implementation"), making it straightforward for sub-agents to identify their scope.

Update Living Documents

Goal: Update project documentation to reflect the implemented changes before running verification.

Why this matters: OpenSpec changes represent significant architectural decisions and feature additions. Living documents (ARCHITECTURE.md, AGENTS.md, openspec/config.yaml) provide context for agents working in the codebase, while README.md serves human users. Keeping them synchronized prevents documentation drift and ensures future agents and developers have accurate, up-to-date context about the system's current state.

IMPORTANT: Run this step BEFORE verification so the verification step can check documentation completeness.

28. Check if the change is in a repository or package root by looking for .git/ or package.json

29. Determine the repo/package root (may be current directory or a parent)

30. Process ALL living documents in this order (do not stop after the first one):

• OpenSpec config (openspec/config.yaml)
• ARCHITECTURE.md (if exists)
• AGENTS.md (if exists)
• README.md (if exists)

Precedence rules for this phase:

• If the corresponding Accelint documentation skill is installed, you MUST use that skill. Do NOT manually edit the document yourself.
• Manual fallback is allowed ONLY when the corresponding skill is unavailable.
• If an invoked documentation skill returns a preview and asks for confirmation before writing, that preview/confirmation gate is MANDATORY. Present it to the human and wait for explicit approval. Do NOT bypass the gate by editing the file manually.
• The "do not pause between documents" rule means: once one document is fully resolved (skipped, approved-and-written via its skill, or manually updated because its skill is unavailable), continue immediately to the next document. It does NOT override a child skill's required preview/confirmation step.
• Never choose manual fallback just because it seems faster or because the child skill asked for confirmation.

For each document in the list above, follow these steps:

Step 3a: Check if update is needed first

• Read the change artifacts to understand what was implemented:
  • openspec/changes/<change-name>/proposal.md
  • openspec/changes/<change-name>/design.md
• Assess whether this change introduces content that would affect the document
• If the change is trivial (typos, comments) or doesn't touch the document's scope, skip to the next document

Step 3b: Update the document if needed

For OpenSpec config (<repo-root>/openspec/config.yaml):

• Check if accelint-onboard-openspec skill is installed

• If skill is available:

  1. The child skill owns discovery, preview, confirmation, and write steps for this document. Do NOT manually edit openspec/config.yaml while this skill is available.
  2. Read openspec/changes/<change-name>/design.md frontmatter to extract the decisions field
  3. For each decision, rephrase as a plain factual statement (not an instruction)
  4. Invoke the skill with findings:

  Invoke the accelint-onboard-openspec skill.
  
  We have just completed the change spec openspec/changes/<change-name>.
  
  findings:
  - [Decision 1 rephrased as fact, e.g., "config.yaml's Anti-Patterns section says to avoid polling, but this change chose polling for stated reasons"]
  - [Decision 2 rephrased as fact]
  ...
  

  The skill will merge these findings with its own codebase scan before presenting to the human.

• If skill is NOT available, read the change artifacts:

  • openspec/changes/<change-name>/proposal.md
  • openspec/changes/<change-name>/design.md

  Then read openspec/config.yaml and update manually focusing on project DNA (WHAT the project is):

  • Tech Stack section: Add new dependencies, frameworks, or libraries introduced by this change with versions
  • Domain Concepts section: Add new entities or domain terms if this change introduces them
  • Code Patterns section: Update if this change establishes new patterns (exports, error handling, validation approaches)
  • Architecture Patterns section: Add new design patterns if introduced (factory, repository, observer, etc.)
  • Patterns to Avoid section: Add any anti-patterns this change deprecates or makes explicit
  • Per-artifact rules (rules: section): Update if this change affects proposal/design/tasks/spec requirements
  • DO NOT add agent behavior (commit conventions, workflow steps, tool preferences belong in AGENTS.md)

For ARCHITECTURE.md (<repo-root>/ARCHITECTURE.md) — IF it exists:

• Check if accelint-architecture-doc skill is installed

• If skill is available:

  1. The child skill owns discovery, preview, confirmation, and write steps for this document. Do NOT manually edit ARCHITECTURE.md while this skill is available.
  2. Read openspec/changes/<change-name>/design.md frontmatter to extract the decisions field
  3. For each decision, rephrase as a plain factual statement (not an instruction)
  4. Invoke the skill with findings:

  Invoke the accelint-architecture-doc skill.
  
  We have just completed the change spec openspec/changes/<change-name>.
  
  findings:
  - [Decision 1 rephrased as fact]
  - [Decision 2 rephrased as fact]
  ...
  

  The skill will merge these findings with its own codebase scan before presenting to the human.

• If skill is NOT available, read the change artifacts:

  • openspec/changes/<change-name>/proposal.md
  • openspec/changes/<change-name>/design.md