skill-authoring

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.

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.

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 on every fresh stackhawk.yml (Phase 0c) 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.

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.

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 on every fresh stackhawk.yml (Phase 0c) 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.

Helps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skill should be used when the user is looking for functionality that might exist as an installable skill.

Configure this repo for the engineering skills: set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.

Teach the user a new skill or concept, within this workspace.

No description in the SKILL.md.

No description in the SKILL.md.

Ask which skill or flow fits your situation. A router over the skills in this repo.

No description in the SKILL.md.

Plan a huge chunk of work (more than one agent session can hold) as a shared map of decision tickets on your issue tracker, and resolve them one at a time until the way to the destination is clear.