| 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: .
