Planning

The step people skip, and the one that determines whether everything after it works.

When to plan

Task	Plan?
One-line fix, obvious cause	no
3+ steps	yes
Any architectural decision	yes
Touching auth, money, data, migrations	yes, written
You cannot state "done means…" in one sentence	yes — that is the signal

The chain

idea → spec-workflow → implementation-planning → build → progress-audit → completion-plan
             ↑                                                   ↓
      harvest-questions ←──────── open questions ────────────────┘

Step	Skill	Produces
Clarify	spec-workflow	A spec with acceptance criteria
Interrogate	skills:grilling	Assumptions challenged, decisions made with you
Detail	implementation-planning	Files, schema, contracts, tests — build-ready
Estimate	ai-time-estimates	Effort in agent-sessions, with a band
Track	progress-audit	Verified completion, measured against wired code
Scope the rest	completion-plan	Backlog with a plan and a ticket per item

The interview

skills:grilling is the one to reach for on anything ambiguous. It maps the work as a decision tree and asks a whole frontier per round — every question whose prerequisites are settled — each with its recommended answer, then waits.

grill-with-docs runs the same interview and leaves ADRs and a glossary behind, which is what you want when the decisions need to survive the conversation.

Rule of thumb: if a plan lists no rejected alternative, no alternative was considered.

Estimating

Default estimates are wrong in both directions for agent work, and the errors do not cancel.

• Overestimated: mechanical volume — boilerplate, CRUD, test scaffolds, renames across 200 files. 5–20× faster.
• Underestimated: deciding what to build, waiting for access, review cycles, integrating with something undocumented, and the loops where the agent is confidently wrong.

Estimate in sessions, not hours, and always give a band. ai-time-estimates carries the full method.

Spec-driven development

For anything where "what should this do" is genuinely open, look at github/spec-kit (★125k) — /specify, /plan, /tasks as a formal loop. This kit's spec-workflow covers the same ground more lightly; spec-kit is worth it when several people must agree on the spec before code exists.