da-fix-planlisted

# /da-fix-plan — decide what not to fix, then order the rest A review produces findings. This turns them into a plan, and **its primary job is subtraction.** > A reviewer prompted to find gaps **will report some even when the work is sound**, because that is > what it was asked to do. Chasing every finding leads to over-engineering: extra abstraction layers, > defensive code, and tests for cases that cannot happen. So the failure this skill exists to prevent is not "a finding got missed". It is **acting on all of them**. A plan that accepts every finding has not triaged; it has transcribed. **Read-only until the plan is agreed.** Produce the plan, show it, and stop. Fixing happens after. ## Preconditions | Condition | If unmet | |---|---| | A review report exists — in this conversation, at a path, or on a PR | **Stop.** Ask which review. Never plan against remembered findings. | | You can tell what the change was *supposed* to do — a spec, a plan, a PR description, or the user saying so | **Ask.** Without it you cannot separate "the code is wrong" from "the reviewer wanted something else", and that distinction is most of the work here. | | The findings carry locations | Continue, but mark any finding you cannot locate as **unactionable** rather than guessing at one | ## Position in the workflow | Upstream | This skill | Downstream | |---|---|---| | `/da-review-all`, `/code-review`, `/find-bugs`, or a human review | `/da-fix-plan` | `/executing-plans` on the accepted s