菜单
Serialized security audit using 23 deep framework subskills. Each framework runs in its own agent context with expert-level depth. Smart interview pre-fills from conversation context.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Keep a live interactive chat session coming back to itself, visibly, after a usage/session cap interrupts it, never a silent background process. Invoke with /qq-cap-resume, or say “keep this session alive,” “resume yourself after the cap,” “don’t go dark on me,” any time a long interactive burn needs to survive a 5-hour session cap or ride out to a weekly reset without leaving you staring at a dead thread.
The unbounded end of the AFK spectrum: spend whatever it takes for quality, budget isn’t the constraint. Stand up a self-healing, fully-autonomous “kitchen-sink max-effort” campaign for a big multi-day initiative: resilience first, creative meta strategy, workflows spawning workflows, audit-gated quality, a phone-glanceable status surface with a proud wins list, and a long living tasklist. Invoke when you say “go HAM”, “go-ham”, “go afk ham”, “qq-go-afk-ham”, “kitchen sink”, “blow me away”, “use all the quota”, or hand it a large ambitious build to run autonomously for hours or days. For the frugal end, use `qq-go-afk-lean`; for the adaptive middle, use `qq-go-afk-smart`.
The adaptive middle of the AFK spectrum: picks the right model task by task, moment by moment, instead of committing to either extreme. Stand up a calm, self-healing, fully-autonomous overnight worker for a well-scoped punch list: the top-tier model writes strict specs and does quality control, cheap and free models do the grunt work, one bounded task per cycle, each one deployed and live-verified, a phone-glanceable status surface, and a durable done log. Invoke when you say “go afk smart”, “go-afk-smart”, “qq-go-afk-smart”, “go smart”, “bounded overnight”, “delegate and verify overnight”, or hand it a finite, well-specified backlog (a punch list, a rollout, a sweep) to grind down autonomously while you sleep, without the kitchen-sink fan-out of go HAM. For the unbounded end, use `qq-go-afk-ham`; for the frugal end, use `qq-go-afk-lean`.
The moment a real, avoidable mistake happens, name it plainly, root-cause the general class of it rather than just this one instance, and fix it at a level that prevents a repeat, not a note that gets written and forgotten. Then, before starting work that looks like it could repeat that shape, check the log first. A second occurrence of the same mistake means the note wasn’t enough, and it needs to become a real check instead of a reminder. Invoke with /ww-mistake-ledger, or say “log this mistake,” “close the loop on this,” “add this to the mistake log,” “check the mistake log first,” right after a preventable error, or right before starting work that resembles one already logged.
Ask what would make this fail before you build it, not after. A one-question design-time gate, imagine it’s already broken three months from now, work backward to the most likely cause, and let the answer change the plan instead of just getting noted and ignored. Works on code, an automation, a process, or a decision. Invoke with /ww-premortem, or say “what breaks this in three months,” “pre-mortem this,” “why would this fail,” “before I build this,” at the moment you’re about to commit to an approach, not after you’ve already started.
Before filling a gap in what you know with a guess, check whether the guess is load-bearing. If getting it wrong would mean redoing real work, or building on a false premise, ask a real question with concrete options instead of assuming silently. If it’s genuinely low-stakes, state the assumption out loud and keep moving rather than stalling on it. Works on any ambiguous request, with or without an AI agent involved. Invoke with /ww-questioning, or say “wait, let me ask first,” “is this load-bearing,” “check before I guess,” “clarify before building,” whenever a request has more than one reasonable reading and you’re about to just pick one.
| name | qq-audit-security |
| description | Serialized security audit using 23 deep framework subskills. Each framework runs in its own agent context with expert-level depth. Smart interview pre-fills from conversation context. |
| version | 3.0.0 |
| triggers | ["security audit","vulnerability audit","owasp review","security framework review","pen test","run security audit"] |
Part of Claude Code operator skills: a collection of skills for running a real Claude Code setup.
Audit security by running 23 expert personas in serial, fixing critical issues per framework before verifying.
23 security frameworks, each loaded as a deep expert persona into its own agent context. Serial execution: one framework → fix critical issues → verify → next. Each agent thinks like a 20-year specialist in that specific framework.
Expert lens: Is it safe? Would a security engineer approve?
Supersedes: ad-hoc security checklists, one-off OWASP scans.
This skill responds to three modes based on the args passed. Interpret intent loosely: fuzzy matching, not exact phrasing.
Triggers: /qq-audit-security, "run all", "full audit", "everything", no args at all.
Triggers: /qq-audit-security OWASP Top 10, "just run XSS on the form handler", "CSRF on the checkout flow", etc.
Match the framework name fuzzily: "owasp", "top 10", "xss", "cross site scripting" should all match the right framework. "csrf", "anti-forgery", "request forgery" should all match CSRF Protection. If ambiguous, show the 2-3 closest matches and ask.
Triggers: "list", "what do you have", "what frameworks", "help", "which ones", "show me", etc.
Show the framework table from the framework inventory below, then ask which one(s) to run.
DO NOT ask dumb questions. Before asking anything, gather what you already know:
Pre-fill and present assumptions:
"Here’s what I know going in:
- Product: [name] ([description from context])
- Tech stack: [framework, language, hosting, inferred from project]
- Auth model: [session-based / JWT / OAuth, inferred from code]
- Known attack surface: [public APIs, file uploads, user input, third-party integrations]
- Scope: [full app / specific endpoints / specific component]
Anything wrong or missing?"
Use AskUserQuestion with multiple choice ONLY for genuine gaps. For example, if you truly can’t tell whether auth is session-based or JWT, ask. If you can infer it, state the inference.
Interview output becomes the audit context: passed to every framework agent so they audit with purpose, not generically.
For each framework (in order 1-23):
Spawn one agent with these instructions:
~/.agents/skills/qq-audit-security/frameworks/[NN-name].md"Collect the agent’s output:
Verify build if fixes were applied (npx next build or equivalent)
Update cumulative state:
Move to next framework
Save to project’s data directory:
data/audit-security-[date].md: full reportdata/audit-security-[date]-summary.md: scores + critical findings only| # | Framework | Expert lens | Subskill file |
|---|---|---|---|
| 1 | OWASP Top 10 | The ten most critical web application security risks: is the app defended against the attack classes that actually matter? | 01-owasp-top-10.md |
| 2 | Injection Prevention | All data entering queries parameterized: is untrusted input ever interpreted as code? | 02-injection-prevention.md |
| 3 | Cross-Site Scripting (XSS) Prevention | User content escaped in every rendering context: can an attacker execute scripts in another user’s browser? | 03-xss-prevention.md |
| 4 | CSRF Protection | State-changing operations require anti-CSRF tokens: can an attacker trick a user’s browser into making unwanted requests? | 04-csrf-protection.md |
| 5 | Authentication Security | Resists credential stuffing, brute force, and identity spoofing: can the application reliably prove who someone is? | 05-authentication-security.md |
| 6 | Authorization / Broken Access Control | Every object access checks server-side permissions: can users reach resources or functions they shouldn’t? | 06-authorization-enforcement.md |
| 7 | Sensitive Data Exposure | Encrypted at rest and in transit, no secrets in logs: is sensitive data protected throughout its lifecycle? | 07-sensitive-data-exposure.md |
| 8 | Content Security Policy (CSP) | Strict CSP preventing inline scripts and unauthorized origins: does the browser enforce what code is allowed to run? | 08-content-security-policy.md |
| 9 | Dependency Vulnerability Audit | Third-party CVEs and timely patching: are the application’s dependencies free of known exploitable vulnerabilities? | 09-dependency-vulnerabilities.md |
| 10 | Security Headers Audit | HSTS, X-Content-Type-Options, and friends: do HTTP response headers harden the browser’s security posture? | 10-security-headers.md |
| 11 | API Security / Broken Function-Level Authorization | Function-level authorization on every API endpoint: can callers invoke operations they shouldn’t have access to? | 11-api-security.md |
| 12 | File Upload Security | Validated type, size, and content, stored safely: can an attacker weaponize the file upload feature? | 12-file-upload-security.md |
| 13 | Session Management Security | Timeout, rotation, secure cookies, and invalidation: can an attacker hijack, fixate, or ride a user’s session? | 13-session-management.md |
| 14 | Cryptographic Practices | Current algorithms, proper key lengths, and sound key management: is the application’s cryptography actually protecting what it claims to protect? | 14-cryptographic-practices.md |
| 15 | SSRF Prevention | User-controlled URLs validated before server-side fetch: can an attacker make the server request internal resources? | 15-ssrf-prevention.md |
| 16 | Mass Assignment / Over-Posting | Only whitelisted fields accepted on write operations: can an attacker modify fields they shouldn’t by including extra parameters? | 16-mass-assignment.md |
| 17 | Business Logic Abuse | Business rules enforced server-side: can an attacker exploit the application’s intended functionality for unintended outcomes? | 17-business-logic-abuse.md |
| 18 | DNS/Subdomain Security | No dangling CNAMEs, proper email authentication: is the DNS infrastructure defended against hijacking and spoofing? | 18-dns-subdomain-security.md |
| 19 | Client-Side Storage Security | No tokens or PII in localStorage: is the client-side storage model defended against extraction, persistence, and cross-site access? | 19-client-storage-security.md |
| 20 | Clickjacking Protection | Frame-ancestors CSP and X-Frame-Options: can an attacker trick users into clicking hidden elements by framing the application? | 20-clickjacking-protection.md |
| 21 | Supply Chain Security | Build pipeline protected per SLSA: can an attacker inject malicious code through dependencies, build tools, or CI/CD infrastructure? | 21-supply-chain-security.md |
| 22 | Secrets Rotation | Never in code, always auditable: are secrets managed with proper lifecycle controls, rotation, and zero-code-exposure guarantees? | 22-secrets-rotation.md |
| 23 | Privacy/Data Minimization | Only necessary data collected and retained per GDPR Art. 5: does the application collect the minimum personal data required and delete it when no longer needed? | 23-privacy-data-minimization.md |