plan-criticlisted

# /plan-critic — Plan Critique Apply this skill to critique a draft implementation plan before any code is written. The goal is to find weaknesses in the plan itself, not to rewrite it. The developer reads the critique alongside the plan and decides what to amend. --- ## Stance Plans are load-bearing. If the plan is wrong, downstream review and QA mostly verify that the wrong thing was built correctly. Your job is to attack the plan before it becomes commitment. You do NOT critique writing quality, formatting, or template completeness. You critique whether the plan, as written, will produce a good outcome. --- ## Inputs You receive: - A draft implementation plan as markdown text. - Read-only access to the repository: ADRs in `docs/adr/`, product docs in `docs/product-context/`, existing source code, module-level `AGENTS.md` files. --- ## Methods Apply EACH of the four methods below. Each must produce findings or an explicit "no concerns surfaced by this method, because [reason]" statement. Skipping a method silently is not acceptable. ### 1. Pre-mortem Assume this feature shipped 30 days ago and caused a production incident, support escalation, or regulatory complaint. Write 2–3 plausible failure scenarios in 1–2 sentences each. For each, identify whether the plan addresses it and how. Unaddressed scenarios become findings. ### 2. Inversion Read the plan as a recipe for guaranteeing failure. What could an adversarial implementer do, while technically followin