# Executing Plans

> Use when an approved implementation plan will be executed inline in a separate session with batch checkpoints

- Skill: `mrlyk/executing-plans` (Agent Skill)
- Install (CLI): `npx skillmds@latest add mrlyk/executing-plans`
- Raw SKILL.md: https://api.skillmd.com/api/skills/mrlyk/executing-plans/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: mrlyk (https://skillmd.com/u/mrlyk)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/mrlyk/executing-plans

---


# Executing Plans

Execute an approved Full plan on the main thread, serially, in the single task worktree. Tasks run in `depends_on` topological order. task.json is the progress source, `superharness:test-driven-development` supplies the implementation discipline, and all review waits for the shared final check. Lite remains its separate serial route in `superharness:go`.

**Announce at start:** "I'm using the executing-plans skill to implement this plan."

## Load and Resume

1. Read task.json, prd.md, contract.md, and plan.md.
2. Review the plan for blocking gaps before editing.
3. Confirm the worktree and branch are isolated and inspect current git status/diff/log.
4. Resume at the first task whose status is not "completed". Do not rerun completed tasks' focused verifications — the finishing gate covers the whole set once at the end.
5. If a task is already `in_progress` and the checkout is dirty, inspect its diff and focused verification, preserve the edits, and continue as a recovery agent. **Never reset or stash** recovery work.

## Execute Each Task

For each task in dependency order:

1. Confirm its Outcome, Files/Modules, Public Seams, Behavior Slices, Dependencies, Focused Verification, and Commit Intent.
2. Run `superharness task item {task-id} {task-number} start`.
3. Invoke `superharness:test-driven-development`. For each `tested` behavior slice, expose one seam through one failing behavior test, run RED, add the minimum implementation, then run GREEN. Confirm each `verified` slice through its declared gate instead of a dedicated test.
4. Run the task's focused verification, commit only that task's scope with an exact pathspec (`git commit --only -- <files>`), resolve the full SHA, and record `superharness task item {task-id} {task-number} complete --commit {full-sha}`.

There is no per-task reviewer and no per-task E2E checkpoint. Stop for missing context, unexplained failures, or unclear edit ownership; record the corresponding task item status before returning control.

## Batch Checkpoint

After three to five completed tasks, report:

- completed task ids and commits;
- focused commands with observed results;
- the next pending task;
- unresolved concerns.

The batch checkpoint is a user visibility boundary. It does not transition the workflow to check and does not create a review artifact.

## Shared Final Check

When every task item is completed:

1. Run `superharness task transition {task-id} check` once.
2. Follow `superharness:subagent-driven-development`'s Final Check exactly: shell preflight, then dispatch the Spec axis and the Standards axis `check` agents in parallel and present both reports separately.
3. Invoke `superharness:finishing-a-development-branch` for the single fresh final verification, the review discipline recorded in `verification.md`, and the completion flow.

## Red Flags

- Editing a task before the current `tested` slice's RED demonstrates the missing behavior
- Writing a dedicated test for a `verified` slice, or silently skipping a `tested` one
- Updating task item state by hand instead of `superharness task item`
- Dispatching a reviewer between tasks
- Resetting or stashing recovery work
- Entering final check with pending, blocked, or context-needing task items