메뉴
File a low-severity finding as an ordinary public GitHub issue after explicit analyst confirmation. Use for hardening gaps, defence-in-depth misses, and other bugs that do not warrant coordinated private disclosure.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | public-issue |
| description | File a low-severity finding as an ordinary public GitHub issue after explicit analyst confirmation. Use for hardening gaps, defence-in-depth misses, and other bugs that do not warrant coordinated private disclosure. |
| license | MIT |
| compatibility | Needs the gh CLI authenticated with permission to open issues on the upstream GitHub repository. Needs network access to api.github.com and the scrutineer API. github.com upstreams only. Finding-scoped. |
| metadata | {"scrutineer.version":1,"scrutineer.output_file":"report.json","scrutineer.output_kind":"freeform","scrutineer.requires_remote":true} |
Open an ordinary public GitHub issue for a confirmed low-severity finding that does not need private vulnerability reporting. This is still a disclosure act: do not file unless the analyst has explicitly chosen this skill for this finding.
./src — the upstream clone./context.json — has repository.url, repository.full_name, and the scrutineer block with api_base, token, repository_id, scan_id, finding_id./report.json — write what you did./schema.json — shape of report.jsonUse the gh CLI for every GitHub call.
Read ./context.json, then GET {api_base}/repositories/{repository_id} and GET {api_base}/findings/{finding_id} with Authorization: Bearer {token}. Refuse to continue by writing {"error": "..."} to report.json and exit 0 if any of these are true:
scrutineer.finding_id is missing — this skill is finding-scopedrepository.url host is not github.comgh auth status fails — the runner has no GitHub credentialsstatus is reported, acknowledged, fixed, published, rejected, or duplicatestatus is not ready; the analyst must review and mark it ready before public filingseverity is High or Critical; those should stay on the private disclosure path unless the analyst manually overrides outside this skillpublic-issue (GET {api_base}/findings/{finding_id}/references)gh api repos/{owner}/{repo} --jq '.has_issues' is not trueDerive {owner}/{repo} from repository.full_name, falling back to parsing repository.url and stripping a trailing .git.
Draft for maintainers, not for scrutineer operators. The title should be concise and non-alarmist. The body must explain:
location when presentsuggested_fix, mitigation, or rating when availableUse the finding's prose (trace, boundary, validation, rating, disclosure_draft, mitigation) as source material, but do not include exploit-heavy detail that would make the issue unsafe for public posting. If the finding only makes sense with exploit instructions, refuse and tell the analyst to use private disclosure instead.
End the body with:
[scrutineer-finding:{finding_id}]
This marker lets re-runs recognise the issue.
GitHub caps issue titles and bodies. Keep the title under 256 characters and the body under 65535 characters; trim from the bottom and set truncated: true in report.json if needed.
Write ./issue.md with the body, then run:
gh issue create --repo {owner}/{repo} --title "$TITLE" --body-file ./issue.md
Pass the title through an environment variable or stdin-safe shell assignment, not by interpolating raw finding text into a command line. Capture the issue URL from stdout. If gh issue create fails, write {"error": "<stderr or response>"} to report.json and do not write back to scrutineer.
All with Authorization: Bearer {token}:
PATCH {api_base}/findings/{finding_id} with {"fields": {"status": "reported"}, "by": "public-issue"}POST {api_base}/findings/{finding_id}/references with {"url": "<issue_url>", "tags": "public-issue", "summary": "Public issue on {owner}/{repo}"}POST {api_base}/findings/{finding_id}/communications with {"channel": "issue", "direction": "outbound", "actor": "public-issue", "body": "Filed public issue on {owner}/{repo}: <issue_url>"}Write ./report.json:
{
"upstream": "owner/repo",
"title": "Issue title",
"url": "https://github.com/owner/repo/issues/123",
"truncated": false,
"error": null
}
On refusal or failure, write:
{
"error": "why nothing was filed"
}
Map distinct externally reachable input-processing subsystems into focus areas for the threat-model skill to carry into later security audits. This is a short, read-only orientation pass, not a vulnerability scan.
Derive a project's security contract from its source and docs, then emit it as structured data other skills can cite. Records what the project assumes about callers and inputs, what properties it claims and disclaims, which code is out of scope, and which recurring tool findings are known-safe. This is not a vulnerability scan; it produces the trust map that security-deep-dive loads instead of re-deriving boundaries per run.
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 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.
Compare open findings in one repository and record how they relate. Marks same-vulnerability findings as duplicates, findings that another finding's fix will close as subsumed, and findings that combine into a higher-severity attack as a chain.
High-recall static source-code vulnerability scan adapted from Anthropic's defending-code reference harness. Fans out by focus area, ranks candidates by confidence, and emits Scrutineer findings for later verification.