gnurio/nurijanian-skills · Archived

decision-audit

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 di…

First seen May 16, 2026

Installation

$ npx skills add gnurio/nurijanian-skills --skill decision-audit

Stronger alternatives

This repository is archived — consider an actively maintained alternative.

Similar popular skills

Related neighbors and high-traction skills in the same topics — useful to compare before installing.

Also in this package

Other skills from gnurio/nurijanian-skills · top by installs.

npx skills add gnurio/nurijanian-skills

Browse all from gnurio/nurijanian-skills

More details

Agent compatibility

Declared targets from SKILL.md / docs. Unmarked agents are not listed — the skill may still install via the CLI.

Claude Code Not declared
Cursor Not declared
Codex Not declared
GitHub Copilot Not declared
Windsurf Not declared
Gemini CLI Not declared
Cline Not declared
OpenCode Not declared

Repository health

Stars 103
License LICENSE
Default branch main
Open issues 0
Status Archived

Package contents

Files included with this skill beyond the listing page.

  • skill md SKILL.md 6,996 B
  • docs SUMMARY.md 826 B

History

  1. First seen on skills.sh
  2. First recorded snapshot · 6 installs

SKILL.md

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