decision-audit
Skill112 starsChanged 7 months agoMITView on GitHub
PM decision quality auditor. Use this skill whenever a PM wants to audit a specific decision they made — not just whether it worked out, but whether it was a *good decision* by the criteria that define PM excellence. Trigger on: "was this the right call?", "I want to audit this decision", "I'm not sure I made this well", "help me think through whether this was a good PM decision", "I made a call about X and I want to pressure-test it", "I cut this feature / changed this priority / chose this direction — was that right?", or any time a PM wants structured feedback on the quality of a specific decision they made, regardless of whether it turned out well. Important: good outcomes don't make good decisions; bad outcomes don't make bad decisions. This skill audits the *process*, not the result.
2 other projects use a version of this.
Adopted by
Most recently taken up by
- Haple/system-onetheir own version, first seen Oct 20, 2026
- emaraschio/cursor-commandstheir own version, first seen Aug 7, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
- emaraschio/cursor-commands★ 9same name
- Haple/system-one★ 0same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository14 other files it gives its agents.
- adversarial-roleplaySkill
- blind-spot-scanSkill
- corporate-misalignment-finderSkill
- focal-point-finderSkill
- make-requirements-greatSkill
- orchestrate-pm-alignmentSkill
- reasons-people-buySkill
- rulebook-for-argumentsSkill
- situation-retrospectiveSkill
- team-perspective-revealSkill
- tech-sensemakingSkill
- verbalized-samplingSkill
- vibe-code-leaf-finderSkill
- workflow-trellisSkill
The file
We split this skill into the rules it gives an agent
6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈5
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 17
Read references/pm-excellence-behaviors.md before beginning.
- Distinctive: line 35
Ask the PM to describe the decision.
- Distinctive: line 41
If they've already described it, work with what you have.
- Distinctive: line 45
Ask these questions one at a time.
- Distinctive: line 114
If the PM conflates the two — "it worked out so I must have done it right" or "it failed so I must have gotten it wrong" — name that …
- Distinctive: line 135
Ask them to slow down on the ones that are hard to undo.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Decision Audit
Read references/pm-excellence-behaviors.md before beginning. Focus on Cluster 2 (Decision Quality)
as the primary lens, with Clusters 1, 3, and 6 as secondary lenses for how the decision was made
and communicated.
What This Mode Does
The PM describes a decision they made. You walk them through a structured audit of the decision process — not whether it worked out, but whether it was made with the rigor, transparency, and customer-centricity that defines excellent PM decision-making.
The output is a decision quality scorecard and a clear statement of where the process fell short.
Process
Step 1: Get the Decision
Ask the PM to describe the decision. You need:
- What was decided? (feature cut, priority change, direction call, scope trade-off, etc.)
- When? (recent enough that details are fresh)
- What was the alternative? (every decision has a road not taken — what was it?)
- What happened? (outcome so far, if any)
If they've already described it, work with what you have.
Step 2: The Audit Interview
Ask these questions one at a time. Don't ask all of them at once — listen and adjust based on what they say:
On data and grounding: "What data or research informed this decision? Walk me through what you looked at."
On the customer: "Where does the customer appear in the reasoning? How did user impact factor into the call?"
On alternatives: "What was the strongest argument for the alternative you didn't choose? Did you seriously consider it?"
On transparency: "How did you communicate the decision to the team? Did you share the 'why' or just the 'what'?"
On reversibility: "Was this a reversible or irreversible decision? Did you treat it accordingly — i.e., move fast on reversible, slow down on irreversible?"
On pressure: "Was there any external pressure (leadership, timeline, politics) that shaped this decision? If so, how did you account for it?"
On dissent: "Did anyone push back? If so, what happened to that pushback?"
You won't always need all six questions. If the PM has already addressed something, move on.
Step 3: Score the Decision
Silently assess the decision against five dimensions (don't show the scores — use them to structure your output):
| Dimension | What "Good" Looks Like | What "Weak" Looks Like |
| Customer-centricity | User impact explicitly weighed; customer used as north star | Decision driven by business pressure, personal preference, or technical convenience |
| Data quality | Relevant data identified and used correctly; gaps acknowledged | No data, bad data, or data cherry-picked to support a pre-made call |
| Transparency | "Why" shared proactively; team could reconstruct the reasoning | "What" communicated, "why" assumed or withheld |
| Alternative consideration | Strongest counter-argument taken seriously and addressed | Only one option considered; alternative dismissed superficially |
| Appropriate speed | Reversible decisions made fast; irreversible ones slowed down for input | All decisions treated the same, regardless of reversibility |
Step 4: Deliver the Audit
Structure your output as:
The quality of this decision: Open with a direct, one-sentence read: "This was a solid decision made from a weak data position" or "This was the right call, but it was made in a way that probably eroded team trust" or "This decision had good intent but was process-poor."
What you got right: Name 1-2 genuine strengths in how the decision was made. Be specific.
Where the process broke down: Name the 1-3 most significant process failures. For each:
- What the failure was (specifically)
- Why it matters — what does it cost the team or the product in the long run?
- What doing it differently would look like
The distinction that matters most: End with the one insight that cuts to the heart of the decision. This might be about process ("you outsourced the 'why' to leadership, which means your team can't evaluate the decision themselves"), about timing ("this needed to be a slow decision — reversible decisions can move fast, this one couldn't"), or about the customer ("the user never appeared in your reasoning — that's the tell").
The Core Principle to Enforce
The best PMs in the source material distinguish clearly between outcomes and decision quality. A decision can be made well and still fail. A decision can be made poorly and still succeed.
If the PM conflates the two — "it worked out so I must have done it right" or "it failed so I must have gotten it wrong" — name that directly: "Whether this worked out is separate from whether it was a good decision. Let's focus on the process."
Calibration Notes
Audit the process, not the content. You're not second-guessing the actual call (cut the feature vs. keep it) — you're evaluating how the decision was reached and communicated. Stay in that lane.
Pressure matters. Many PM decisions are made under leadership pressure with imperfect data and too little time. Acknowledge that reality. The audit isn't about ideal conditions — it's about whether the PM exercised judgment within the constraints.
Push on the customer. The single most common PM failure mode in the source material is decisions that don't have a visible customer in them. If the PM can't articulate how the user was part of the reasoning, push on that first.
Reversibility is underused as a concept. Many PMs treat all decisions with the same urgency. Ask them to slow down on the ones that are hard to undo. If they didn't, name that.
Input/Output Contract
Accepts: A description of a specific PM decision (context, alternatives, outcome, communication)
Produces: Decision quality audit — what was done well, where the process broke down, and the one insight that matters most
Passes to: blind-spot-scan if the audit reveals a recurring pattern; terminal if the PM
has specific improvements to apply to the next decision
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

