Security audit
Security checks for vulnerabilities and agentic risk
This is a clearly disclosed autonomous coding workflow that can edit the working tree but does not hide behavior or publish changes on its own.
Install this only if you want an agent to make local code changes without checking in during the run. Use it in a clean branch or disposable workspace, review the final diff and any .claude/handoffs content before sharing, and avoid permission-bypass mode outside a sandbox.
a destructive or irreversible step, missing access, an architectural or unimplementable spec, or three failed fixes on one behavior. Use this skill whenever the user says "autopilot", "/autopilot", "run task <id> autonomously", "work this task end to end without asking", "full autonomy on this", "do the whole task, skip commits and PR", or launches a headless run with a task id — even if they don't name the skill. Not for interactive plan approval (task-executor), a queue of tasks (goal-runner), or when commits or PRs should be created (create-pr).
## When to use this skill - "autopilot task 12345" / "run task 12345 autonomously" / "/autopilot 12345" - "work this end to end without asking me anything, skip PR and commits" - A headless (`claude -p`) invocation naming a work item or task description. Do **not** use when the user wants to approve the plan (`task-executor`), has a queue of tasks (`goal-runner`), or wants a commit or PR produced (`create-pr`).
## Examples
- **Headless work item.** "autopilot task 4711" → remote is `dev.azure.com` → `azure-devops` pulls #4711 with two screenshots (both viewed); baseline `47 passed` quoted; 4 increments, each red-then-green under `write-tests`; the diff adds an endpoint → `code-review`, `security-review`, `api-contract-review`, `ship-it` run, one blocker (missing authz) fixed and re-reviewed; report has Requirements 5/5 met, a Skills used table with quoted headings, 2 cited assumptions, a `conventional-commits` block. No commits.
- **Hard stop done right.** "run task 8912 end to end without asking" → task says "remove the legacy sync"; inspection shows production traffic still hitting it (log timestamps quoted). Destructive and contradicts the spec → hard stop after Phase 1, tree untouched, report names the one decision ("confirm the consumer at X is decommissioned").
## Anti-patterns- ❌ "Assumed camelCase keys — matches project conventions." (no instance cited) - ✅ "Assumed camelCase keys — every DTO in `src/api/dto/` uses them (`UserDto.ts:12`). Blast radius: one serializer line." 2. **Hard stops only.** Halt and report (never improvise) when the next step is destructive or hard to reverse (data deletion, force push, dropping schema objects, external side effects); access or credentials are missing; the task is architectural (Phase 0); every reading of the task contradicts the codebase expensively; or three fixes have failed on one behavior. The stop-vs-assume test: *would a wrong guess destroy data, publish something, or cost more to undo than redoing the task?* No → assume and log. Yes → hard stop, with the tree left at the last observed-green state and the one decision needed to resume. 3. **Never commit, push, or create PRs.** The deliverable is a verified working tree plus the report. The human gets the final gate. 4. **Scope is the task, exactly.** Adjacent problems go in "Found along the way", never in the diff. - ❌ Adding a `-j` alias because "it's consistent" when the task said `--json`. ✅ `--json` only; the alias idea goes in Found along the way. 5. **Unobserved is `not run`, never `passed`.** Every Evidence line carries a tag: `verified` (you ran it and quote the output), `inferred` (follows from a named verified fact), `assumed` (unverified; name what breaks if wrong). "Tests pass" is not "requirements met".
No suspicious patterns detected.