---

name: context-bootstrap description: Setup guidance for users running a /report:* command before their toolkit has enough context. Use when a report command detects missing findings, frameworks, or history. Walks the user through installation and first collection rather than generating a hollow report. allowed-tools: Read, Glob, Bash

Context Bootstrap

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.

What to check

Before any report command generates, verify:

1. Plugins installed. Run /plugin list or inspect the marketplace. Need at least:

   • grc-engineer (the pipeline hub)
   • One connector (e.g., github-inspector, aws-inspector, okta-inspector)
   • One framework plugin (e.g., soc2, fedramp-rev5, iso27001)

2. Findings cache populated. Look in ~/.cache/claude-grc/findings/<source>/*.json. Timestamps within the last 30 days mean the pipeline is active.

3. Framework metadata available. Each framework plugin's plugin.json should have a framework_metadata block. Without it, coverage math fails silently.

4. 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.

5. 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.

Command-specific minimums

• /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.

The three paths

Complete context

Auto-discover everything. Ask at most one or two narrative questions (audience, material asks). Generate.

Partial context

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.md shows the file shape. Which do you want?

Empty context

Walk through the setup. Do not generate.

The empty-context setup script

Deliver these steps in plain conversational form. Do not dump all commands at once; confirm each step before moving to the next.

1. Add the marketplace

   /plugin marketplace add GRCEngClub/claude-grc-engineering
   

2. Install the minimum plugin set

   /plugin install grc-engineer@grc-engineering-suite
   /plugin install github-inspector@grc-engineering-suite
   /plugin install soc2@grc-engineering-suite
   

   github-inspector is the lowest-setup connector (uses the gh CLI you probably already have authenticated). soc2 is the most common first framework.

3. Set up the connector

   /github-inspector:setup
   

   Confirms gh auth status and writes a default config.

4. Collect findings

   /github-inspector:collect --scope=@me
   

   For a first run, @me scopes to the user's own repos. For org-wide scans, use --scope=<org-name> with a token that has admin:org.

5. Run the first gap assessment (optional but recommended)

   /grc-engineer:gap-assessment SOC2 --sources=github-inspector
   

   Not strictly required for /report:* commands, but produces the crosswalked finding structure report commands read.

6. Come back to the report command. With findings in cache, rerun the report command that sent the user here.

7. If the user wants /report:program-health, add a second framework now.

   /plugin install fedramp-rev5@grc-engineering-suite
   /grc-engineer:gap-assessment SOC2,FedRAMP-Moderate --sources=github-inspector
   

   program-health needs more than one framework in scope or it is not a portfolio view.

For /report:automation-coverage specifically

This command needs history. If the user just finished a first-time setup, tell them:

You have one baseline from today. Automation coverage needs at least two metric snapshots 7+ days apart so there's a delta to report. Two options:

1. Schedule regular collection with /grc-engineer:monitor-continuous SOC2 daily --sources=github-inspector. Come back in 7-14 days.
2. Run /grc-engineer:record-automation-metrics <framework> --controls-total=<n> --controls-automated=<n> --window-label=<period> once per week so ./grc-data/metrics/ builds a real history, then rerun the report after you have two snapshots.

Do not fabricate a week-over-week comparison from Findings alone.

When to break the "no hollow report" rule

Never. A fake report is worse than no report because it teaches the user to trust numbers that aren't real. If the user explicitly asks for a template rendering with placeholder data for demo purposes, that is a different ask and gets a clearly-labeled DEMO DATA output.