メニュー
Use when validating, compiling, executing, running, analyzing, or explaining APXM workflow artifacts such as canonical .air workflows, Python frontend workflows, .apxmw workflow files, and compiled APXM objects.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Use when work is multi-step, long-running, side-effecting, approval-gated, or must survive a coding-host session and remain observable through APXM.
Use when designing APXM-owned event-triggered loop specs or workflow packs, and when identifying which APXM server/MCP/Dekk capabilities are missing. Do not use as the primary skill for generic MCP usage, workflow following, worker selection, or execution.
Use when converting a Codex skill, Claude/Superpowers-style skill, or local agent procedure into an APXM workflow pack with AIR source, policy, compile targets, verification, and conversion notes.
Use when a decision needs a traceable APXM council with multiple worker perspectives, dissent, critique, evidence, and a final recommendation. Use for architecture choices, risk reviews, plan reviews, and high-impact tradeoff analysis.
Use when following, watching, replaying, archiving, or explaining APXM workflow/run progress through APXM OS observability surfaces such as watch, rollout list, rollout replay, rollout archive, process list, and workflow sessions.
Use when verifying APXM workflow traces, artifacts, schema validity, test evidence, worker outputs, budget records, or whether an APXM run actually satisfied its declared acceptance criteria.
| name | compile-and-execute |
| description | Use when validating, compiling, executing, running, analyzing, or explaining APXM workflow artifacts such as canonical .air workflows, Python frontend workflows, .apxmw workflow files, and compiled APXM objects. |
Use this skill as the direct APXM/Dekk execution path. It should be boring and traceable: validate first, compile when needed, execute with policy, then report artifacts.
PLUGIN_ROOT as the directory two levels above this skill directory."$PLUGIN_ROOT/scripts/ensure_apxm_cli.sh"
.air: the only wire input to compile/execute. Author
single-graph workflows as an apxm.workflow-draft.v1 document (schema:
contracts/schemas/workflow-draft.v1.json in the coordinator's
workspace/contracts) and lower to .air via a frontend's to_air(), or
hand-write AIR directly (grammar: contracts/docs/air-grammar.md). Then
validate, analyze, then execute or compile..apxmw: a checked-in multi-step workflow manifest (steps referencing
already-compiled .air/.apxmobj/nested .apxmw files, not an authored
graph document) — use dekk apxm workflow validate|analyze|execute when
available..apxmobj: run directly.Use the available command surface that matches the artifact:
dekk apxm validate <workflow.air>
dekk apxm analyze <workflow.air>
dekk apxm explain <workflow.air>
dekk apxm compile <workflow.air> -o <workflow.apxmobj>
dekk apxm run <workflow.apxmobj>
dekk apxm execute <workflow.air>
dekk apxm workflow validate <workflow.apxmw>
dekk apxm workflow analyze <workflow.apxmw>
dekk apxm workflow execute <workflow.apxmw> --json
dekk apxm workflow execute <workflow.apxmw> --background --session-root <dir> --json
When calling the APXM binary directly instead of Dekk, the workflow execution subcommand may be apxm workflow run <workflow.apxmw> --json.
Use background workflow execution for long-running orchestration when the user needs to keep working while APXM records follow handles. The response should include pid, session_dir, log_file, and command.
Store generated artifacts under .apxm/ unless the user or repo has a clearer convention.
dekk apxm validate; executable workflows should be canonical AIR or Python source that emits AIR.Return: status, artifact_type, validated, compiled, executed, trace_id, artifacts, warnings, and next_action.