// Propose a code patch for a finding. Produces a unified diff against the current HEAD plus a short rationale, written back as a finding note so the analyst can review, adjust, and open a PR themselves. The skill never pushes to the remote.
| name | patch |
| description | Propose a code patch for a finding. Produces a unified diff against the current HEAD plus a short rationale, written back as a finding note so the analyst can review, adjust, and open a PR themselves. The skill never pushes to the remote. |
| license | MIT |
| compatibility | Needs network access to the scrutineer API (http://host:port/api). Finding-scoped; runs against ./src at HEAD. |
| metadata | {"scrutineer.output_file":"report.json","scrutineer.output_kind":"freeform"} |
Propose a minimal code patch that fixes a confirmed finding. You are not shipping the fix; you are handing the analyst a starting diff and explaining what it does. The analyst reviews, edits if needed, and opens a PR by hand.
./src — the repository at its current HEAD, on the default branch, writable./context.json — has scrutineer.api_base, scrutineer.token, scrutineer.repository_id, scrutineer.finding_id (required; this skill only makes sense finding-scoped)./report.json — write the patch + rationale here./schema.json — shape of report.jsonRead ./context.json. If scrutineer.finding_id is missing, write {"error": "no finding_id in context.json; patch is finding-scoped"} to report.json and exit 0.
Fetch the finding: GET {api_base}/findings/{finding_id} with Authorization: Bearer {token}. Read location, cwe, trace, boundary, validation, rating. These five together tell you where the sink is, what the vulnerable input flow looks like, and what dangerous behaviour you need to stop.
Inside ./src, edit files to fix the finding. Constraints:
location is pkg/foo/bar.go:42, that is where the patch should land (or at the nearest layer where a guard is sensible — e.g. the input validator that feeds the sink).rationale.Once you have a working tree edit, generate a unified diff against HEAD:
cd src
git add -N .
git diff HEAD -- . > /tmp/patch.diff
Read /tmp/patch.diff and put its contents into report.json under the patch field. Do not commit; the diff is the artefact. If the diff is empty, something went wrong — do not write an empty patch. Write {"error": "patch produced no diff"} and exit 0.
POST a finding note summarising the patch: POST {api_base}/findings/{finding_id}/notes with:
{
"body": "Proposed patch in scan #{scan_id}.\n\nFiles changed: ...\n\n{short rationale}\n\nApply with: `git apply` the diff from the scan report.",
"by": "patch"
}
The note lives on the finding page; the full diff lives in report.json and is viewable on the scan page.
Do not PATCH any editable fields on the finding. Specifically:
fix_commit — that field means a shipped upstream fix, not a proposal. The analyst sets it after their PR merges.fix_version — same reason.status. Lifecycle transitions belong to the analyst.Write ./report.json:
{
"patch": "diff --git a/pkg/foo/bar.go b/pkg/foo/bar.go\n...",
"rationale": "Short prose — two or three sentences. What the guard is, why it blocks the trace, what legitimate input it still lets through.",
"files_changed": ["pkg/foo/bar.go", "pkg/foo/bar_test.go"],
"base_commit": "<HEAD sha from ./src>",
"tests_added": true,
"notes": "Optional: anything the analyst should know — a second sink you spotted but didn't patch, a style choice you weren't sure of, a test you couldn't write."
}
base_commit is the HEAD sha the diff applies to. The analyst needs this to git am or git apply cleanly — if they rebased since the scan, they know the patch may not apply and can regenerate.
Write {"error": "...", "rationale": "..."} and exit 0 in any of these cases — do not ship a bad patch:
git log -- {location} — if a recent commit looks like it addressed the sink, surface the SHA in notes and refuse to duplicate.Produce a structured plain-language overview of what a repository does, who maintains it, its activity level, and the shape of its codebase. Use when you want a quick orientation before deeper analysis.
Audit first-party source for security vulnerabilities using an inventory-first, six-step per-sink methodology. Use when you want a thorough scan that distinguishes real findings from pattern matches and records both in a machine-readable report. The target is this codebase's own code, not its dependencies.
Run semgrep static analysis with the security-audit and secrets rulesets, then map each hit into scrutineer's findings shape so it surfaces alongside model-driven audits. Use as a fast deterministic pass before or alongside deeper skills.
Enumerate scannable sub-folders inside a repository. Identifies monorepo packages, workspaces, and discrete modules so the analyst can scope deep-dive scans to a specific sub-path instead of treating a huge tree as one unit. Runs at repo level; writes back a list that surfaces on the repo overview.
Default pipeline scrutineer runs when a repository is added. Triggers a standard set of other skills in parallel, then writes a short summary of what was enqueued. Edit the list below to change the default scan coverage without touching scrutineer's Go code.
Audit the repository's GitHub Actions workflows for common security issues (credential mishandling, untrusted inputs, template injection, overly permissive tokens) and convert findings to scrutineer's shape. Use on any repo with a .github/workflows directory.