메뉴
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.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Identify the real maintainers of a repository and the best way to contact them about a security issue. Distinguishes active leads from occasional contributors and bots, using commit history, issue activity, and registry ownership. Use when preparing a disclosure and needing to know who to reach.
Index dependencies reported by git-pkgs for the repository's manifest and lockfile files (package.json, Gemfile, go.mod, requirements.txt, etc.) and record each one with its manifest path, ecosystem, and requirement string. Use to populate the Dependencies tab.
Check whether known sinks in this application's dependencies are reachable from its own trust boundaries. Scrutineer already holds findings against the libraries this app uses; this skill traces each one from the app's entry points to the library call and reports the ones an attacker can reach. Use on applications (Gemfile.lock / package-lock.json present), not on libraries.
Generate a CycloneDX Software Bill of Materials for the repository. Use when you want a standard-format inventory of components for downstream tooling, compliance, or archival. Stored verbatim on the scan.
Fetch the published security advisories that affect any package produced by this repository. Use to populate the Advisories tab with existing GHSA and CVE records so analysts can see what is already public before triaging new findings.
For each published package of this repository, fetch the top runtime dependents so later exposure-analysis skills have a ranked shortlist to work against. Use after the packages skill has populated which packages exist.
| 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.version":1,"scrutineer.output_file":"report.json","scrutineer.output_kind":"patch"} |
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.scan_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).{"error": ...} shape).rationale.Once you have a working tree edit, generate a unified diff against HEAD:
cd src
git add -N .
git diff HEAD -- . > ../patch.diff
Read ../patch.diff (the workspace root, alongside report.json) 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.