// 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.
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.
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.
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 | triage |
| description | 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. |
| license | MIT |
| compatibility | Needs network access to the scrutineer API (http://host:port/api). |
| metadata | {"scrutineer.output_file":"report.json","scrutineer.output_kind":"freeform"} |
Kick off the standard set of scans against a freshly-added repository.
./context.json — has scrutineer.api_base, scrutineer.token, and scrutineer.repository_id. Required../report.json — write a short summary of what you enqueued.Before enqueueing anything, check what already ran so a re-trigger is idempotent: GET {api_base}/repositories/{repository_id}/scans returns every scan on this repository with skill_name and status. Build a set of skill names with status="done" or status="running" and skip those.
For every remaining skill in the list below, enqueue it: POST {api_base}/repositories/{id}/skills/{name}/run with an Authorization: Bearer {token} header. Empty JSON body. Order does not matter; the scrutineer worker runs them as they come in.
metadatapackagesadvisoriesdependentsdependenciessbommaintainerssubprojectsrepo-overviewsemgrepzizmorsecurity-deep-diveIf a skill name comes back 404 skill not found or inactive, skip it and note which one in your report; the operator may have disabled it on purpose.
Write ./report.json as:
{
"triggered": ["metadata", "packages", ...],
"skipped": ["semgrep"],
"already_done": ["metadata"],
"errors": []
}
already_done holds skills that were skipped because a done/running scan was already present. skipped is for skills that came back 404 skill not found or inactive.
Do not wait for any of the scans to finish. The API returns a scan id immediately; your job is to fire them off and exit.
Do not fabricate scans or invent skill names. If the api_base or token is missing from context.json, write {"error": "context.json missing scrutineer block"} and exit 0 so the failure is visible on the scan page.