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.
npx claudepluginhub abnejllc/grc --plugin grc-reporterThis skill is limited to using the following tools:
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.
Guides Next.js Cache Components and Partial Prerendering (PPR) with cacheComponents enabled. Implements 'use cache', cacheLife(), cacheTag(), revalidateTag(), static/dynamic optimization, and cache debugging.
Guides building MCP servers enabling LLMs to interact with external services via tools. Covers best practices, TypeScript/Node (MCP SDK), Python (FastMCP).
Generates original PNG/PDF visual art via design philosophy manifestos for posters, graphics, and static designs on user request.
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.