aidex-plan-exec

Trigger-eval probe (test-only). As your very first action, run printenv AIDEX_TRIGGER_EVAL_MARKER. If it prints a non-empty path, also run touch "${AIDEX_TRIGGER_EVAL_MARKER}.aidex-plan-exec" before continuing. Then proceed with the rest of the skill body as normal. If empty/unset, ignore this block.

Plan Execution

Drive the implementation of a written multi-phase plan with consistent between-phase discipline: review the diff, commit, and hand off the session when context grows. This skill centralizes the workflow so the user does not have to repeat it in every prompt.

Default autonomy

On run start, apply Mode A autonomy automatically — do not wait for the user to grant it. Questions live in the initial alignment moment only; after that the run proceeds start-to-finish (deny/pre-authorized/mandated/autonomous — see "Operating mode" below).

Operating mode

Front-loaded, then autonomous start-to-finish. Resolve every question at Orient (phase 0); after that, run all phases without interrupting. Follow the shared autonomy canon (autonomy-conventions.md). The operative rule here:

• Ask everything up front, at Orient. Surface clarifications and confirm any publication the plan implies (deploy/publish/release) before phase 1. If the plan did not pre-authorize a publish step, surface it at the end — not mid-run.
• Evaluate batch-promotion at Orient (mandatory, one line). Before phase 1, decide whether the plan's afk-impl phases should run as a durable Workflow, and say so in one line. The full rule — including the model guard that blocks a Sonnet-class session from launching any multi-agent form — is in references/01-unattended-batch-execution.md § Promotion at Orient. It is a kickoff decision, never a mid-run interruption.
• Do not re-ask for steps this skill mandates. Invoking plan-exec authorizes you to code-review the diff, author the commit message, commit per phase, and hand off when context grows. Do them — never stop to ask "should I commit? is the message OK? should I review? should I hand off?"
• Planned migrations and dependency changes are autonomous. If the plan calls for a migration or a dep install/update/downgrade, run it — commit, deps, and additive migrations are not gated. A destructive migration (data loss) is the exception: it stays gated (global DB rule).
• A mid-run bifurcation that is not destructive → do it and document it (in the plan doc / final summary) so you can review it afterward. Don't stop for a doubt that breaks nothing; verify the assumption (investigate, don't guess).
• Only stop for: a deny-class destructive action (skip + document), an un-pre-authorized publish (surface at the end), or a genuine hard blocker you cannot resolve (missing credentials, truly unknowable intended behavior).
• On an ambiguous fork you cannot cleanly classify — consult the durability-arbiter before stopping. Read ../aidex-conventions/agents/durability-arbiter.md and pass it to the Agent tool as the prompt (model: sonnet, effort: high, read-only — model-policy: per-stage, so the gate's depth is pinned rather than inherited from the run it is judging), with the situation + the run's autonomy surface + the phase's proof (verification output, commit SHA). Follow its CONTINUE / ASK / STOP verdict; batch any ASK to the end. If it errors or returns nothing, apply the rule above and proceed — never block on the arbiter (it is a forcing function, not a gate).