菜单
Run a repo-wide quality offensive for <SCOPE>. Use when the user says "ultracode", "repo offensive", "quality offensive", "codebase cleanup", or explicitly requests a full-coverage quality offensive, pre-release hardening, or inherited-codebase cleanup.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | repo-offensive |
| description | Run a repo-wide quality offensive for <SCOPE>. Use when the user says "ultracode", "repo offensive", "quality offensive", "codebase cleanup", or explicitly requests a full-coverage quality offensive, pre-release hardening, or inherited-codebase cleanup. |
| disable-model-invocation | true |
Default posture: Maximum throughput. Disregard cost. Exhaustiveness and correctness over efficiency. This skill loads into the main conversation. The deterministic workflow lives in
.claude/workflows/repo-offensive.jsand is invoked manually via the Workflow tool.
Run the skill (loads instructions):
/repo-offensive
Run the workflow (deterministic execution):
/repo-offensive-workflow
Or invoke the script directly via the Workflow tool:
Workflow({ scriptPath: ".claude/workflows/repo-offensive.js" })
When the user asks for a repo offensive, follow this pattern. Treat this as a deterministic workflow, not a normal chat.
First frame the mission:
Recon the repo:
Run repeated discovery waves until dry. Each wave fans out independent specialist agents across:
Every finding must include:
Dedupe aggressively. Send each surviving P0/P1/P2 through an evidence court.
For every P0/P1/P2 finding, spawn 3 skeptics in parallel:
Accept only findings with 2/3 non-low-confidence real votes.
Convert verified findings into conflict-aware implementation slices:
dependsOn and parallelSafe.Implement only low/medium-risk slices unless explicitly told otherwise.
Finish with a validation gauntlet:
/repo-offensive).maxWaves: 4 — no infinite loops.The deterministic workflow is at .claude/workflows/repo-offensive.js. It is a resume-safe, loop-until-dry multi-agent offensive. Reference it from this skill when orchestrating.
Implement a feature using an implementation tournament with competing designs, judge scoring, and champion synthesis. Use when the user says "ultracode", "implementation tournament", "tournament", "design competition", or explicitly requests /implementation-tournament or a feature-building workflow with multiple competing strategies.
Run a quality gate council before shipping. Use when the user says "ultracode", "quality gate", "gate council", "ship check", "pre-ship review", "before this ships", or explicitly requests /quality-gate-council or a pre-push/pre-merge validation council.
Review a pull request or diff by fanning out one reviewer per changed file and adversarially verifying every issue before reporting. Use this WHENEVER the user asks to review a PR, review a diff, "look over these changes", check a branch before merge, or do a code review of more than a couple of files — even if they don't say the word "workflow". Prefer this over a single-pass review whenever the diff spans several files or the cost of missing a bug is high.
Sweep a codebase for real, reproducible bugs using diverse finder agents in a loop-until-dry, with every candidate confirmed by a multi-lens majority vote. Use this WHENEVER the user wants to "find bugs", do a bug hunt, audit a service/module for defects, hunt for a class of bug (races, null derefs, leaks, off-by-one), or shake out problems before a release — even without the word "workflow". Prefer this over reading files one-by-one whenever coverage across many files matters.
Audit every dependency in parallel — CVEs, breaking changes, maintenance health, and dead/unused packages — then rank by risk and produce an upgrade/remediation plan. Use this WHENEVER the user asks to audit dependencies, check for vulnerable/outdated packages, find unused deps, plan upgrades, or review package.json / requirements.txt / Cargo.toml / go.mod — even without the word "workflow". Prefer this over eyeballing a manifest whenever there are more than a handful of dependencies.
Root-cause a hard incident by generating competing hypotheses, gathering evidence for each in parallel, adversarially refuting them, and synthesizing the surviving root cause with a minimal fix and a verification plan. Use this WHENEVER the user is debugging a production incident, a flaky/intermittent failure, a regression, a mysterious stack trace, or asks "why is this happening / what's the root cause" — even without the word "workflow". Prefer this over a single linear debugging pass whenever the cause is non-obvious and the stakes are high.