old-town

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.

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.

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.

Run a codebase-wide migration as a no-barrier pipeline where each file independently streams through transform → verify → fix in its own worktree, so a many-file change never stalls on the slowest file. Use this WHENEVER the user wants a framework swap, API deprecation cleanup, a codemod, a language-idiom migration, or any "change X to Y across the whole codebase / all these files" task — even without the word "workflow". Prefer this over editing files sequentially whenever the change spans more than ~10 files.

Profiler-guided optimization audit — find real hotspots, fan out an analyst per hotspot to propose concrete optimizations, then a judge panel ranks by impact ÷ effort and refutes anything that would regress correctness. Use this WHENEVER the user wants to make code faster, profile/optimize a service, hunt performance bottlenecks, reduce latency/memory/bundle size, or "find what's slow" — even without the word "workflow". Prefer this over guessing at optimizations whenever the surface is larger than a single function.

Find the most under-tested code, generate a real test suite per unit in parallel, and quality-gate each suite with a judge panel so only tests that run and meaningfully assert behavior are kept. Use this WHENEVER the user wants to add tests, raise coverage, "write tests for this module", backfill missing tests, or harden a service with a test suite — even without the word "workflow". Prefer this over writing tests one file at a time whenever a module or service needs broad coverage.