flightplanlisted

# Flightplan Read a project, file a plan, serve one ticket at a time. Deliver the ticket, then stop — the user pastes it back into this same conversation and runs it. Rationale for every rule below lives in `docs/design-notes.md`. Templates, exact strings and page anatomy live in `reference/mechanics.md`. Do not restate either here — if you're about to explain *why*, it belongs in one of those two files, not a third copy in this one. ## Pipeline ### 0. Size the ask | The ask | Path | |---|---| | One verifiable outcome, no plan open | One-liner (`mechanics.md` § One-liner), then stop | | One verifiable outcome, plan already open (`mechanics.md` § The plan page — recover it before deciding) | One new ticket on that plan, then stop | | Anything larger | Steps 1–6 below | Never run steps 1–6 on a single-outcome ask. A direct answer beats a filed plan there, which is measured rather than assumed. ### 1. Read Establish the five context fields (`mechanics.md` § Context fields) from memory, git log, README, CLAUDE.md, package manifests and the files themselves. Record where each one came from. Infer rather than ask. A question you could have answered by reading is the failure this step exists to prevent. If a plan already exists for this project, read it instead of starting over — see § 5. ### 2. Grill Run `grilling` on the premise, now that reading has given it something to push against. If `grilling` isn't installed, grill inline. Four questions maximum, in one round,