catu-ai/harness-execute

Harness Execute

Purpose

Use this skill after plan approval to drive the repository from active work to an archived, merge-ready candidate.

ALWAYS use harness-execute whenever harness status resolves a current approved tracked plan and state.current_node is still in plan or execution/..., or the archived candidate still needs publish follow-up before human merge approval. That includes fresh sessions, resumed sessions after compaction, and pick-up work where the safest next move is to follow the current plan instead of improvising a new workflow.

The controller agent stays in harness-execute for the whole execution loop, including review orchestration. Do not switch the controller into harness-reviewer; that skill is only for spawned reviewer subagents assigned to specific review slots.

harness-execute starts only after plan approval is explicit. If the current plan is still waiting for approval, stop at the plan boundary, get human approval, and record it with harness plan approve --by human before trying harness execute start.

Run harness status at controller checkpoints, not just once per session:

• at start or resume
• before marking a step done
• after each review aggregate
• before trusting later-step or finalize progression after warnings, repair, or review follow-up

Routine review progression is controller-owned. Once the approved plan reaches an ordinary step-closeout or finalize-review boundary, the controller should start that review flow without asking the human to micromanage it.

Before high-risk transitions, run a short controller self-check instead of trusting momentum. Use the phase-based checklist in controller-truth-surfaces.md at these moments:

• before starting a review round
• before aggregating a review round
• before archiving
• before merge-sensitive publish or land handoff work

For delta review, use a real git commit anchor. The detailed controller dispatch fields, anchor guidance, and reviewer-resume rules live in review-orchestration.md.

Keep exactly one active review round at a time. The detailed review rules live in review-orchestration.md.

For behavior-changing work, default to Red/Green/Refactor TDD. Only skip TDD when it is genuinely impractical, and record the reason in the step's Execution Notes.

Start Here

1. Run harness status.
2. If harness status points to a current tracked plan that is already approved for execution, stay in harness-execute and open that plan from plan_path. Active work uses a tracked plan even when the profile is lightweight; only archived lightweight snapshots move into .local/. If status still resolves to plan, do not start execution until approval is explicit and harness plan approve --by human has been recorded.
3. Identify the active or next plan step.
4. Use the status output to answer four questions:
   • which tracked plan is current
   • which current_node the worktree is currently in
   • which step or finalize phase is active or next
   • whether local state already shows review, evidence, or land work in flight, and whether live remote handoff observations are guiding the next action
5. If harness is unavailable or resolves to the wrong binary, first follow the repository's documented setup path. If no setup path is documented, ask the human to install or expose the correct harness command.
6. Read only the references needed for the current part of the loop.

Node Hints

• plan
  • wait for approval or update the plan if scope changed before harness plan approve --by human and harness execute start
• execution/step-<n>/implement
  • continue the current step, fix review findings, or mark the step done once the slice is genuinely complete
  • rerun harness status before marking the step done so the next action reflects whether review, repair, or a warning-driven follow-up is due
• execution/step-<n>/review
  • review is in flight; aggregate or wait for reviewer submissions rather than continuing implementation blindly
• execution/finalize/review|fix|archive
  • the step list is done and the branch is in closeout, review, or archive-prep work
  • treat execution/finalize/review as a continuation state: start or aggregate finalize review as the status guidance indicates instead of stopping to ask the human whether routine review closeout should happen
• execution/finalize/publish
  • the plan is archived, but publish, CI, or sync evidence still needs work
  • for lightweight work, keep the repo-visible breadcrumb requirement in view while driving the candidate toward await_merge
  • use harness status remote handoff facts as the first orientation surface; status may observe the recorded PR, but only evidence commands move the archived candidate toward await_merge
• execution/finalize/await_merge
  • the archived candidate is merge-ready; stay in execute until explicit human merge approval switches the controller into harness-land
  • if status warns that live remote facts drifted after local evidence was recorded, repair or refresh the candidate before treating it as still merge-ready

Reference Guide

• Read step-inner-loop.md when implementing or validating the current plan step.
• Read review-orchestration.md whenever a review round is active or about to start.
• Read publish-ci-sync.md when publish, CI, or remote-sync work becomes relevant.
• Read closeout-and-archive.md before any archive attempt.
• Read controller-truth-surfaces.md whenever you are about to cross a high-risk controller boundary.

Exit Criteria

Execute is done when:

• the plan is archived
• harness status resolves state.current_node to execution/finalize/await_merge
• durable closeout summaries are written into the tracked plan

Do Not

• Do not ask the human to micromanage routine execution once the plan is approved.
• Do not start execution from the raw task request alone; the newly written tracked plan still needs explicit approval.
• Do not ask the human whether routine step-closeout or finalize review should start once harness status and the tracked plan make the next review action clear.
• Do not submit reviewer results from the controller thread or impersonate a reviewer slot yourself. Reviewer submissions belong to bounded reviewer subagents using harness review submit --by <reviewer-name>.
• Do not bypass node or review gates just because the next action feels obvious.
• Do not skip TDD for behavior changes without documenting why the usual Red/Green/Refactor loop was not practical.
• Do not rely on chat memory when harness status, the tracked plan, or local artifacts can tell you the truth more directly.
• Do not archive based on memory alone; use the current plan plus .local artifacts.