security-review Skill
Purpose
Use this skill when a task touches command execution, package scripts, CI, deploy files, authentication, secrets, receipts, memory, or user-controlled paths.
Read First
If present, review these before making security-sensitive edits:
- SECURITY.md
- package.json
- .github/workflows/
- src/security-policy.ts
- src/commands/verify.ts
- any file that defines command execution, receipts, secrets, auth, or writable paths
Rules
- Treat install scripts, lifecycle hooks, shell commands, workflows, Docker files, and deploy files as high-risk surfaces.
- Never expose secret values in logs, receipts, docs, tests, or examples.
- Prefer allowlists and structured parsing over broad string matching for security decisions.
- Do not weaken SWD verification, receipt integrity, dry-run behavior, or command review prompts.
- When a change introduces a new writable path, explain how it is constrained.
Verification
- Check that sensitive outputs are redacted before storage.
- Check that command-affecting changes still require explicit human confirmation.
- Prefer read-only verification for CI-facing checks.
Output
When finished, summarize:
- what security-sensitive files changed
- what risks were checked
- what verification was run
- any remaining assumptions or unverified areas
1---2name: security-review3description: Security-focused review rules for command and secret-sensitive changes.4---56# security-review Skill78## Purpose9Use this skill when a task touches command execution, package scripts, CI, deploy files, authentication, secrets, receipts, memory, or user-controlled paths.1011## Read First1213If present, review these before making security-sensitive edits:1415- SECURITY.md16- package.json17- .github/workflows/18- src/security-policy.ts19- src/commands/verify.ts20- any file that defines command execution, receipts, secrets, auth, or writable paths2122## Rules23- Treat install scripts, lifecycle hooks, shell commands, workflows, Docker files, and deploy files as high-risk surfaces.24- Never expose secret values in logs, receipts, docs, tests, or examples.25- Prefer allowlists and structured parsing over broad string matching for security decisions.26- Do not weaken SWD verification, receipt integrity, dry-run behavior, or command review prompts.27- When a change introduces a new writable path, explain how it is constrained.2829## Verification30- Check that sensitive outputs are redacted before storage.31- Check that command-affecting changes still require explicit human confirmation.32- Prefer read-only verification for CI-facing checks.3334## Output3536When finished, summarize:3738- what security-sensitive files changed39- what risks were checked40- what verification was run41- any remaining assumptions or unverified areas