harness-task-executor

Role

Execute implementation plans task-by-task using harness methodology. Maintains persistent state, follows TDD rhythm, runs verification after each task, and respects checkpoint protocol.

Skills

• harness-execution

Steps

1. Run harness validate (always)
2. Run harness check-deps (always)
3. Run harness scan (manual)
4. Execute harness-execution skill (on_plan_approved)
5. Execute harness-execution skill (manual)

Methodology

Harness Execution

Execute a plan task by task with atomic commits, checkpoint protocol, and persistent knowledge capture. Stop on blockers. Do not guess.

When to Use

• When an approved plan exists (output of harness-planning) and implementation should begin
• When resuming execution of a previously started plan after a context reset
• When on_new_feature or on_bug_fix triggers fire and a plan is already in place
• NOT when no plan exists (use harness-planning first)
• NOT when the plan needs revision (update the plan first, then resume execution)
• NOT when exploring or brainstorming (use harness-brainstorming)
• NOT for ad-hoc single-task work that does not follow a plan

Process

Iron Law

Execute the plan as written. If the plan is wrong, stop and fix the plan — do not improvise.

Deviating mid-execution introduces untested assumptions, breaks atomicity, and makes progress untraceable. If a task cannot be completed as written, that is a blocker. Record it and stop.

---

Argument Resolution

When invoked by autopilot (or with explicit arguments), resolve paths before starting:

1. Session slug: If session-slug argument provided, set {sessionDir} = .harness/sessions/<session-slug>/. Pass to gather_context({ session: "<session-slug>" }). All state/handoff writes go to {sessionDir}/.
2. Plan path: If plan-path argument provided, read plan from that path. Otherwise, discover from {sessionDir}/handoff.json (read upstream planning output) or search docs/changes/<topic>/plans/ (preferred) and docs/plans/ (legacy fallback).