harness-exec-plans

Persist complex multi-session tasks as versioned execution plans with verifiable steps and decision logs.

Updated Jun 18, 2026
One-click install
npx skills add https://github.com/zhengguangli/harness-engineering-kit --skill harness-exec-plans-zhengguangli
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: harness-exec-plans
Source: https://github.com/zhengguangli/harness-engineering-kit/tree/main/skills/harness-exec-plans
Command: npx skills add https://github.com/zhengguangli/harness-engineering-kit --skill harness-exec-plans-zhengguangli

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Complex tasks that span multiple context windows or sessions lose all progress when a conversation ends, because only the filesystem survives between sessions. This Skill turns large tasks into version-controlled execution plan files so work can be interrupted, handed off between agents, and resumed without losing goals, decisions, or acceptance criteria. ## Core Features & Use Cases - Versioned Plan Artifacts: Creates structured plan files under docs/exec-plans/active/ with goal, scope, non-goals, steps, decision log, acceptance criteria, and risks, then moves them to completed/ instead of deleting them. - Plan Quality Enforcement: Rejects plans whose acceptance criteria are not mechanically verifiable, whose steps cannot be self-verified within one PR, or that are edited concurrently by multiple agents. - Multi-Agent Handoff: Uses the active/ directory as a shared coordination ledger with owner markers, decision logs, and a tech-debt tracker for blocked or deferred work. - Use Case: A user asks to migrate a frontend build from Webpack to Turbopack across several sessions with multiple agents. The Skill creates docs/exec-plans/active/frontend-build-migration.md, decomposes it into independently verifiable steps, records decisions, and hands off to a verification loop for step-by-step execution. ## Quick Start Ask the agent to create an execution plan for a large refactoring task that will span multiple sessions, and it will write a structured plan file under docs/exec-plans/active/ with verifiable steps and acceptance criteria.

Frequently Asked Questions about harness-exec-plans

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create an execution plan for a large coding task?▼

State the high-level goal and indicate the task is large or spans sessions. The plan-architect agent writes a plan file under docs/exec-plans/active/ with a one-sentence goal, scope, non-goals, verifiable steps, decision log, acceptance criteria, and risks.

When should I use an execution plan versus a lightweight in-chat plan?▼

Use an execution plan when a task may be interrupted, spans multiple sessions, or involves multi-agent handoffs. Use a lightweight in-chat plan for small changes finished in one session, and skip planning entirely for pure documentation or config tweaks.

How do multiple agents collaborate on the same execution plan?▼

Each plan file is edited by only one agent at a time, with the owner noted at the top of the file. On handoff, the current agent commits progress before the next agent takes over, and the docs/exec-plans/active/ directory acts as the shared coordination ledger.

What happens when an execution plan step fails or gets blocked?▼

The step is marked blocked with a root-cause annotation, the plan status is updated, and the blocker is recorded in tech-debt-tracker.md. Recovery options include splitting the step into smaller sub-steps, re-scoping, or waiting on external dependencies.

Why must acceptance criteria be mechanically verifiable?▼

Criteria like "looks good" cannot be checked by a script, command, or screenshot, so the plan is rejected until each criterion is rewritten as a machine-checkable condition such as tests passing, coverage thresholds, or latency limits.

What are the limitations of execution plans for small tasks?▼

Execution plans add disk-based tracking overhead that is unnecessary for single-session changes, one-shot tool calls, or documented runbook procedures. For those cases a lightweight in-chat plan or direct execution is the intended approach.