Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →grcengclub/context-bootstrap
Setup guidance for users running a /report:* command before their toolkit has enough context.
Passed 21 of 22 test cases with the skill, and 6 of 22 without it.
and 14 more in the full report
15 fixed6 passed either way1 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 15 test cases the skill fixed. Same model, same prompt, with and without the skill.
When expanding from a single SOC 2 setup to meet the minimum multi-framework requirement for program health, which second framework plugin is standard in the setup guide?
| Checked | Without skill | With skill |
|---|---|---|
| Names fedramp-rev5 as the standard second framework plugin. | Missed | Passed |
The instructions your model reads when the skill loads.
Hollow reports are worse than no reports. When a user runs /report:exec-summary with an empty findings cache, the right move is to teach them the setup, not to make up a report.
Before any report command generates, verify:
Plugins installed. Run /plugin list or inspect the marketplace. Need at least:
grc-engineer (the pipeline hub)github-inspector, aws-inspector, okta-inspector)soc2, fedramp-rev5, iso27001)Findings cache populated. Look in ~/.cache/claude-grc/findings/<source>/*.json. Timestamps within the last 30 days mean the pipeline is active.
Framework metadata available. Each framework plugin's plugin.json should have a framework_metadata block. Without it, coverage math fails silently.
History depth (for week-over-week commands). /report:automation-coverage needs at least 2 metric snapshots in ./grc-data/metrics/ that are 7+ days apart. Verify snapshot dates there rather than inferring movement from the findings cache.
Optional GitOps state. ./grc-data/risks/*, ./grc-data/metrics/*, ./grc-data/incidents/*.md. The JSON contracts live in docs/GRC-DATA.md. Missing is fine; present is better.
/report:exec-summary: one connector, one framework, recent findings. Risks and metrics improve it but are not mandatory./report:program-health: two framework plugins plus one successful gap-assessment run per framework. A single-framework setup is not enough./report:board-brief: quarter-spanning findings history plus a real risk register if you want residual-risk sections to be grounded./report:automation-coverage: two metric snapshots in ./grc-data/metrics/ at least 7 days apart. Findings cache alone is not enough to claim week-over-week automation movement.Auto-discover everything. Ask at most one or two narrative questions (audience, material asks). Generate.
Name what's missing. Auto-discover what exists. Offer to proceed with interview mode where the user fills the gaps conversationally. Example:
I see findings from github-inspector across the last 14 days, SOC 2 framework installed. No risk register at
./grc-data/risks/. I can still write the report using findings and metrics only, or you can set up a risk register first.docs/GRC-DATA.mdshows the file shape. Which do you want?
test cases passed, vs 6 / 22 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.