harness-planner

Role

Create detailed implementation plans from approved specs using harness methodology. Breaks work into atomic tasks with explicit file paths, dependency ordering, and checkpoint placement. Writes plans and handoff context for execution.

Skills

• harness-planning

Steps

1. Run harness validate (always)
2. Run harness check-deps (always)
3. Execute harness-planning skill (manual)

Methodology

Harness Planning

Implementation planning with atomic tasks, goal-backward must-haves, and complete executable instructions. Every task fits in one context window.

When to Use

• After a design spec is approved (output of harness-brainstorming) and implementation needs planning
• When starting a new feature or project needing structured task decomposition
• When on_new_feature or on_project_init triggers fire and the work is non-trivial
• When resuming a stalled project that needs a fresh plan
• NOT for small tasks (under 15 minutes, single file — just do it)
• NOT for problem exploration (use harness-brainstorming)
• NOT when a plan exists and needs execution (use harness-execution)

Process

Iron Law

Every task in the plan must be completable in one context window (2-5 minutes). If a task is larger, split it.

A plan with vague tasks like "add validation" or "implement the service" is not a plan — it is a wish list. Every task must contain exact file paths, exact commands, and complete code snippets.

---

Rigor Levels

The rigorLevel is passed by autopilot (or set via --fast/--thorough flags). Default is standard.

Phase	fast	standard (default)	thorough
SCOPE	No change.	No change.	No change.
KNOWLEDGE	Skip entirely.	Run detect; fix if gaps found.	Run detect; fix if gaps found.
DECOMPOSE	Skip skeleton. Full tasks directly after file map.	Skeleton if tasks >= 8; full tasks if < 8.	Always skeleton. Require approval before expanding.
SEQUENCE	No change.	No change.	No change.
VALIDATE	No change.	No change.	No change.