Agent-Harness-Kit: Skill for Claude Code

Graph execution

Apply ../../../docs/ADAPTIVE-EXECUTION.md: lane and assurance are orthogonal; resume probes real state before artifacts; same-context nodes use inline spec/transition; packets exist only for actual separate consumers; planned units target 15–30 active minutes; tests climb the five-rung ladder; and in-scope technical recovery needs no fresh approval.

After verification, for assurance: light|full only, automatically launch the distinct reviewer in a fresh context—prefer a proven subagent—and send only the pinned SPEC-led packet, never prompt or conversation memory. Same-context review is invalid.

Every technical event is persisted in a new TASK-GRAPH.md revision before it is reported: dispatch/start, material progress, dependency changes, block/unblock, remediation, completion, lease/context changes, and newly ready nodes. Never record technical movement only in PENDING.md; revise pending state only for a related human action or macro outcome and backlink the new graph revision. Before graph creation or dispatch, follow writing-plans: non-simple work requires a ready implementation plan and every node requires a self-contained executable task spec. A specialist executes that spec; contradictions, missing decisions/dependencies/paths, unevaluable acceptance, or materially oversized work return needs-replan rather than improvisation. Code behavior and bug-fix tasks also load test-driven-task; completion requires meaningful RED before production code, GREEN with the same focused test, and proportional regression evidence. When automatic model routing is human-approved, do not stop at model_tier: resolve the current Codex model/effort, pass both into the actual task/message/subagent dispatch, and pin adapter confirmation through harness.model-dispatch/v1 before activation. Same-context self-switch claims and silent host defaults are invalid.

For a first-call status or resume, follow ../../../harness/playbooks/status-resume.md before any broad scan. PENDING.md owns human actions and macro incomplete areas; TASK-GRAPH.md owns technical order, dependencies, and execution. For user-pending questions, report human-owned items first and group human/technical pending items by workstream. Otherwise read only the relevant neutral playbook: discovery-to-graph.md, task-dispatch.md, context-routing.md, model-routing.md, or parallel-execution.md. Load the pinned context revision, pending-work authority, local graph neighborhood, task brief, scoped rules, approved capabilities, approved model-routing revision, and linked execution budget. Prefer the node's read_set over a broad scan, lease only its write_set, and use its impact_set for proportional regression checks. Verify derived relationships in source and record context_provenance; an approved, fresh Graphify index may enrich these fields but never becomes a second operational graph. Keep different workstreams in distinct execution contexts except a bounded integration node; create visible threads or internal subagents only when current capability evidence permits it. Respect dependency readiness, exclusive write sets, isolation evidence, routing escalation triggers, and orchestrator-only graph mutation. Enforce ../../../docs/EXECUTION-BUDGET.md: reconcile the goal-lineage counters before another cycle or context expansion; never reset them by changing model, agent, task, review, decomposition, or session; at a ceiling persist evidence and stop-and-replan. Enforce ../../../docs/REVIEW-ROUNDS.md for every dispatched reviewer: one initial review, at most one focused remediation review, and no third loop. Follow ../../../docs/STATUS-AND-COMPLETION.md and ../../../docs/contracts/STATUS.md: explicit status views and milestone closeouts label current stage, progress, continuing-without-user-action work, human and macro pending items from PENDING.md, active/ready/blocked nodes and technical pending work from TASK-GRAPH.md, blockers, next action, and inspectable paths. Routine progress updates may be concise result/evidence, human action, and next action; do not reread artifacts or create a full status form without a state/status need. Mark passing work completed, report it, release ownership, dispatch only nodes whose product and technical gates pass, and run declared assurance review automatically as non-blocking work. Follow ../../../docs/ACCOMPANIED-DELIVERY.md: demonstrate client milestones and genuinely await approval before affected expansion. Every new spec has explicit completion conditions, mirrored in graph acceptance_criteria; current criterion-level, required TDD, and affected-flow evidence must pass before technical completion. Write durable results through shared templates; do not store state inside .agents/.