菜单
Meta-orchestrator that selects and sequences the right combination of audit domains based on project context, conversation state, and user intent. Routes to 13 domain-specific audit skills containing 255 expert-persona frameworks.
用 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-master |
| description | Meta-orchestrator that selects and sequences the right combination of audit domains based on project context, conversation state, and user intent. Routes to 13 domain-specific audit skills containing 255 expert-persona frameworks. |
| version | 2.0.0 |
| triggers | ["full audit","audit everything","quality audit","what should I audit","run audits","comprehensive audit"] |
Part of Claude Code operator skills: a collection of skills for running a real Claude Code setup.
Route to 13 domain-specific audit skills intelligently based on project needs and sequence them.
Routes to 13 domain-specific audit skills (255 total expert-persona frameworks) based on what the project needs. Knows which domains matter for which kinds of work and sequences them intelligently.
Triggers: /qq-audit, "audit this", "what should I audit", "full audit", etc.
Analyze the project context and recommend a tailored audit plan:
Identify the project type from conversation context, files, and CLAUDE.md:
Check what's already been audited: look for data/audit-* reports in the project. Don't re-run domains that were audited recently unless explicitly asked.
Present the recommendation:
"Based on [project type], I'd recommend these audits in this order:
- Product (20 frameworks): verify the product is right before polishing
- UX (20 frameworks): then make sure humans can use it
- Visual (22 frameworks): then make it look professional
- Copy (22 frameworks): then audit the writing
- Frontend (22 frameworks): then verify code quality
Skip: Backend, DevOps, Compliance (not applicable here)
Run all 5? Or pick specific ones?"
Use AskUserQuestion with the recommended domains as options (multiSelect).
Triggers: /qq-audit ux + copy, "audit product and visual", "run ux then frontend", etc.
Parse the domain names from args (fuzzy match), sequence them in the recommended order, and execute each by invoking its /qq-audit-[domain] skill.
Triggers: /qq-audit pre-launch, /qq-audit quick, etc.
| Profile | Domains | When to use |
|---|---|---|
| quick | UX, Visual, Copy | Fast quality check on appearance and usability |
| pre-launch | Product, UX, Visual, Copy, Frontend, Performance, Security, SEO | Before going live |
| post-build | UX, Visual, Copy, Frontend | After completing a feature build |
| deep | All 13 domains | Comprehensive quality audit |
| code | Frontend, Backend, Testing, Security, DevOps | Engineering quality |
| user-facing | UX, Product, Visual, Copy, Performance | Everything the user touches |
| marketing | Copy, Visual, SEO, Performance | Marketing site quality |
Triggers: "list", "what domains", "show me everything", "help", etc.
Show the domain inventory table below.
| # | Domain | Command | Frameworks | Expert lens |
|---|---|---|---|---|
| 1 | UX | /qq-audit-ux | 20 | Does the brain work well with this? |
| 2 | Product | /qq-audit-product | 20 | Is this the right product? |
| 3 | Visual UI | /qq-audit-visual | 22 | Does this look professional? |
| 4 | Content/Copy | /qq-audit-copy | 22 | Is the writing good? |
| 5 | Frontend | /qq-audit-frontend | 22 | Is the code well-built? |
| 6 | Performance | /qq-audit-performance | 22 | Is it fast? |
| 7 | Security | /qq-audit-security | 23 | Is it safe? |
| 8 | QA/Testing | /qq-audit-testing | 22 | Is it tested? |
| 9 | Backend/API | /qq-audit-backend | 22 | Is the server-side solid? |
| 10 | SEO | /qq-audit-seo | 15 | Can people find it? |
| 11 | DevOps | /qq-audit-devops | 15 | Is it deployable and resilient? |
| 12 | Data Quality | /qq-audit-data | 15 | Is the data trustworthy? |
| 13 | Compliance | /qq-audit-compliance | 15 | Is it legally sound? |
| Total | 255 |
Domains are sequenced by the agency build lifecycle. Each phase depends on the previous being stable. Auditing visual design when UX is broken wastes time, because you'll redesign screens after UX fixes.
| Phase | Domain | Input | Why this order |
|---|---|---|---|
| Strategy | Product | Screenshots | Is this even the right thing? Fix before building more. |
| UX | UX | Code + screenshots | Can humans use it? Fix before making it pretty. |
| Design | Visual | Screenshots (+ CSS) | Does it look professional? Fix before copy audit, since copy lives in visual context. |
| Content | Copy | Code + screenshots | Are the words right? Fix after visual context is settled. |
| Build | Frontend | Code only | Is the client code well-built? |
| Build | Backend | Code only | Is the server code solid? |
| Optimize | Performance | Code + browser | Is it fast? Measure after code is clean. |
| Harden | Security | Code only | Is it safe? |
| Verify | Testing | Code only | Is it tested? |
| Launch | SEO | Code + rendered output | Can people find it? |
| Ship | DevOps | Code/config | Is it deployable? |
| Measure | Data | Code + dashboards | Is analytics working? |
| Protect | Compliance | Code + UI | Is it legally sound? |
The rule: Each domain converges before the next begins. Don't audit downstream until upstream is stable.
Input types:
For domains requiring screenshots: if agent-browser is available, capture screenshots at the start of each domain audit. If not, instruct the framework agents to read the rendered component code and reason about visual output.
Each domain runs a convergence loop, not a single pass.
Round 1: Run all frameworks → Score → Fix criticals
Round 2: Re-run all frameworks → Score → Fix remaining
Round 3: Re-run all frameworks → Final score
Convergence target: Configurable via smart interview (see below). Default 9.5/10. Internal tools typically 9+, client projects with buy-in 7-8.
Convergence rules:
Why convergence matters: A single pass finds ~60% of issues. Round 2 finds 25% more (because fixes from round 1 expose new issues or fix old ones). Round 3 catches the last 10-15%. Diminishing returns after round 3: remaining gaps are architectural.
Between domains: After a domain converges, brief the user: "UX converged at 9.6 after 2 rounds (35 fixes). Ready for Visual?" Always pause for direction before starting the next domain.
For each selected domain (in order):
/qq-audit-ux with any scope constraintsBetween domains, ask: "Ready for [next domain]? Or adjust the plan?"
Before selecting domains, gather context the same way domain orchestrators do, but at the project level:
Pre-fill everything possible. Only ask about genuine gaps. The target score question is ALWAYS asked, never inferred.
At the start of every audit run, create a Notion page in your own deliverables/tracking database. Set its data source ID in your project config rather than hardcoding one here.
Properties:
Page structure (update live as the audit progresses):
A domain status table showing the full audit at a glance:
| Phase | Domain | Score | Target | Rounds | Status |
|------------|------------|-------|--------|--------|--------|
| Strategy | Product | 9.2 | 9.5 | 2/3 | 🔄 |
| UX | UX | – | 9.5 | 0/3 | ⏳ |
| Design | Visual | – | 9.5 | 0/3 | ⏳ |
| Content | Copy | – | 9.5 | 0/3 | ⏳ |
| Build | Frontend | – | 9.5 | 0/3 | ⏳ |
...
Status emoji: ⏳ pending, 🔄 in progress, ✅ converged, ⚠️ hit max rounds, ⏭️ skipped
Each domain gets a toggle heading that expands to show:
| # | Framework | Score | Findings | Fixes | Remaining |
|---|---------------------|-------|----------|-------|-----------|
| 1 | Nielsen's heuristics | 9/10 | 3 | 3 | 0 |
| 2 | Gestalt principles | 8/10 | 5 | 4 | 1 |
...
A running log of the spiciest takeaways as each framework completes. Newest at top. This is NOT a dry findings list. It's the "holy shit" moments, the surprising discoveries, the patterns that change how you think about the product.
Format (one entry per framework):
**14:32 – Fitts's Law (UX, Round 2)** ⬆️ 6→9
Delete button is 12px from Save on mobile. Users WILL fat-finger this.
Fixed: moved Delete to overflow menu, Save now full-width.
→ 3 fixes applied, 0 remaining
What makes a good entry:
What to skip:
MANDATORY: 3-5 sentences, no jargon. What was audited, current score, biggest problem, improvement from last audit. Updated after each domain converges with a cumulative view.
After each domain completes, add a 1-2 sentence summary at the top of that domain's toggle section. Lead with the score and the single most important finding. No framework names, just plain language.
After all domains converge:
Update frequency: Update the Notion doc after EVERY framework completes (not just per domain). This gives the user real-time visibility into progress. Use the Notion MCP tools to update.
Comments: The user may leave comments on the Notion page. Before starting a new domain, check for comments via include_all_blocks: true and incorporate feedback into the next domain's approach.
After each domain audit completes, append a log line to ~/.agents/skills/qq-audit-master/usage.jsonl:
{"timestamp": "ISO-8601", "domain": "ux", "product": "example-product", "frameworks_run": 20, "findings": 12, "fixes": 8, "score": 85, "duration_min": 45}
This builds the data to answer: which domains find the most issues? Which frameworks are most productive? Where is quality improving over time?
Domains are NOT independent. Findings in one domain directly influence what matters in others. The default lifecycle order (Product → UX → Visual → Copy → Frontend → Backend) can be overridden when interdependencies matter more.
Key interdependencies:
Recommended sequences by project type: