# Plan Implement

> Explicitly selected plan implementation lifecycle with an implementation log, proof freshness, and continuing plan-backed review. Use when the user chooses $plan-implement or binding task instructions require it. Asking to implement or finish a plan alone does not select these extra workflow duties.

- Skill: `aelaguiz/plan-implement` (Agent Skill, multi-file: 9 files)
- Install (CLI): `npx skillmds@latest add aelaguiz/plan-implement`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aelaguiz/plan-implement/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: aelaguiz (https://skillmd.com/u/aelaguiz)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/aelaguiz/plan-implement

---


# Plan Implement

Use this workflow only after explicit selection as `$plan-implement` or a
binding task instruction requiring it.

The job is to go faster by wasting less motion: fewer repeated code reads,
fewer duplicate checks, fewer late review surprises, and less context loss
after compaction.

This is a doctrine-only, prompt-first implementation skill. It must not become
a deterministic harness, runner, controller, workflow engine, checklist
executor, test scheduler, CI verifier, code review subprocess launcher, scorer,
state machine, or script-backed completion judge.

## Use When

- The user asks to implement an existing plan, plan phase, plan section,
  checklist, issue-body plan, or documented implementation scope.
- The user wants implementation to stay aligned with plan quality doctrine,
  plan-audit findings, review state, and proof freshness.
- The user wants progress to survive compaction without rereading the same
  plan and code surfaces repeatedly.
- The user wants native subagents or parallel-agent features used for
  independent read, review, or safe low-collision implementation slices when
  the current coding harness supports them.

## Do Not Use When

- The plan does not exist yet. Use the repo's planning skill or normal planning
  flow.
- The user wants a plan audited before implementation. Use `plan-audit`.
- The user wants code already written for a plan reviewed without new
  implementation. Use `plan-audit implementation-audit`.
- The user wants a generic branch, diff, or PR reviewed. Use the host agent's
  normal review response.
- The user explicitly wants delegated external workers, resumable child
  sessions, or plan-wide worker orchestration with the parent acting as
  conductor and cynical reviewer. Route to `conductor` under the shared
  agent policy.
- The user wants one explicit external worker. Route to `agent-delegate` under
  the shared agent policy.

## Non-Negotiables

- The plan remains the source of truth. Do not create a second plan in the
  worklog.
- The implementation log is a speed and resumability artifact. Keep it short
  enough for the next agent to read quickly.
- The plan audit log owns `PLA-*` and `IMP-*` review findings. Do not turn it
  into an implementation diary.
- Update artifacts at meaningful boundaries, not after every micro-edit.
- Choose depth-first slices: make one narrow approved plan truth real, review it
  while warm, verify impact, then advance through breadth already authorized by
  the plan. Depth-first sequencing is not permission to widen scope.
- Proof freshness matters. Reuse passing proof until a real invalidator makes
  it stale; run checks when the plan, changed code, impacted behavior, or a
  review finding gives a reason.
- Apply `../_shared/agent-orchestration-policy.md` whenever implementation
  uses child agents.
- Use a coverage-led set of children for broad independent mapping, review, or
  safe low-collision implementation work when useful. Start each new
  independent child as a clean same-host native child when the active host
  supports it; keep lenses and owned paths non-overlapping and bound fanout by
  host slots, shared-file or shared-state collision risk, and parent
  integration capacity.
- Use bounded or full inherited context only for a named decision that exists
  solely in chat. Prefer plan, audit-log, implementation-log, and code paths
  over inheriting the parent's framing or completion story.
- Use the strongest read-only capability available for mapping and review
  children, also tell them not to edit or write, and have the parent compare
  repository status and diffs with the pre-dispatch state before accepting
  their evidence.
- Children may use native sub-agents within authorized scope and host limits; they
  may not start external agents.
- The parent owns child accounting, evidence spot-checking, deduplication,
  integration, finding scope disposition, source-of-truth updates, proof
  claims, and final completion claims.
- Resume the exact implementer child for an accepted repair in its owned
  scope. Every independent recheck uses a new clean critic rather than the
  implementer's or an earlier critic's context.
- Do not manually spawn separate coding-harness executables such as `codex`,
  `claude`, `agent`, `grok`, or `kimi` for ordinary acceleration. This lightweight lane may
  still hand an explicitly requested external worker or conductor to
  `agent-delegate` or `conductor` under the shared policy; external
  execution is a deliberate route, not a blanket ban.
- Do not claim a plan item complete from logs or checkboxes alone. Read code
  anchors and confirm the outcome is true.
- Apply `../_shared/scope-and-convergence.md`. Before the first edit,
  recover the human baseline, initial minimal convergence closure, sign-off
  boundary, and explicit later human approvals. If a legacy plan cannot support
  a defensible boundary, stop for one human scope decision.
- A warm review, subagent, test, worklog, or plan edit cannot expand scope.
  Give every material finding a shared scope disposition. Only `authorized` and
  `approved-convergence-required` enter required implementation work; a newly
  discovered adjacent path is `new-scope-needs-human`, and already-built excess
  is subtraction work.

## First Move

1. Read `references/artifact-contract.md`.
2. Read `references/progressive-implementation-loop.md`.
3. Read `../_shared/scope-and-convergence.md`.
4. Read `../_shared/agent-orchestration-policy.md` before creating or
   resuming any child.
5. Resolve the plan artifact, requested scope, stop boundary, repo root, audit
   log path, and implementation log path.
6. Read the plan, existing plan audit log if present, existing implementation
   log if present, local instructions, and current worktree state.
7. Identify the next narrow depth-first slice and the proof or review likely to
   matter.
8. If the scope is broad, decide whether native children can save real time
   for independent mapping or review slices.

## Workflow

1. Resolve and restate the active plan scope. Do not silently widen.
2. Build the local truth cache: relevant plan anchors, code areas read,
   comparable patterns, side doors, proof already fresh, proof likely needed,
   and review lenses likely to matter.
3. Create or update `<PLAN_STEM>_IMPLEMENTATION_LOG.md` for non-trivial
   file-backed implementation scopes.
4. Implement the smallest useful depth-first slice using the repo's existing
   patterns and owner paths.
5. Review while the work is warm using plan-audit implementation-audit lenses.
   When children save time, use new clean native critics for independent
   read-only lenses. Send accepted repairs back to the exact implementer that
   owns the code, then use a different new clean critic for an independent
   recheck.
6. Run, assign, or reuse proof based on impact and freshness. Do not rerun
   checks only because prior context was forgotten.
7. Update the owning artifact: plan for source-truth changes, audit log for
   `PLA-*` or `IMP-*` findings, implementation log for resumability.
8. Advance to the next already-authorized slice only after the prior slice's
   code, plan, review, and proof state agree. New breadth requires human approval
   and re-approval.
9. At the requested stop boundary, perform a final lightweight plan-backed
   implementation check and report remaining gaps plainly.

## Output Expectations

Return concise implementation status:

- active plan scope and stop boundary
- implementation log path and audit log path when applicable
- what changed
- what plan items moved state
- proof run, supplied, reused, stale, or intentionally not run
- review findings opened, repaired, rejected, or still open
- relevant code read and relevant code still unknown
- next useful move

For ongoing work, prefer a short progress update over a full report. The
implementation log carries detail so the chat can stay readable.

## Reference Map

- `references/artifact-contract.md` - plan, audit-log, and implementation-log ownership
- `references/progressive-implementation-loop.md` - ordered implementation loop
- `references/proof-freshness.md` - proof reuse, invalidators, and rerun triggers
- `references/continuous-review.md` - warm plan-backed review during implementation
- `references/native-subagent-contract.md` - native subagent use and prompt shapes
- `../_shared/agent-orchestration-policy.md` - transport, starting context,
  continuation, isolation, topology, and parent-integration policy
- `references/output-contract.md` - progress and final report contracts
- `references/examples.md` - examples and anti-examples