AgentStack
SKILL verified MIT Self-run

Triage Incidents

skill-gitguardian-agent-skills-triage-incidents · by GitGuardian

Use when triaging or reviewing GitGuardian secret incidents already detected in the dashboard, when asked what is leaking in the org or what to fix first, when remediating or rotating a credential flagged in an incident, after a Public Monitoring alert, or to assign, tag, or resolve incidents. Operates through the GitGuardian Developer MCP server.

No reviews yet
0 installs
4 views
0.0% view→install

Install

$ agentstack add skill-gitguardian-agent-skills-triage-incidents

✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.

Security review

✓ Passed

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

Are you the author of Triage Incidents? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

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_incidents is 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-secrets when 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 (or list_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:write scope — 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 .md to 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.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet — be the first.

Versions

  • v0.1.0 Imported from the upstream source.