Apply

---
name: "OPSX: Apply"
description: Implement tasks from an OpenSpec change and drive each section through PR + CI + code review until green (Experimental)
category: Workflow
tags: [workflow, artifacts, experimental]
---

Implement tasks from an OpenSpec change and drive the full delivery cycle for each section: branch → implement → commit → push → PR → CI → `/code-review` → address feedback → CI green.

**Input**: Optionally specify a change name (e.g., `/opsx:apply add-auth`). If omitted, check if it can be inferred from conversation context. If vague or ambiguous you MUST prompt for available changes.

**Steps**

1. **Select the change**

   If a name is provided, use it. Otherwise:
   - Infer from conversation context if the user mentioned a change
   - Auto-select if only one active change exists
   - If ambiguous, run `openspec list --json` and use **AskUserQuestion** to let the user pick

   Announce: "Using change: <name>" and how to override (`/opsx:apply <other>`).

2. **Check status to understand the schema**
   ```bash
   openspec status --change "<name>" --json

Parse schemaName and which artifact holds the tasks.

3. Get apply instructions

   openspec instructions apply --change "<name>" --json
   

   • state: "blocked" → suggest /opsx:continue and stop.
   • state: "all_done" → congratulate, suggest /opsx:archive, stop.
   • Otherwise: continue.

4. Read context files — every path under contextFiles. Schema decides which (spec-driven: proposal, specs, design, tasks).

5. Show current progress — schema, N/M complete, remaining tasks overview, the dynamic instruction from the CLI.

6. Plan section batches.

   Group the remaining pending tasks by their tasks.md section header (## ...). Each section = one PR. Skip sections already fully complete. If the file has no section headers, treat the whole remaining list as a single batch.

   Announce the planned batches in order before starting.

7. For each section batch, run the full delivery cycle below. Do not start the next section until the current section's PR is green post-review.

   a. Start a fresh branch from latest main.

   • Confirm the working tree is clean (git status --porcelain). If dirty, pause and ask.

   • git fetch origin main
     git checkout -B <change-name>--<section-slug> origin/main
     

   b. Implement the tasks in the section.

   • Per-task loop: read task → make minimal, focused changes → tick - [ ] → - [x] in tasks.md immediately.
   • Prefer the TypeScript LSP (findReferences, goToDefinition, hover, workspaceSymbol) per CLAUDE.md for symbol-level work.
   • Pause only on ambiguity, design issues, or unrecoverable errors — don't guess.

   c. Add a changeset if package source changed.

   • CI's changeset job fails the PR if any packages/*/src/** or packages/*/package.json is touched without a new .changeset/*.md. Run pnpm changeset (or author the file directly) before committing.

   d. Run the local quality gate before committing.

   • The pre-commit hook will run anyway; running these proactively avoids bounce-backs:

     pnpm format && pnpm lint && pnpm typecheck && pnpm test
     

   • If the pre-commit hook fails, fix the root cause and create a NEW commit — never --no-verify, never --amend (per global git safety rules).

   e. Commit and push autonomously, then open the PR.

   • One cohesive commit per section (or a small number of logical commits). Match the repo's conventional-commit style (see git log for examples like feat(queue): ...).
   • git push -u origin <branch> then gh pr create with a conventional-commit title and a body listing the section's tasks. No pause for confirmation before push.

   f. Monitor CI until it terminates.

   • Poll: gh pr checks <pr-number> --json name,state,conclusion every ~60s, or gh pr checks <pr-number> --watch.
   • If any check fails: gh run view <run-id> --log-failed → diagnose root cause → fix → commit → push. Repeat until all checks pass. Do not proceed to review while red.

   g. Run /compact to free context before the review.

   h. Run /code-review against the PR.

   • Invoke the code-review skill with the PR number once CI is green: code-review PR #<n>.
   • Wait for the review to complete.

   i. Run /compact again before addressing feedback.

   j. Address review feedback per CLAUDE.md → "Addressing PR review comments".

   • One commit per comment. Judge each comment before applying; reject with a reason when wrong.
   • Reply via gh api -X POST repos/:owner/:repo/pulls/<n>/comments/<id>/replies, then resolve the thread via the GraphQL resolveReviewThread mutation.
   • Watch for the pending-review gotcha called out in CLAUDE.md — ask the user how to proceed rather than silently submitting or dismissing.

   k. Re-monitor CI after the fix commits land. Iterate until green again.

   l. Move to the next section batch.

8. All sections complete — show final progress and suggest /opsx:archive.

Output During a Section

## Implementing: <change-name> — section "<section-title>" (schema: <schema-name>)

Branch: <branch>  PR: #<n>

Working on task <i>/<m>: <task description>
[...implementation...]
✓ Task complete

[...all section tasks done...]
→ Quality gate: pnpm format/lint/typecheck/test … ✓
→ Pushed and opened PR #<n>
→ CI: monitoring… ✓ green
→ /code-review PR #<n> … <K> comments
→ Addressed <K> comments (commits <sha1>..<shaK>); CI re-monitoring… ✓ green

Output On Completion

## Implementation Complete

**Change:** <change-name>
**Progress:** M/M tasks complete ✓
**PRs opened:** #<a>, #<b>, …  (all merged-ready / green)

Ready to archive: `/opsx:archive <change-name>`.

Output On Pause

## Implementation Paused

**Change:** <change-name>
**Section:** <section-title>
**Where:** <task / qu