| name | plan |
| group | Lifecycle |
| description | Produce a written plan before non-trivial APXM implementation. Required for changes touching >3 files, modifying a public API or AIS op, or needing Slurm GPU allocation. Enforces APXM-specific gates (AIS-op-vs-compose decision, dialect-codegen impact). |
| user-invocable | true |
APXM Plan
Write a plan before implementing. Mirrors native plan mode but enforces
APXM gates that generic planning skips.
When this skill is required
- Change touches >3 files.
- Change modifies a public API or AIS op (anything other crates or
the Python frontend will see).
- Change requires a Slurm GPU allocation.
- Change rebases or edits
external/vllm.
Trivial bug fixes, doc-only edits, single-file refactors with a clear
local scope do not require this skill.
What this skill does
- List affected files and subsystems. Be specific: file paths,
public API surface, downstream consumers.
- Decide AIS-op-vs-compose if the change adds or modifies behavior
currently expressed in
apxm-core. Adding an op? Invoke
ais-op-design first — it owns the design-before-code gate.
- State expected verification: which
dekk agents test -p <crate>,
which integration test, which dekk agents vllm zoo-status probe,
which --strict lint.
- State boundaries — what the change is NOT doing. Prevents
scope creep during execution.
- State a rollback plan — branch name, what's reversible, what's
not (e.g. codegen output, manifests committed mid-flight).
- Get user sign-off — use the harness's plan-approval surface
(Claude Code:
ExitPlanMode) or an explicit confirmation from the
user in conversation. Do not proceed without it.
Plan template
## Goal
<one paragraph, concrete>
## Affected
- Files: <list>
- Subsystems: <crate(s), AIS ops, python frontend, vLLM fork>
- Public API impact: <none / additive / breaking>
## Approach
<bullets>
## Pre-work
- [ ] ais-op-design (if adding an AIS op)
- [ ] dekk agents build-dialect + codegen (if editing .td)
## Verification per phase
- Phase 1: <command>
- Phase 2: <command>
## Boundaries — explicitly NOT in scope
- <bullet>
## Rollback
- Branch: <name>
- Reversible? <yes/no, plus what's not>
Anti-patterns
- Plans that double as implementations ("First I'll edit X to add the
field, then…"). Plans state the shape, not the diff.
- Plans without verification per phase.
- Plans that omit the boundaries section — scope creep happens precisely
where boundaries aren't drawn.
- "Add new AIS op" plans that skip
ais-op-design.
Next step
Once the user signs off, invoke execute-plan. Do not begin
implementation before approval.
