execute-plan

Files (2)

• SKILL.md
• openai.yaml · agents/

SKILL.md (first lines)

# Execute Plan

Implement the plan against the current repository, using the user's prompt to define this run's scope.

## Execution Contract

Use the entire user prompt as the runtime override layer. It may select the full plan, phases, or task IDs; skip or defer work; assign tasks to subagents; reserve checks for a human; change sequencing; add task-specific constraints; or set a stopping point. Apply these overrides before execution and report their effects.

Read the complete prompt, repository instructions, and plan before editing. Treat every plan section as input, including file structure, dependencies, required skills, acceptance criteria, Human Review Focuses, verification, progress state, out-of-scope boundaries, global decisions, and checkpoints. For HTML plans, read the visible semantic content and preserve presentation code when updating the artifact.

If the plan and repository differ, make the smallest evidence-based adaptation and record the affected task IDs. Ask only when a material choice cannot be inferred safely.

## Run Manifest

Before implementation, build a run manifest containing:

- the target repository and run baseline;
- every plan task's scope state, dependencies, acceptance criteria, and verification requirements;
- every planned Human Review Focus;
- existing or previously completed work;
- task ownership by the main agent, a subagent, or a human.

Use these task states:

- `Selected`: included in this run.
- `Completed`: acceptance criteria are satisfied with permitted verification evidence.
- `Skipped`: the user explicitly excluded the task.
- `Deferred`: the task remains planned but is outside this partial run or stopping point.
- `Blocked`: a selected task cannot proceed because of an unmet dependency, missing input, unavailable required capability, or authority boundary.

Preflight completes when every plan task is selected, skipped, deferred, already completed, or blocked.

## Program Design Gate

Before implementing a selected task that introduces or substantially reshapes modules, interfaces, types, file layout, dependencies, or control flow, use the `program-design` skill and obtain explicit approval of the proposed code shape. Group tasks behind one proposal when they share the same design. Small fixes, local implementation changes, and mechanical edits do not require this gate.

Approval of the implementation plan does not satisfy this gate unless the plan already contains an explicitly approved program design that still matches the current repository. If implementation evidence later forces a material deviation, return to `program-design` with the affected delta before continuing.

## Implement And Verify

Execute selected tasks in dependency order while preserving plan boundaries and intermediate working-state requirements.

- Assign disjoint file ownership to concurrent tasks.
- Load skills and references required by a task before starting it.
- Treat plan commit boundaries as checkpoints. Create commits only when the user or plan explicitly requires them.
- Run task-level verification at its boundary and applicable final verification afterward.

Apply task ownership from the user prompt before ownership stated in the plan. For delegated work, follow the `subagent-dispatch` skill, provide self-contained task context, and assign non-overlapping file ownership. The main agent integrates the result and verifies its acceptance criteria. If explicitly required delegation is unavailable, mark the task blocked or request direction instead of silently executing it in the main context.

For a human-owned check, prepare the test or verification artifact and report `Not run`, the ownership reason, and the exact command or manual steps. Keep its result unverified until human evidence exists. When the environment blocks a check, run the next applicable non-destructive check and report the remaining validation gap.

After implementing each selected task, reassess its Human Review Focus against the actual implementation. Keep at most three items and name the narrowest stable file, symbol, screen, workflow, policy, or boundary; the judgment the human should apply; and why agent or automated validation is insufficient. Narrow or add a focus when implementation evidence warrants it. Remove one only when the implementation eliminates the need for that judgment, and record the reason. Update the task in a maintained, writable plan so it shows only the current focus.

A Human Review Focus is an advisory review map. It never becomes a dependency, acceptance criterion, verification result, human-owned check, task state, review gate, or completion gate. Agent reviews do not substitute for the named human judgment, and a human review does not clear or complete the focus. Report findings from any performed human review through the ordinary implementation workflow.

## Complete-Plan Review Gate

Run this gate only after every task in the complete plan is `Completed`. Completing every task selected for a partial run does not satisfy this gate. For a partial run, update plan progress and report the review gate as `Not run` because the plan remains incomplete.

At the final gate, use the `review-implementation` skill with a self-contained implementation packet:

- the complete plan path and final user overrides;
- the full-plan baseline and current diff or commit range covering every task;
- human-owned checks and their current evidence;
- verification evidence and justified deviations.
- explicit task-scoped authorization for Architectural Review, when granted.

The review skill owns reviewer isolation, finding validation, remediation, targeted revalidation, blind rereview, cycle accounting, and escalation. Consume its terminal result as `Passed`, `Blocked`, or `Awaiting architectural-review decision`. A missing required reviewer or review gate cannot produce `Passed`.

## Complete The Run

Recheck every selected task's acceptance criteria against the implementation and fresh verification evidence.

Update progress only when the plan is a maintained, writable execution artifact:

- `Current status`: `Completed` only when every plan task is completed; `Blocked` when selected work cannot proceed; otherwise `In progress`.
- `Started on`: set when the first task begins.
- `Completed on`: set only with overall `Completed`.
- `Last executed tasks`: record executed task IDs newest first.
- `Current blocker or next focus`: record the blocker or next dependency-ready task.
- `Unplanned necessary work`: record required work outside the original task list.

Preserve archival plans unchanged and represent partial completion without marking the overall plan completed.

Report concisely:

- completed, skipped, deferred, or blocked task IDs;
- changed files and behavior;
- verification with `Passed`, `Failed`, or `Not run` status;
- plan deviations;
- spec-compliance, code-quality, and authorized architectural findings addressed;
- Human Review Focuses grouped by task, including focuses a human already reviewed;
- Human Review Focus Changes with the task ID and reason, only when planned focuses changed;
- remaining human checks, blockers, or follow-up work.

From rakaadi/agent-kit, MIT.

More from rakaadi/agent-kit