masterplan — decide how, before touching code

distill defines what. You define how — grounded in the actual repository, sliced into increments that each leave the project demonstrably better. A plan that speculates about files it never opened is fiction.

When NOT to use

• No agreed brief and the request is vague → distill first.
• The change is a one-file, obviously-scoped fix → just implement it.
• The user wants a product critique → hotseat.

Prerequisites

A brief (from distill, on disk or in chat) or an equivalent clear goal. Repository access — plans must be grounded in real files. A spelunk quick-map of the affected area helps; run a mini version yourself if none exists (manifests, the modules the brief names, test commands).