Pre-Implementation Planning

Research first, design second, build third. Applies to code, skills, doc pipelines, and audit tools alike — "production" below means wherever the thing runs for real (a repo, a teammate's machine, a shared doc someone else reads).

When to Use

Run /pre-implement before any task that takes more than ~30 minutes, touches more than 2-3 files, involves external services, has unclear requirements, or could be built more than one way.

Skip for: typo fixes, single-line changes, debugging probes, tasks explicitly defined with no ambiguity. When in doubt, run it.

Step 0: Consume What Already Exists

Do not re-ask what's already decided.

• Grill record? Check brainstorms/ for a /grill-me record on this task. Its decisions are inputs, not open questions. Only surface a question if the record is silent or contradicts the repo.
• Prior plan? If a plans/ dir for this task exists from an earlier session, a plan is a point-in-time snapshot — re-validate it against the current repo before executing (files it names still exist, assumptions still hold, nothing shipped in between). Never execute a stale plan on trust.

Prerequisites