From role-pgm
Structured root-cause investigation of a team or project issue — a missed deadline, stalled initiative, customer escalation, recurring miscommunication, or production incident. Enforces "no fix without root cause", uses a 3-strike hypothesis rule, and ends with an investigation report. Produces a write-up — never takes unilateral action.
npx claudepluginhub sitloboi2012/team-marketplace --plugin role-pgmThis skill uses the workspace's default tool permissions.
**Invocation: user only.**
Guides Next.js Cache Components and Partial Prerendering (PPR): 'use cache' directives, cacheLife(), cacheTag(), revalidateTag() for caching, invalidation, static/dynamic optimization. Auto-activates on cacheComponents: true.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Share bugs, ideas, or general feedback.
Invocation: user only.
No fix proposals without root-cause investigation first.
Jumping to a fix on symptoms creates whack-a-mole problems — the same thing recurs in a new form. Find the root cause, then act. If you can't find the root cause, say so. Don't fabricate one to have something to propose.
Process and project issues, not just code. The shape is the same either way:
If it's a code bug, the methodology still works — but a dedicated engineering investigate skill exists in gstack or similar; use this one when the answer might be organizational, not technical.
Before any hypothesis, gather evidence. Ask the user for anything you need, one question at a time, not a batch.
Pull what you can from sources:
Produce a clean symptom statement: "What we observed is X, starting around Y, affecting Z." Confirm with the user before moving on.
Before forming a hypothesis, check if this matches a pattern. Common ones:
Search prior investigation reports and retros in Notion for the same area. Recurring issues in the same place are an organizational smell, not coincidence.
State a specific, testable root-cause hypothesis. Example:
Verify the hypothesis. Ways to verify without taking action:
If 3 hypotheses fail to match evidence, stop. Tell the user:
"Three hypotheses tested against evidence. None match. This may be a structural issue, not a local one."
Offer options:
Only after a root cause is confirmed — or the 3-strike rule triggered — produce the report.
# Investigation: <one-line title>
**Date:** <today> · **Investigator:** <user> · **Status:** <Root cause found | Unresolved after 3 hypotheses | Ongoing>
## Symptom
<What we observed. Specific. Dated.>
## Timeline
- <YYYY-MM-DD> <event>
- ...
(Aim for 4-8 entries. The moments that mattered, not every Slack message.)
## Root cause
<If found: the specific, testable claim about what was wrong.>
<If unresolved: "Unresolved — three hypotheses tested. See below.">
## Evidence
- <link to artifact, quote, or event that supports the root cause>
## Hypotheses considered (including the one that held)
1. <hypothesis> — <evidence for/against> — <held / rejected / partial>
2. ...
3. ...
## What this is *not*
<Useful when investigating something people have strong opinions about. Explicitly rule out explanations that would be obvious but aren't supported — "this was not a capacity problem, because X.">
## Contributing factors (non-causal)
<Things that made the failure mode more likely or harder to catch, but aren't the root cause. Keeps the report honest without scope-creeping into everything.>
## What to do next
- <specific action, owner, date>
- ...
## Systemic fix (if any)
<If this recurs in the same area, or matches a prior pattern, propose a structural change. Not "communicate better." Specific: "Add a check in the spec-review skill that asks about rate limits." "Make the PgM the DRI on cross-team dependencies by default.">
## Don't blame
<One paragraph. A good investigation names what happened and what to change — not who to criticize. Read the report once and delete anything that reads like an accusation.>
Show the draft. Common edits:
On approval:
<<NOTION_INVESTIGATIONS_PATH>> (or ask for the destination if unset)/role-pgm:risk-log addNever auto-publish. Never post to Slack unless the user asks — investigation reports are usually shared deliberately, to specific people, not broadcast.