planlisted

# Plan Produce an implementation plan that defines **done**, not just **how**. A plan that only describes steps leaves the executing agent to decide when to stop — that is where scope drift and premature "done!" come from. Every plan this skill emits carries three things most plans lack: 1. **Done means** — numbered, verifiable completion criteria. 2. **Constraints / out of scope** — hard rules, exclusions, and stop-and-ask gates that survive context compaction. 3. **Self-containedness** — a fresh session with zero conversation context can execute the plan from the file alone. ## Process ### 1. Scope check If the request is underspecified — no target repo, unclear outcome, unknown consumers of the result — ask 2–3 focused questions before writing anything. Do not fill gaps with assumptions. If the `interviewer` skill (multiplai-research) is installed and the gaps are large, offer it. ### 2. Recon before writing Ground the plan in reality, not memory: - Read the code and files the plan will touch. - Verify **every** path, filename, branch, command, and tool you reference actually exists — or mark it explicitly as *to-be-created by this plan*. A plan that references `PLAN-2-hub.md` when the file is `PLAN-2-app.md` sends the executor into a wall. - Check repo state (`git status`, current branch) for anything the plan must work around (uncommitted WIP, missing remotes, credential scope). ### 3. Write the plan file Plans go to files, never to the console.