plan-authorlisted

# Plan Author Skill Turn a short brief into a complete `plan.md`. This skill is the inverse of `plan-review`: it treats the eleven plan-review categories as generative targets, so the plan it writes is already structured to pass a pre-flight review. The output is opinionated — it makes decisions and records genuine unknowns as numbered Open Questions, never as vague "TBD". ## Step 1: Gather the Brief The brief is the seed. Find it in this order: 1. If the argument is a readable file path, read it in full. 2. If the argument is inline prose, use it directly. 3. If no argument was given, scan for a seed: `**/README.md`, `**/docs/notes/*.md`, `**/IDEA.md`, `**/BRIEF.md`. Read the best candidate. Assess whether the brief is thick enough to ground a plan. It is too thin if you cannot answer all three of: (a) what is being built, (b) who or what consumes it, (c) what "done" roughly means. If too thin, use AskUserQuestion to ask **at most three** scoping questions: the core mission, the single most important hard constraint, and the primary consumer/interface. Do not interrogate beyond three — fill remaining gaps as Open Questions in the plan itself. ## Step 2: Detect and Confirm Plan Type Classify the work — this changes which sections get emphasis: - **Greenfield** — new tool/app from scratch (emphasis: acceptance scenarios, walking skeleton) - **Port** — reimplementing existing code in another language/runtime (emphasis: parity matrix, conformance harness, source metri