executing-planslisted

# Executing Plans Use this skill to turn an approved plan into a checkpointed execution loop. The goal is not to run through every task as fast as possible; the goal is to make each task independently auditable, resumable, and verified. ## Preconditions - If the input packet is part of a PM orchestration flow, `execution_confirmed` must be present and must match the current `plan_revision`. - The plan must list concrete tasks, dependencies, `files_involved`, assumptions or explicit unknowns, acceptance checks, and verification commands or checks. - The plan must not contain placeholders such as `TBD`, `TODO`, or `to be decided`. - User-provided paths, current editor files, attachments, and priority files must be consumed before broad search. If any precondition fails, return `NEEDS_CONTEXT`, `NEEDS_USER_INPUT`, or `BLOCKED` instead of executing from guesses. Use `NEEDS_USER_INPUT` only when human input or approval is required; missing repository/task evidence is `NEEDS_CONTEXT`. ## Execution Loop For each ready task, follow this exact order: 1. `PICK`: identify task id, target files, dependencies, success criteria, assumptions, tradeoffs, and the simplest viable approach. 2. `READ`: before code edits, inspect the target file's public surface/exports, the immediate caller or callee, and obvious shared utilities or local patterns. 3. `EXECUTE`: make the smallest diff inside the frozen file set. Do not add speculative features, single-use abstractions, or adjacent cleanup