Executing Plans

Announce this skill, read the supplied plan, and check current files and repository
instructions. Treat the plan as intent; resolve material contradictions before
dependent work. Preserve unrelated changes. Use the existing project tracker.

Follow docs/canon/reasoning-routing.md from the selected installation. Record
reasons and rationale, resolve the execution role, and preserve frontier planning
and independent review requirements. Hand off only with decisions, constraints,
verification and escalation conditions. Missing authentication is an operational
blocker, not permission to change the required reviewer or destination.

Execute sequentially by default. If a companion .exec.yaml exists or the project
has .claude/clodex-toggle.flag, read
execution-modes.md for that mode before dispatch.
Use only authorized delegation and available host capabilities. Pattern F runs
also require pattern-f-contracts.md.

For each logical task: mark progress, implement the specified behavior, run the
meaningful checks, inspect their results and preserve review evidence. Use
intertest:test-driven-development for behavior changes. Report material findings
between batches and continue authorized work without ceremonial approval requests.

Verification blocks require a zero process exit as well as the declared
expectation. Reject unknown expectation syntax; output text never overrides a
nonzero exit. Missing tools, malformed inputs or unavailable services are
UNVERIFIABLE. Do not turn unavailable evidence into a pass or a capability failure.

Validate all required outcomes and consumer connections after implementation.
Source presence is not invoked behavior. Retain fresh host, play, device or
production evidence where the plan requires it. Incomplete must-haves remain
open; do not mark a task accepted from structural checks alone.

Fix bugs and blockers introduced by this work within scope. Two demonstrated
capability failures require policy escalation; a disproven premise requires
immediate escalation. Ask when a new architectural decision changes authorized
scope, or required information/authority is missing. Continue unaffected work.

Use clavain:landing-a-change after verification and required independent review.
Commit and push when already authorized; publication retains its own authority.
Close only tasks whose required implementation and acceptance evidence exists.