OPSX: Apply
OPSX: Apply executes implementation tasks defined in an OpenSpec change, a structured workflow system for managing code modifications. Use this command when you need to systematically work through a predefined set of tasks, handling schema detection, progress tracking, context file reading, and iterative implementation with checkpoints and error handling built in.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/VILA-Lab/FigMirror/HEAD/.claude/commands/opsx/apply.md -o ~/.claude/commands/opsx-apply.mdapply.md
Implement tasks from an OpenSpec change. **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` to get available changes and use the **AskUserQuestion tool** to let the user select Always announce: "Using change: <name>" and how to override (e.g., `/opsx:apply <other>`). 2. **Check status to understand the schema** ```bash openspec status --change "<name>" --json ``` Parse the JSON to understand: - `schemaName`: The workflow being used (e.g., "spec-driven") - Which artifact contains the tasks (typically "tasks" for spec-driven, check status for others) 3. **Get apply instructions** ```bash openspec instructions apply --change "<name>" --json ``` This returns: - Context file paths (varies by schema) - Progress (total, complete, remaining) - Task list with status - Dynamic instruction based on current state **Handle states:** - If `state: "blocked"` (missing artifacts): show message, suggest using `/opsx:continue` - If `state: "all_done"`: congratulate, suggest archive - Otherwise: proceed to implementation 4. **Read context files** Read the files listed in `contextFiles` from the apply instructions output. The files depend on the schema being used: - **spec-driven**: proposal, specs, design, tasks - Other schemas: follow the contextFiles from CLI output 5. **Show current progress** Display: - Schema being used - Progress: "N/M tasks complete" - Remaining tasks overview - Dynamic instruction from CLI 6. **Implement tasks (loop until done or blocked)** For each pending task: - Show which task is being worked on - Make the code changes required - Keep changes minimal and focused - Mark task complete in the tasks file: `- [ ]` → `- [x]` - Continue to next task **Pause if:** - Task is unclear → ask for clarification - Implementation reveals a design issue → suggest updating artifacts - Error or blocker encountered → report and wait for guidance - User interrupts 7. **On completion or pause, show status** Display: - Tasks completed this session - Overall progress: "N/M tasks complete" - If all done: suggest archive - If paused: explain why and wait for guidance **Output During Implementation** ``` ## Implementing: <change-name> (schema: <schema-name>) Working on task 3/7: <task description> [...implementation happening...] ✓ Task complete Working on task 4/7: <task description> [...implementation happening...] ✓ Task complete ``` **Output On Completion** ``` ## Implementation Complete **Change:** <change-name> **Schema:** <schema-name> **Progress:** 7/7 tasks complete ✓ ### Completed This Session - [x] Task 1 - [x] Task 2 ... All tasks complete! You can archive this change with `/opsx:archive`. ``` **Output On Pause (Issue Encountered)** ``` ## Implementation Paused **Change:** <change-name> **Schema:** <schema-name> **Progress:** 4/7 tasks complete ### Issue Encountered <description of the issue> **Options:** 1. <option 1> 2. <option 2> 3. Other approach What would you like to do? ``` **Guardrails** - Keep going through tasks until done or blocked - Always read context files before starting (from the apply instructions output) - If task is ambiguous, pause and ask before implementing - If implementation reveals issues, pause and suggest artifact updates - Keep code changes minimal and scoped to each task - Update task checkbox immediately after completing each task - Pause on errors, blockers, or unclear requirements - don't guess - Use contextFiles from CLI output, don't assume specific file names **Fluid Workflow Integration** This skill supports the "actions on a change" model: - **Can be invoked anytime**: Before all artifacts are done (if tasks exist), after partial implementation, interleaved with other actions - **Allows artifact updates**: If implementation reveals design issues, suggest updating artifacts - not phase-locked, work fluidly
Reviewer role in the FigMirror loop. Audits a draft figure against the L1 reference image, L2 aesthetic library, and optional 3D insert; outputs ONE strict JSON object (anchor.what_is_right + quality_floor + fidelity.verdict + focus_themes). Vision-only audit — must NOT read data.txt, drawer notes, or any path outside the audit_view directory it is briefed to read. Tools restricted to Read + Bash for PIL measurement on L1-reliable properties only. Dispatched by figure-orchestrator on each iter.
Drawer role in the FigMirror loop. Produces a self-contained matplotlib script + rendered PNG + iter notes that match a reference paper figure's STYLE (not its data). Reads the reference image, the user's data, the L2 aesthetic library, and optional 3D insert; runs an iter-0 anchor-measurement pass; self-checks the layout floor before handoff. Dispatched by figure-orchestrator on each iter of the Drawer/Reviewer loop. Do NOT use this agent standalone — it expects the workdir layout staged by figure-orchestrator.
Stage-0 image cropper for FigMirror. Cleans the user-supplied reference screenshot before Drawer/Reviewer style analysis by preserving the raw upload, cropping away captions/page text/screenshot margins/neighboring panels when safe, writing reference_clean.png plus a before/after crop check and report. Dispatched before figure-illustrator and figure-critic.
Archive a completed change in the experimental workflow
Enter explore mode - think through ideas, investigate problems, clarify requirements
Propose a new change - create it and generate all artifacts in one step
>
Implement tasks from an OpenSpec change. Use when the user wants to start implementing, continue implementation, or work through tasks.