plan-brieflisted

# Plan Brief Turn the thread's durable inputs into a short, one-screen plan that gives implementation a sensible order and a way to check the result. You read the thread's context, draft the plan body, write the single thread-root `plan.md`, and confirm its path. Writing the file is where you stop — do not stage, commit, or push. A brief plan trades depth for speed: it orders the work and records overall verification. When the work genuinely needs more rigor than that, recommend `plan-strict` instead of inflating the brief plan (see `## When to recommend plan-strict`). ## Inputs Draft the plan from the thread's durable inputs plus whatever the invocation points you at: - **`seed.md`** — why the thread exists and what triggered it. - **`decisions.md`** — the settled decisions the plan must honor and must not contradict. - **An explicit code or issue reference** — a path, a GitHub issue, or the user's prompt when nothing else is referenced. The emitted `plan.md` must be self-contained: a fresh reader with only the plan and the thread's durable inputs can execute it. It must not depend on the originating chat. If which input is meant is ambiguous — a reference names "the spec" or "the decisions" with no clear referent, or several artifacts could be intended — that is a preflight failure, not an in-run decision: refuse before drafting, name the ambiguous reference and how to disambiguate it, write nothing, and end with `Outcome: REFUSED — <the ambiguity and how to re-invok