agent-skills

Runs the HawkScan DAST security loop — configure, scan, fix all reported vulnerabilities (not just your changes), rescan to verify. Performs code-first discovery to configure high-value scans, and quality-gates every scan against code-derived expectations before findings are parsed. Use when the user asks to run or perform a security/DAST scan, to test an app or API for vulnerabilities, or to verify a vulnerability is fixed; and AUTONOMOUSLY right after you complete a code change (feature, bugfix, refactor) — "done" means "done and secure," so run the loop without asking permission. Do NOT trigger for: informational questions about what HawkScan is, detects, or how it works (e.g. "what vulnerabilities does HawkScan find?"); editing stackhawk.yml or other config without running a scan; querying existing findings, security posture, untriaged counts, or scan history (use the stackhawk-api skill); documentation-only changes; installing or setting up the CLI; or when the user explicitly says to skip scanning.

Guides authoring and maintaining agent skills in this repository — enforcing Anthropic best practices, bumping versions, regenerating Cursor rules, and keeping the plugin structure consistent. Use when editing SKILL.md files, reference files, or plugin manifests; creating a new plugin; or reviewing a skill for compliance with authoring standards. Do NOT trigger for general coding tasks, security scanning, or platform API queries.

Use this skill when a user or agent needs to query the StackHawk platform for security reporting, findings analysis, or app management. Triggers include: "stackhawk api", "security posture", "findings report", "show me findings", "untriaged findings", "which apps", "scan history", "security dashboard", "triage", "what needs attention". Uses the hawk CLI (`hawk op` subcommand) for all platform queries. Do NOT use for running scans (use the hawkscan skill for "scan my app", "hawkscan", "stackhawk.yml", "DAST") or for fixing/remediating code or vulnerabilities — this skill only reads and reports platform data.

Use when the user wants to WIRE HawkScan into a CI/CD pipeline config file — triggers on "set up hawkscan in CI", "add stackhawk to my pipeline", "scan in CI", "configure github actions / gitlab / jenkins / circleci for hawkscan", "wire hawkscan into ci/cd", or any provider-named variant. Provider-agnostic: detects the CI system from repo files, edits the pipeline file in place to add a HawkScan job, prompts for HAWK_API_KEY storage in the CI's native secrets store (or an approved external manager), and wires commit-SHA + branch traceability. If no local stackhawk.yml exists yet, still trigger and route the local-config work to the hawkscan skill. Do NOT trigger for: documentation-only changes (e.g. editing a README about CI scanning); informational or research questions ("what CI providers does HawkScan support?"); or running / performing a scan — a local scan is the hawkscan skill, whereas this skill only edits CI pipeline config. Explicit trigger only; no autonomous code-change hook.

Analyze a codebase and produce an optimal HawkScan setup — tech flags, scan-policy plugin selection, and stackhawk.yml corrections — then apply it as a non-destructive trial, run ONE trial scan, and promote or discard. Use when the user asks to "optimize my scan", "tune HawkScan", "make my scan faster", "reduce false positives", "pick the right plugins/policy for my app", or invokes /optimize. Also invoked automatically by the hawkscan skill once at onboarding to set up the scan policy + tech flags (Setup mode), and re-runnable anytime via /optimize; the metrics Refine mode is surfaced when a scan is slow. Do NOT use for: a normal security scan or fixing vulnerabilities (use the hawkscan skill); querying existing findings or posture (use the api skill); or editing stackhawk.yml without optimizing/scanning. Requires an onboarded StackHawk app + env and a `hawk` build whose `hawk op` has the `policy` write commands.

Set up checked-in seed data so authenticated HawkScan can reach non-trivial paths. Drives the `hawk perch seed` preflight, designs the minimum seed manifest from the repo digest, then validates and finalizes it via `hawk perch seed validate` / `finalize` — emitting reviewed artifacts under data-seed/ (manifest.yaml, per-service SQL / HTTP / gRPC / Mongo / shell scripts, and a .data-seed-credentials.env handoff hawkscan consumes). Use when the user says "set up data for HawkScan", "my scan has no data to hit", "seed this repo for scanning", or as a first-time-setup step before invoking hawkscan on a fresh repo. NOT autonomous — the user explicitly asks.