Install
$ agentstack add skill-gitguardian-agent-skills-triage-incidents ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
GitGuardian — Triage Incidents
Overview
This skill works through the GitGuardian Developer MCP server (ggmcp) to read, prioritize, and remediate secret incidents the GitGuardian platform has already detected. It is distinct from scan-secrets: that finds unknown secrets in code; this acts on known incidents in the dashboard.
This is the one MCP-first skill in the bundle. There is no ggshield subcommand for incident triage — the work runs through ggmcp tools. ggshield is only needed for the HMSL handoff sub-step, which is user-run regardless.
Start Here — Read This Before Doing Anything
- Two non-interchangeable incident categories. Internal incidents (integrated
sources: private/org repos, Slack, Jira, registries) use list_incidents / get_incident. Public incidents (Public Monitoring on the worldwide perimeter: public GitHub, gists, Docker Hub) use list_public_incidents / get_public_incident. IDs are not interchangeable; an internal write tool called with a public ID silently 404s. Default to internal unless the user's intent is about leaks "on public GitHub / outside the org / on Docker Hub / found by Public Monitoring".
- Triage before action — even for valid incidents. Rank the full set first; do not
start remediating the first incident before the user has seen the prioritized list. A valid result raises urgency but is not a triage axis: it never lets you skip the ownership and blast-radius questions or jump to a generic rotation plan. The deliverable mode is selected by ownership x blast radius, and a valid production-critical credential is Coordination (supervised, sequenced rotation), not a fast "just rotate it" — rotating it blind can take a live system down. See doctrine principle 7.
- Read the doctrine before composing remediation. When you are ready to drive a fix,
read [references/remediation-doctrine.md](references/remediation-doctrine.md) end-to-end. Rotation-first; history-rewrite only under narrow conditions; public exposure is always burned.
- A configured custom remediation workflow takes the lead. Before composing the fix,
call get_remediation_workflow. If it returns an id, the workspace has a custom workflow — follow it as the spine of the deliverable: render its steps verbatim and use the doctrine to fill in the mechanics and verification under each step. If there is no id (GitGuardian's default workflow) or the tool is unavailable, set the returned steps aside — do not render them — and let the doctrine drive end-to-end. See doctrine § 13.
remediate_secret_incidentsis a read tool — not the remediation plan. Despite the
name, it changes no state: it returns occurrence data for the current repo — file paths, line numbers, char indices — and nothing more. Ignore the remediation_instructions it returns: do not take its remediation guidance into account. Treat this tool's output as occurrence data only and drive the fix from the doctrine (rotation-first). Calling it is not "remediating."
- Never auto-resolve. Marking an incident RESOLVED / IGNORED, assigning it, or
tagging it is an outward-facing state change on the shared dashboard. Confirm with the user before any write, and only mark RESOLVED after rotation is actually confirmed — never on intent.
- HMSL stays user-run. When a finding's validity is
unknown/no_checker/
not_checked, the follow-up is HasMySecretLeaked. Do not run ggshield hmsl yourself and do not read the credential into context — print the command for the user (-n none --json). If the check-hmsl skill is installed, load it for the full protocol.
When to Use
- "triage / review my GitGuardian incidents", "what's leaking in our org", "what should
I fix first".
- After a Public Monitoring alert (a leak outside the org perimeter).
- As a handoff target from
scan-secretswhen a scan finding turns out to already be a
tracked incident.
Onboarding (first use)
Prerequisites
- The GitGuardian Developer MCP server (ggmcp) connected and authenticated. See
https://github.com/GitGuardian/ggmcp.
- A token with incident read scope for triage, and write scope to assign / tag /
resolve. ggmcp hides tools whose scopes the token lacks.
Setup
- Verify connectivity and read scope with a cheap read such as
count_incidents(orlist_sources). - If the incident write tools are absent from the available toolset, the token lacks
write scope. Degrade to read-only triage and hand the user the equivalent dashboard action instead of failing. See [references/gitguardian-platform.md](references/gitguardian-platform.md) for auth/scope recovery and instance URLs.
Triage workflow
Follow [references/triage-workflow.md](references/triage-workflow.md) — it covers the five steps (scope → rank → drill in → drive the fix → close the loop), the axis→filter mapping, the internal/public tool split, and scope-degradation handling.
Best Practices
- Rank validity-first (valid > unknown > invalid-suppressed), then by
score,
severity, source_criticality, public_exposure.
- Group the same credential across occurrences into one row; one credential is one
rotation even if it appears many times.
- Respect default tag/validity exclusions — don't resurface known false positives or
test credentials.
- Stay read-only until the user opts into a specific write. State which incident space
(internal vs public) you are querying.
Troubleshooting
- Write tools missing. Token lacks
incidents:writescope — re-issue the token with
write scope; see [references/gitguardian-platform.md](references/gitguardian-platform.md).
- Public tools missing or empty. Public Monitoring is not enabled on the workspace
(enterprise-gated, like endpoint scanning for scan-machine).
- 404 on a write. Internal-vs-public incident-ID mismatch — use the matching tool
family.
- Docs fallback. https://docs.gitguardian.com (append
.mdto any page; AI-agent
index at https://docs.gitguardian.com/llms.txt).
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: GitGuardian
- Source: GitGuardian/agent-skills
- License: MIT
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.