best-practices-competition

# Best Practices: Competition Use this skill to run a competition that produces usable engineering signal: isolated candidates, identical task packets, explicit judging criteria, local verification, and a bounded revision request for the selected winner. A competition is not a roundtable. Competitors do not deliberate with one another, and the project agent does not share participant information between candidate lanes or rounds. The project agent judges the work against the codebase, skill contracts, and deterministic evidence. ## Core Rule Compete candidates are claims until checked. The project agent owns the competition contract, candidate isolation, artifact collection, feature verification, scorecard, winner decision, and final winner-only continuation. `$ask` owns the runtime entrypoint and should compile the competition into Tau-owned candidate nodes and a join node. For iterative competitions, the control plane is a dynamically expanding Tau DAG: each round adds the next candidate or winner-continuation nodes under the same immutable goal, or launches an explicitly linked next-round Tau DAG when the installed runtime cannot append nodes in place. `$tau`, `$surf`, `$browser-oracle`, and `$scillm` own transport and provider execution. Browser-backed handlers and API-backed handlers are peers. Do not privilege or discard a candidate merely because it arrived through a different transport. The project agent may coach each participant between its own iterations with the project agent's review of that participant's output, local deterministic findings, and external research from `$brave-search`, `$github-search`, or `$dogpile`. That help must stay lane-local unless it is shared public evidence added to a fresh common task packet for every candidate. Never leak another candidate's approach, code, score, feature ideas, or failure analysis. ## Use This When - The user asks for a competition, compete run, bakeoff, isolated candidates, a winner, or "best of several implementations." - The task has multiple plausible implementation paths and comparison will improve the final patch. - The candidates may mix browser seats such as `webgpt`, `webclaude`, `webkimi`, or `webgemini` with `$scillm` model seats. - The project agent can locally inspect candidate output and verify reusable features before promoting them. ## Do Not Use This When | Request shape | Better route | | --- | --- | | Shared deliberation or synthesis | `$ask` roundtable with `$best-practices-roundtable` | | N independent answers the human reads, no winner | `$ask one-shot` with `$best-practices-one-shot` | | One answer from one handler | `$ask` single handler | | Creator then pass/fail reviewer | `$ask tau-dag --topology sequential` | | A deterministic repair is already obvious | Apply and test the repair directly | | The judge cannot inspect the target repo or artifact | Stop with `NEEDS_ATTENTION` | | The user needs a human policy decision | Ask the human directly | ## Source-Derived Step Model 1. **Define the competition contract.** State the objective, immutable goal or acceptance bar, target repo/path, allowed files, candidate count, judging criteria, output schema, and proof boundary. 2. **Freeze the shared task packet.** Every candidate receives the same task, context, constraints, and expected output. Do not tailor hidden context to favor one handler. 3. **Choose isolated candidates.** Use at least two handlers. Mix browser and API handlers when useful. Treat `webclaude` as a strong default candidate for hard work; when available in `$ask`, prefer `Opus 5 High` for that browser seat. 4. **Compile through `$ask compete`.** Use `$ask` as the front door. The competition should become a Tau DAG with concurrent candidate nodes and a join node. If the competition spans more than one round, preserve the same immutable goal hash and link each next-round DAG to the previous round's receipts. 5. **Preserve all receipts.** Read `request.json`, `dag.json`, command specs, candidate receipts, candidate responses, scorecard, and winner revision request. Missing, blocked, stale-tab, or rate-limited candidates must be visible in the scorecard. 6. **Normalize candidate outputs.** Extract concrete changes, proposed files, test commands, risk notes, and `VERIFIED_FEATURE:` claims. Do not let prose style or confidence decide the winner. 7. **Review each candidate iteration.** For each participant, inspect only that participant's artifacts plus the original task packet, local repo state, and tool-backed research. Use `$brave-search`, `$github-search`, or `$dogpile` to unblock the participant when research can answer a concrete implementation question. Send feedback back only to that same lane. 8. **Verify reusable features locally.** A candidate feature is promotable only after the project agent checks it against repository state, skill contracts, and the narrow deterministic proof command. Unchecked features stay out of the winner request. 9. **Harvest useful features after N rounds.** After the configured round count, or earlier if the evidence clearly converges, decide feature-by-feature what is useful. Losing participants may provide no useful ideas, one useful feature, or several useful features; the project agent decides from local evidence and records accepted, rejected, and unchecked feature claims. Do not share the harvested list with candidates until the isolated competition phase has closed. 10. **Score with evidence.** Score criteria such as correctness, minimality, maintainability, contract fit, proof quality, and failure handling. Tie every score to artifacts or local checks. 11. **Pick a winner or fail closed.** Pick a winner only when one candidate has a clear evidence-backed advantage. If candidates are tied, incomplete, blocked, unverifiable, or all wrong, report `NEEDS_ATTENTION` instead of fabricating a winner. 12. **Continue with the winning participant.** Once the winner is chosen, stop the broad competition and continue iterating with the winning participant until the immutable goal is met or a real `NEEDS_ATTENTION` blocker is recorded. Ask the winner to keep its own implementation as the base and add only locally verified features harvested from other candidates. The winner-continuation request is a next step, not proof that the revision happened. 13. **Verify the final implementation locally.** Competition output can guide the patch, but closure requires local deterministic evidence appropriate to the task. ## Competition Packet Every substantial competition prompt should include: ```text Objective: Immutable goal or acceptance bar: Target repo/path: Allowed files or boundaries: Shared context: Candidate handlers: Judging criteria: Expected candidate output: Forbidden claims: Proof boundary: ``` Ask every candidate for: - `APPROACH`: concise strategy. - `CHANGES`: specific files, functions, commands, or artifacts. - `VERIFIED_FEATURE`: only features that the project agent can check locally. - `RISKS`: failure modes, omitted cases, and assumptions. - `PROOF_COMMANDS`: exact commands the project agent should run. - `BLOCKERS`: only missing input, credentials, or external state. ## Iteration And Research Rules The project agent may run iterative competitions, but isolation still applies. Treat those iterations as a dynamically expanding Tau DAG: round 1 creates isolated candidate nodes and a join node; later rounds add lane-local repair nodes, fresh common-task candidate nodes, or a winner-continuation node with explicit dependencies on the prior receipts. If the current `$ask` or `$tau` runtime cannot mutate an existing DAG, the project agent must launch a linked next-round DAG with the same immutable goal hash and cite the previous run directory as input evidence. Allowed lane-local help: - ask a participant to repair its own failed proof gate; - give a participant the project agent's review of that participant's output; - provide deterministic local errors from that participant's attempted patch; - run `$brave-search web`, `$github-search`, or `$dogpile` for a concrete blocker and provide the retrieved public evidence to that participant; - update all participants with a fresh common task packet when the same public evidence should apply to everyone. Forbidden cross-lane leakage: - another participant's code, approach, prompt, score, or review; - "candidate B solved this by..." hints; - merged feature lists before winner selection; - using one participant as an uncredited reviewer of another participant; - sharing failure analysis from one lane with another lane unless the human explicitly converts the competition into a roundtable. If cross-lane leakage happens, mark the competition contaminated and restart from a fresh shared packet or convert it to a roundtable with human approval. ## Winner Continuation After N rounds, do not keep all candidates alive by default. The project agent must choose a clear winner when evidence supports one, then continue iterating with the winning participant until the immutable goal has been met. Winner continuation packet: ```text Winning participant: Immutable goal: Winner base to keep: Verified features to add: Rejected or unchecked features to exclude: Required proof commands: Stop condition: ``` Only locally verified harvested features may be included. A losing participant may or may not contribute useful ideas; the project agent decides feature by feature and records the reason. If the winner cannot make progress after a focused continuation attempt, either run one explicit fallback round with the remaining candidates or report `NEEDS_ATTENTION` with the failing evidence. ## Count candidates that ANSWERED, not candidates dispatched "Fewer than two candidates" must be measured on answers. Dispatching two seats and receiving one is a single opinion wearing a competition's artifacts. Observed 2026-08-16: a compete run dispatched `webgpt` and `webclaude`, one answered, and the scorecard still read `candidates: 2`. That run stayed honest only because it also reported `NEEDS_ATTENTION`; a scorecard naming a winner off one answer would have been indistinguishable from a real competition. ```bash skills/ask/run.sh panel-audit <run-dir> --mode compete ``` The audit fails the run when fewer than two candidates produced a non-empty response and the status is not already `NEEDS_ATTENTION`/`BLOCKED`. ## Isolation is checkable, so check it Do not assert isolation from the fact that you did not intend to leak. Look for a rival's response text inside each candidate's prompt -- that is the shape leakage actually takes when a join, a retry, or a recovery path rebuilds a packet from prior artifacts. Compare task bodies too: every candidate must receive a byte-identical packet once per-seat addressing (`Handler:`, `Model:`, `Browser model preference:`) is removed. A packet tailored to one candidate is a rigged competition even when the tailoring looks harmless. ## A transport failure is not a candidate verdict A candidate that died before reaching its provider has produced no evidence about its approach. Record it as a transport blocker with its exact failure, never as a weak entry. This matters more than it sounds: on 2026-08-16 every non-`webgpt` browser seat was failing on a CLI usage error (`unrecognized arguments: --stable-stall-ms`) before opening a page. Read as candidate quality, that would have "proved" webgpt superior across every competition ever run on this machine. Always separate `did not run` from `ran and lost`. ## Charts before and after the run Compile first and show the human the DAG chart before any multi-candidate `--execute`: `$ask` prints it at compile and persists it as `dag-chart.initial.txt` (candidates, join-gate, reviewer lenses, judge, join all visible). After the run, read `dag-chart.final.txt` — per-node verdicts on the same topology — and reconcile it with the scorecard: a candidate's node line must agree with its lane artifacts, and a judge node reading FAIL or NO_RECEIPT invalidates any winner claim. The final chart is also the project agent's SELF-CORRECTION instrument: walk its node lines before writing the scorecard. Every non-PASS node is a work item -- read that lane's receipts and fix, rerun, or name the blocker before any verdict is reported. Both artifacts are eval-enforced in `$ask`. ## Scoring Contract The project agent's scorecard must include: - candidate status: responded, blocked, stale tab, timed out, rate-limited, or not run; - artifact paths for every candidate; - feature claims accepted, rejected, or unchecked; - harvest decision for every useful feature considered from every candidate; - local checks run by the project agent; - criterion scores with evidence; - winner, tie, or `NEEDS_ATTENTION`; - bounded winner-continuation request and status, if a winner exists. Do not score a candidate higher for sounding confident. Score only what can be reconciled with the task packet, codebase, skill contracts, and proof artifacts. ## Ask Integration Use `$ask` for execution. Do not replace competitions with informal subagents or manual browser prompts. Compile-only example: ```bash cd skills/ask ./run.sh compete "Implement the focused patch. Return concrete reusable features as VERIFIED_FEATURE lines only when locally checkable." \ --repo local/agent-skills \ --target ask-competition-example \ --handler webgpt \ --handler webclaude \ --handler gpt-5.5-high \ --handler-project webgpt=tau \ --criterion skill-contract \ --criterion deterministic-proof \ --json ``` Add `--execute` only when live browser/provider calls are authorized and the required browser-oracle bindings or provider credentials are available. ## Fail-Closed Rules | Condition | Behavior | | --- | --- | | Fewer than two candidates | Request another handler or emit `NEEDS_ATTENTION` | | Candidate sees another candidate's output or score | Restart; isolation was broken | | Missing candidate receipt | Mark that candidate `NEEDS_ATTENTION` | | Candidate feature is not locally checkable | Do not promote it | | All candidates fail the same gate | Stop the family and report systemic failure | | No clear evidence-backed winner | Report tie or `NEEDS_ATTENTION` | | Winner-continuation request exists | Treat it as a request packet, not final proof | ## Common Failure Modes | Failure mode | Required correction | | --- | --- | | Roundtable disguised as competition | Re-run as isolated `$ask compete` | | Consensus substituted for judging | Use roundtable, or verify features locally | | Cross-lane coaching | Restart or convert to roundtable with human approval | | Tool help omitted for a research blocker | Use `$brave-search`, `$github-search`, or `$dogpile` lane-locally | | Feature harvesting without proof | Remove unchecked features from the winner request | | Winner picked from style | Score against criteria and artifacts | | Over-broad final revision | Bound the request to verified features only | | Ignored losing candidate insight | Preserve rejected and accepted feature reasons | | Competition continues after clear winner | Close competition and iterate with the winner | | Browser/API transport hidden | Mark per-candidate transport status explicitly | ## Closure Boundary A competition can close its selection phase when it has: - a frozen shared packet; - isolated candidate receipts; - a scorecard with local checks; - explicit accepted/rejected/unchecked feature claims; - a winner, tie, or `NEEDS_ATTENTION`; - a bounded winner-continuation request when a winner exists. It cannot close the user's immutable goal by itself. Final closure requires the selected implementation to be applied and locally proven against that immutable goal.