pm-decision-quality-audit

Decision Quality Audit Skill

What this skill changes vs. default behavior

By default, Claude evaluates a decision by its result — if the launch worked, the call was good — and accepts a confident rationale at face value. It rarely separates the quality of the reasoning from the luck of the outcome, checks whether the deliberation matched how reversible the decision was, names the bias quietly driving the choice, or asks whether failure modes were surfaced before commitment. This audit forces four things: every finding names the violated principle; decisions are judged on the reasoning available at the time, not hindsight; the bias or process gap is named explicitly with a structural countermeasure; and findings come severity-rated by decision damage and reversibility with a concrete fix.

This is an evaluative skill: it auto-runs whenever a significant product decision, decision log, or retrospective is being reviewed — and as a validation step after a consequential call is made.

Scope discipline. When invoked directly (the user named this audit), review only this concern — don't pull in sibling audits. It runs alongside other lenses only when the pm-product-review orchestrator or a generative skill calls it under docs/orchestration-policy.md, where it sits in an artifact-specific lens — offered (for high-stakes, hard-to-reverse decisions). Explicit scope always wins.

The framework — what to check and what a violation looks like

1. Process judged on its merits, not the outcome (resulting)

"Resulting" is grading a decision by what happened next. But outcomes are shaped by forces the team didn't control (a competitor launch, a platform change, timing). The right question is: given what was known at the time, was this the best reasoning available? Use the process × outcome matrix — good process + bad outcome is bad luck (don't punish it); bad process + good outcome is dumb luck (the most dangerous quadrant — the team learns the shortcut works).