Stats
Actions
Tags
From grc-reporter
Translates GRC findings, risks, and program activity into language leadership actually reads. Use when any /report:* command is composing output intended for a CISO, CIO, or above. Opinionated rules on what lands and what doesn't.
How this skill is triggered — by the user, by Claude, or both
Slash command
/grc-reporter:so-what-translationThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
Every GRC person needs this skill and most don't have it. The controls are not the point. The frameworks are not the point. The deliverable is not the point. The point is the decision you want the reader to make.
Every GRC person needs this skill and most don't have it. The controls are not the point. The frameworks are not the point. The deliverable is not the point. The point is the decision you want the reader to make.
These are the rules for translating the work into something a CISO or above will read, trust, and act on.
Not selfishly. Because their bosses care about money. The CFO, the CEO, the board. Every finding needs a dollar or time translation.
"We have a control deficiency in CC6.1" is invisible to a CISO. "This blocks a $2M SOC 2 deal closing in Q2" is not.
If you cannot translate a finding into dollars saved, dollars at risk, deals unblocked, or time returned to the team, you have not finished the work. Do that step before you walk into the room.
More secure. More deals. Fewer surprises. Faster audits. Cleaner board meetings.
GRC is the plumbing. Nobody talks about plumbing at dinner. Talk about what's running through it: revenue, trust, speed, sleep. The controls and frameworks are how you get there. They are never the thing.
If your weekly update reads like a control checklist, you've written it wrong.
What went wrong, and what are we doing about it.
"The connector failed this week" is not an update. "The connector failed Tuesday, we caught it by Thursday, here's the fix going in tomorrow, and here's what we're building so it can't happen again" is an update.
Every problem you name needs a response attached. If the response isn't ready, say "response in 48 hours, here's who owns it." Never leave a problem floating without an owner and a timeline.
Every CISO has a personal scorecard. Budget defense. Security metrics the board sees. Making the CEO confident. Clean audits. Low-noise SOC. Getting promoted. Not getting fired.
You cannot communicate up effectively without knowing which of those scorecards you are moving this week. The only way to find out is to ask. In a 1:1. Directly.
"What do you want me making you look good on this quarter?" is a legitimate question from a GRC engineer to a CISO. Ask it.
A CISO reporting to a CIO tells a different story than one reporting to a CEO.
Same finding, different framing, depending on whose ear you're actually reaching through the CISO.
Don't wait to be asked.
Bring the weekly update before it's requested. Bring the risk the board hasn't noticed yet. Bring the proposal for the automation project that didn't have a sponsor. Bring the framework expansion the company will need in 18 months.
The GRC engineers who rise are not the ones who execute the plan. They're the ones who name the next plan.
name. ETA: date."specific control automation."Run this check on every section:
If any answer is no, rewrite that section.
npx claudepluginhub abnejllc/grc --plugin grc-reporterCreates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.