tree-search-coder

name	tree-search-coder
description	Execution-gated branching code generation (ADR-020 Surface 2). Generate N candidate solutions (default ≤5) by invoking `sparc:coder` with varied temperature/framing, execute each in a fresh `KernelSession` via the `code-interpreter` (ADR-018 kernel) MCP, score every branch by assertion-pass count, and select the highest-scoring candidate (tie-break on shortest code). Slow, N× token cost, mandatory `spend_cap_usd` — NEVER auto-routed; only ever invoked explicitly. Use for correctness-critical generation where a single attempt is demonstrably insufficient and the measured +26.9% correctness lift (ORPS) justifies the cost. NOT for a single generation attempt (use `sparc:coder`), depth-on-one QE/TDD (`build-with-quality`), one-trajectory stateful loops (`codeact`), or applying a known edit (`Edit`/`aci.edit_file`).
version	0.1.0
triggers	["/tree-search-coder","tree search this","best of N candidates","generate and rank code candidates","execution-gated code search"]
depends_on_mcps	["code-interpreter"]
optional_mcps	["aci-shell"]
manifest_gate	[skills.tree_search_coder] enabled = true
related_skills	["sparc-coder","build-with-quality","codeact","verification-quality"]

Tree-Search Coder Skill

Execution-gated tree-search over code candidates (ADR-020 Surface 2). This skill carries no code of its own — it is an orchestration pattern that composes sparc:coder (candidate generation) with the code-interpreter (ADR-018 kernel) MCP (candidate verification). It generates a tree of alternative programs, executes each branch, scores by execution outcome, and selects the best.

The verification signal is Trace-as-Reward (DDD-005): a branch's score is its assertion-pass count observed in a real ExecutionTrace, never an LLM opinion about whether the code "looks correct". No LLM judge sits in the critical path.

Research basis: ORPS (arXiv 2412.15118) reports +26.9% correctness and +42.2% code efficiency from execution-gated tree-search across 5 models and 3 benchmarks with no fine-tuning; Tree-of-Code (arXiv 2412.15305) reports ~+20% accuracy with fewer turns.

---

When to choose

Reach for tree-search-coder only when all of these hold:

• The task is correctness-critical — a subtly-wrong answer is expensive (tricky edge cases, numerical boundaries, parser/state-machine logic, an algorithm with a known-hard corner).
• A single attempt is demonstrably insufficient — you have already tried sparc:coder once, or you have strong prior that first-shot generation will miss an edge case.
• You have executable assertions or a test suite that discriminate a correct candidate from a plausible-but-wrong one. Tree-search is only as good as the signal it scores against; with no discriminating assertions every branch ties.
• The N× token/latency cost is justified by the value of getting it right, and an explicit spend_cap_usd bounds the blast radius.
• You are explicitly opting in — a user request, a /tree-search-coder directive, or a coordinator that has decided this task warrants search.

If any of those is false, this is the wrong tool — see the negative-routing reference below.

---

How it works (in brief)

Seven steps: generate N candidates (sparc:coder, varied framing) → fresh kernel per branch (kernel.reset) → execute assertions (kernel.exec) → score on assertion-pass count → select highest (tie-break shortest code) → honour the mandatory spend_cap_usd (halt + return best-so-far) → emit the audit trajectory. Full step contract, manifest gate (//), and URN/ span schema: .