/openspec-plus-apply

name: openspec-plus-apply
description: "MANDATORY skill that activates whenever the OpenSpec apply phase begins. Triggers: /opsx-apply runs, the openspec-apply-change vanilla skill is referenced or active, `openspec instructions apply` is invoked, or the user asks to implement, apply, execute, or build out an OpenSpec change ('implement the change', 'apply tasks', 'execute change', 'build out the change'). Takes over only vanilla step 6 (implementation loop) and emulates step 7 output (final status)."
metadata:
  version: 1.6.1
  priority: high
  disable-user-invocation: true

OpenSpec Plus Apply

Mission

Wrap vanilla `/opsx-apply` step 6 (task implementation loop) with subagent orchestration, two-stage review, strict TDD via `openspec-plus-tdd`, four implementation principles, conditional parallelism over a dependency-validated graph, per-slice + final lint/format/test/other gates, never-ignore-failures rule.

Vanilla owns:

• Step 1 — Select change
• Step 2 — `openspec status --change <name> --json`
• Step 3 — `openspec instructions apply --change <name> --json`
• Step 4 — Read context files
• Step 5 — Show progress
• Step 7 — Final status (this skill EMULATES output, not invokes vanilla)

This skill takes over Step 6 only.

---

> **RIGID. NEVER skip Phase 0 mode question when `settings.apply.executionMode` is `ask`. NEVER read affected source code files into the main agent's context — pass PATHS to subagents who read them. NEVER mark a slice `[x]` while a relevant test is failing or skipped. NEVER run code-quality review before spec-compliance ✅. NEVER dispatch parallel implementer subagents within a change without dependency analysis + user confirmation. NEVER modify spec/design from inside the implementer — escalate to plus-design / plus-spec. NEVER commit code. NEVER take over vanilla steps 1-5 or invoke openspec-verify-change or auto-trigger /opsx-archive.**

**Red flags — STOP, you are about to violate this skill:**

• "Re-read the artifacts to be safe" — vanilla loaded them, in context
• "Let me read the affected source files before dispatching the subagent" — NO (subagent mode). Pass paths. Subagent reads. (Inline mode is different — main agent reads directly.)
• "Critique the spec/design before starting" — done; trust them
• "Fix the spec/design from here while implementing" — escalate, don't edit
• "Mark the test `.skip` to move on" — never. Failing tests block progress
• "Slice is small, skip the spec-compliance reviewer" — never
• "Implementer's report says DONE, good enough" — verify with reviewer subagents
• "Both reviewers found issues, fix simultaneously" — spec-compliance first, re-review, then code-quality
• "Reviewing is generic, I'll write the review prompt myself" — NO. Every reviewer dispatch reads its `*-prompt.md` and sends the body verbatim; improvising it is the #1 failure mode
• "This prompt is long, I'll tighten it / drop the obvious parts when passing it on" — NO. Copy the template's `prompt:` block verbatim, substitute only `{PLACEHOLDER}`s. Every bullet is load-bearing; simplifying silently strips instructions from the subagent
• "Should I continue to the next slice?" — never ask. Continuous unless BLOCKED
• "Three fixes failed, try a fourth" — STOP. Artifacts wrong. Pause and exit
• "Run all tests instead of just affected" — wastes time; per-slice gate is scoped
• "Commit as I go" — vanilla doesn't commit; we don't either
• "Run /opsx-archive once everything is done" — only suggest, never auto-trigger
• "Run openspec-verify-change as part of final gate" — out of scope
• "Implementer wrote all tests upfront, that's fine" — TDD violation. One test at a time.
• "Implementer skipped REFACTOR because nothing to refactor" — refactor assessment is mandatory; skipping the assessment is the violation, not the skipping of action
• "AGENTS.md has many rules, implementer applied the ones that felt relevant" — cherry-picking the project's documented rules. Follow them strictly, end-to-end.
• "Implementer did test 1 RED-GREEN-REFACTOR correctly, then batched the rest" — the per-test state machine applies to EVERY test, not just the first
• "Implementer only wrote acceptance tests (one per Gherkin scenario), skipped all unit/edge tests" — acceptance coverage is mandatory but granular tests are encouraged for non-trivial branches, edges, error paths

None justify re-reading artifacts, reading affected code into main context, editing spec/design, ignored failures, skipped reviewers, batched fixes, per-slice check-ins, fix-attempt #4, full-suite tests, commits, archive auto-trigger, verify-change handoff, batched scenario tests, skipped REFACTOR assessment, or cherry-picked project rules.

---

Inputs

Already in conversation context (loaded by vanilla `/opsx-apply` steps 2-4):

• `proposal.md`, `spec.md` (or `specs/**/*.md`), `design.md`, `tasks.md`
• Output of `openspec status --change <name> --json`
• Output of `openspec instructions apply --change <name> --json`

Project standards (`AGENTS.md` / `CLAUDE.md` / `GEMINI.md`) — opencode auto-loads as project instructions; authoritative for code style, file organization, naming, build/test/lint commands.

Build files (`package.json`, `Cargo.toml`, `go.mod`, etc.) — source of lint/format/test commands for gates.

If artifacts NOT in context, surface error:

OpenSpec change artifacts are not in context. Run `/opsx-apply <change>` to load
them, then I will take over the implementation loop.

NEVER read source code outside what slices touch.

---

Workflow

Four phases (0-3) plus hand-back. NEVER skip, merge, or reorder.

[ ] Phase 0: Pre-Flight (verify inputs, discover commands, choose mode)
[ ] Phase 1: Dependency analysis & parallelism check
[ ] Phase 2: Per-slice execution loop
[ ] Phase 3: Whole-change review & final gate

**Flow:** Phase 0 → Phase 1 → (blocked? → suggest /opsx-continue, exit) → (all_done? → suggest /opsx-archive, exit) → Phase 2 per-slice: implementer → (DONE → sp