| name | qa-security-sweep |
| description | Adversarial QA audit that turns security findings for a feature, module, or diff into canonical Layer:security regression scenarios and archived findings. |
| disable-model-invocation | false |
| allowed-tools | Read, Write, Grep, Glob, Bash, ApplyPatch |
| argument-hint | [<feature-slug>|--diff <ref>|--pr <number>] [--write] [--severity-floor critical|high|medium|low] |
QA Security Sweep
Purpose
Treat security testing as a first-class QA layer. The skill reviews a feature,
module, or diff with an adversarial mindset, then emits findings as canonical
Layer: security regression scenarios that can be tracked by qa drift
and implemented as browser/API/security tests.
Template paths are resolved from ${AGENTS_SKILLS_ROOT}/qa-security-sweep/.
Scope
Inspect every relevant layer in the target repo:
- frontend UI, client state, browser storage, forms, URLs, iframes, messages
- backend route handlers, controllers, server actions, jobs, webhooks
- authn/authz, sessions, role checks, tenant isolation, policy enforcement
- database queries, migrations, RLS/policies, secrets, audit logs
- integrations, webhooks, credential handling, replay protection
- infrastructure headers/config, environment handling, CI/CD, dependencies
- business logic, state machines, race conditions, workflow bypasses
Steps
- Follow
${AGENTS_SKILLS_ROOT}/qa-security-sweep/commands/qa-security-sweep.md.
- Load the QA profile and feature catalog when present.
- Identify existing scenarios and tests for the target feature/prefix.
- Build a threat model before writing scenarios.
- Propose
Layer: security scenarios using canonical IDs and the shared
Security Class: vocabulary.
- Archive the full findings report under
qa/security/findings/ when the
repo uses that convention, or under the QA profile's configured security
output path when present.
- With
--write, append scenarios to the relevant regression spec files and
run qa drift.
Guardrails
- Do not actively exploit live infrastructure.
- Do not include real secrets, tokens, customer data, or production identifiers.
- Prefer testable regression scenarios over vague prose findings.
- Model exploit chains when individually low-severity issues compose into a
higher-risk path.
- Use repo-local fixture IDs and helper patterns when proposing tests.
