opsx-ext:task — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited opsx-ext:task (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
End-to-end orchestrator for a single OpenSpec change. Takes a user's request, plans it, implements it, and verifies it in the current working tree — then hands back to the user for final review and commit.
opsx-ext:task-queue instead.When dispatching subagents within a phase:
OpenSpec must be initialized in the project. If the openspec/ directory does not exist, stop immediately and tell the user to run openspec init and openspec update first. Do not proceed without this.
The sub-skills invoked throughout this workflow (/opsx:ff, /opsx:apply, etc.) run openspec CLI commands that produce JSON output. Run each command as a standalone Bash call — the Bash tool returns stdout directly. Do NOT pipe openspec output through Python, jq, or any other inline processor. Do NOT use 2>&1 — stderr mixed into stdout corrupts JSON parsing. If you need to inspect specific fields from large JSON output, save the output to a temp file with > /tmp/openspec-out.json and use the Read tool.
Follow these phases in exact order. Do not skip phases. Do not reorder them.
Invoke /opsx:explore with the user's description to investigate the codebase, understand the current state, and surface gaps or ambiguities.
Parallelization: If the request spans multiple areas (frontend + backend, multiple services, etc.), dispatch one subagent per area to explore concurrently. Merge all findings before presenting to the user.
After exploration, present:
If the request clearly splits into multiple independent changes (e.g., "add the user model AND the auth endpoints AND the middleware"), stop and recommend opsx-ext:task-queue instead — that case warrants worktree-per-change isolation. Otherwise, proceed directly to Phase 2 without asking for confirmation. The user reviews everything in Phase 3; gating the start of implementation on a confirmation prompt just adds friction.
Run steps 2a through 2f without stopping. The next user interaction point is Phase 3.
#### 2a — Create Change
Invoke /opsx:new with the change name from Phase 1.
#### 2b — Generate Artifacts
Invoke /opsx:ff to fast-forward and generate all planning artifacts (proposal, specs, design, tasks).
Validate structure. Run openspec validate <change-name> as a Bash call. Validation enforces format rules that the semantic review in 2c does not check — every ### Requirement: must contain SHALL/MUST, must have body text, and must include at least one #### Scenario: block. If validation errors, edit the artifacts to fix the structural issues and re-run until clean before proceeding to 2c.
#### 2c — Self-Review Artifacts
Ask yourself: "Are there any concerns about these artifacts?"
Parallelization: Dispatch one subagent per artifact file to review simultaneously. Each reviews its artifact looking for:
Collect all concerns, fix them, re-review. Repeat until zero concerns. Maximum 100 passes — if concerns persist, present remaining to the user.
Once concerns are resolved, re-run openspec validate <change-name> to confirm the semantic edits didn't break the format. Fix any new structural errors before exiting the loop.
#### 2d — Implement
Run implementation in parallel waves, orchestrated by this skill directly. Do not invoke /opsx:apply here — that command's step 6 is an in-process serial loop ("for each pending task: implement, mark complete, continue"), so once it starts there is no task list left to fan out from. Parallelism must be planned before any task is touched.
Step 1 — Read the task list. Open openspec/changes/<change-name>/tasks.md and the change's other artifacts (proposal.md, design.md, specs/).
Step 2 — Group tasks by primary edit target. Tasks within tasks.md are usually grouped into sections that each map to one source file (e.g. Section 4 → src/paint.rs). All tasks within one such file group MUST be handled by the same subagent — concurrent edits to the same file by separate subagents corrupt each other. Then identify each group's primary file(s) and which groups depend on symbols exported by which other groups.
Step 3 — Build a wave plan. A typical wave structure:
lib.rs, index.ts, mod.rs, top-level __init__.py). Run after Wave 1 is fully complete.openspec validate commands. Sequential; the orchestrator runs these directly via Bash.When in doubt, prefer one extra wave with cleaner dependency lines over packing borderline-independent groups into the same wave.
Step 4 — Dispatch each wave. For each wave, send all subagent calls in a single tool-use turn (multiple Agent tool calls in one assistant message). Each subagent prompt MUST include:
proposal.md / design.md / spec deltas inlinecompleted: ["4.1","4.2","4.3","4.4","4.5","4.6","4.7"]Step 5 — Mark tasks complete after each wave. Once every subagent in the current wave has returned, the orchestrator reads tasks.md and edits each - [ ] N.M → - [x] N.M for the task numbers the subagents reported as complete. This is the only place tasks.md is mutated. Then proceed to the next wave.
Step 6 — Errors. If any subagent in a wave reports errors or partial completion, dispatch fix subagents in the next turn (still parallel for independent errors). Do not start the next wave until the current wave's outputs are clean.
Config file update: After implementation, check whether the change introduces config-driven behavior (env vars, feature flags, settings). If so, update relevant existing config files (.env.example, config templates, schema files, Docker/compose files). Only update files that already exist — do not create new config infrastructure.
#### 2e — Test
Check whether the project has an existing test suite (test directories, test files, test runner config).
If tests exist:
If no test suite exists, skip this step — do not create a test framework unless the user asked for it.
#### 2f — Verify Loop
Invoke /opsx:verify to validate implementation against artifacts. Verification catches drift between what was planned and what was built — fixing suggestions too prevents spec debt from accumulating.
Fix ALL findings — including suggestions. Parallelization: Group findings by file, dispatch one subagent per file to fix concurrently. Re-run /opsx:verify. Repeat until zero findings. Maximum 100 passes — if findings persist, log the remaining ones and proceed to Phase 3.
Present a one-paragraph summary: the change name, file count, and a smoke test the user can run to verify it. Omit the smoke test if nothing is testable from outside (e.g. an internal refactor).
Example:
"add-user-modelis verified and ready for review (4 files changed). Smoke test:npm test -- --grep User. Let me know if it looks good to finalize, or what needs fixing."
If the user reports issues, fix them, re-run /opsx:verify until clean, then return and wait for confirmation.
Do not proceed until the user confirms.
Once approved:
/opsx:archive to finalize the change.git add . or git add -A. <short summary>
- <change 1>
- <change 2>
- <change 3>Do not include a Co-Authored-By line.
Present a one-line confirmation:
"<change-name> is committed and ready."~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.