Plan

• HARD RULE: call EnterPlanMode as your FIRST tool call on "plan", "plan this", "make a plan", or any variant: no Read, Grep, Glob, Bash, Edit, or Write before it. The hooks plugin's force-plan-mode.mjs UserPromptSubmit hook injects this directive; it is non-negotiable.
• On "plan", "plan this", "make a plan", or any variant: ENTER PLAN MODE. Write the plan in the plan file. NOT in chat. NOT in a table. NOT in a code block. Plans in chat are worthless; the plan file is the only place plans belong.
• NEVER skip plan mode because "it's simple enough". If the user said plan, they mean plan.
• Self-trigger (plan without being asked) when: a CI failure has multiple root causes, the first fix attempt failed, or you're about to touch 3+ files.
• A plan is NOT a list of edits. A plan MUST run in order:
  1. Research: what do I need to verify before touching anything? What docs to check? What commands to run? What assumptions need proof?
  2. Validation: how will I verify each step worked? What does success look like? What are the failure modes?
  3. Implementation: only AFTER research and validation strategy are defined.
• NEVER jump to implementation. Research first, define validation criteria, then plan the changes.
• Every assumption in the plan must have a verification step. "I think X works" is not a plan; "verify X by running Y, then proceed" is.
• Plans must contain survival context (test URLs, route paths, IDs, exact verification steps) because conversation context doesn't survive resets.
• When incorporating a sub-plan, INCLUDE by reference: add **Full detail:** plan-name.md and keep the sub-plan file intact. NEVER rewrite as a lossy summary. The sub-plan IS the detail.
• When told to "update the plan," UPDATE THE PLAN FILE. Not a chat summary. Not a mental note. Open the plan file and edit it.
• Before giving a multi-step procedure, compare each step against failures already hit this conversation; if a step repeats one, stop and redesign.
• If new evidence shows an approved-plan assumption is wrong, STOP; update the plan file first, then continue referencing it.
• NEVER include commit or push steps in a plan; git operations are the user's business.