| name | compass-explore-branches |
| description | This skill should be used when a task has multiple genuinely viable approaches and the risk of anchoring on the first idea matters — the user asks to "explore different approaches", "what are my options here", "don't just go with the first idea", "compare a few strategies before we commit", or a scoped problem (from compass-clarify-scope, or compass-solve's Explore stage) needs a decision among distinct paths rather than a single obvious next step. Not for tasks with only one reasonable approach, or for expanding an already-chosen approach into stages (that is compass-decompose-chain's job). |
Generate several genuinely distinct approaches to a scoped problem, score
each one, and select the best — rather than expanding and committing to
whichever approach came to mind first. This is Tree-of-Thoughts, generalized
from strategic planning to any complex decision with meaningful tradeoffs
(built on ../../references/knowledge/tree-of-thoughts.md's
three-phase generate-branches / score-branches / select-and-expand
structure — see ../../references/knowledge/index.md). See
../../references/constraints.md for the context-rot and
plausible-vs-verified constraints that apply across every compass-* skill.
This skill's own methodology stops at selection — it does not expand the
winning branch into concrete stages or actions. That expansion is
compass-decompose-chain's job (the source template's own "Phase 3 —
expand" content), kept separate so the two skills aren't duplicating each
other's methodology.
Step 0 — Confirm the scoped problem and branch count
This skill needs a scopedProblem: a well-scoped problem statement, usually
produced by compass-clarify-scope. If invoked standalone with no prior
scoping step, ask for (or construct from the immediate conversation) a
problem statement concrete enough that "genuinely distinct approaches" is a
meaningful question — a problem so vague that every approach would just be a
restatement of the same idea should go through compass-clarify-scope
first instead.
Default branchCount to 3 (or .claude/compass.local.md's
branch_count, if that file exists and sets it), matching the source
template's Branch A/B/C. Use a different count only when the user
explicitly asks for more or fewer options, or the scoped problem's own
complexity clearly warrants it (cap at 6, or .claude/compass.local.md's
max_branch_count if lower — see the workflow's angle pool).
Unlike self-assess/confab, compass has no output_dir — every
compass-* skill (including this one) returns its result into the
conversation rather than writing a persistent artifact. An optional
.claude/compass.local.md may still exist for branch_count/
max_branch_count overrides (see above); there is nothing else to load
here beyond the inputs above and that one optional file.
Step 1 — Run the exploration
Preferred — Workflow orchestration. If the Workflow tool is
available in this session (this skill invocation is your authorization):
Workflow({
scriptPath: "${CLAUDE_PLUGIN_ROOT}/workflows/explore-branches-scan.js",
args: { scopedProblem: "<scoped problem statement>", branchCount: <default 3>, _contractVersion: "compass-contract-v1" }
})
It runs a Propose phase — branchCount branch-proposer agents in
parallel, each assigned a distinct angle (conservative/incremental,
ambitious/reimagine, resource-minimal/pragmatic, and further named angles
beyond 3) so the branches are forced apart rather than converging on the
same safe middle ground — then a Score phase — one branch-proposer
agent per branch (a separate dispatch from the one that proposed it) scores
Feasibility, Impact, and Risk 1-10 each and names the branch's biggest
blocker. Selection then runs deterministically in the workflow script
itself: highest total (the three raw dimension scores summed, Risk not
inverted, matching the source template's own Total row), ties broken by
lower risk — mirroring stage-map-scan.js's pattern of doing the actual
decision in plain JS after the agent-driven phases hand off structured data,
never asking an agent to also pick the winner. The proposer/scorer agents
are read-only by design.
Fallback (no Workflow tool) — spawn branchCount branch-proposer
subagents directly in parallel via the Agent tool, one per angle (see
workflows/explore-branches-scan.js's ANGLE_POOL for the exact angle
briefs if reconstructing them), each producing one {name, description}
branch. Then dispatch one more subagent per branch (or score them yourself)
using the identical Feasibility/Impact/Risk/blocker rubric. Compute each
branch's total yourself (sum of the three raw scores) and select the
highest, breaking ties by lower risk — the same deterministic rule the
workflow script applies, done by hand instead of in JS.
Step 2 — Present branches, selection, and rationale
Present, in this order:
- Branches — each branch's name and description.
- Scores — a table: branch, Feasibility, Impact, Risk, Total, biggest
blocker.
- Selected branch and the rationale (why it beat the alternatives,
including the tie-break note if one applied).
If continuing within compass-solve's pipeline (its Explore stage), hand
the selected branch's description to compass-decompose-chain as that
skill's input contract for its Decompose stage. If running standalone,
suggest compass-decompose-chain as the natural next step for turning the
selected branch into concrete, verifiable stages.
Optional — render an interactive trace
compass has no output_dir/settings file, so this is opt-in
visualization, not a required report — offer it, don't gate on it. After
presenting Step 2, optionally render the workflow's result (the object
returned in Step 1: {branches, selected, rationale, ...}) as an
interactive branch diagram via
${CLAUDE_PLUGIN_ROOT}/assets/reasoning-trace-viewer.html, using the same
injection approach self-assess-stage-map uses for topology-viewer.html
(JSON-safe-escape </>/& before injecting into the <script> block —
do not reimplement that escaping ad hoc):
python3 "${CLAUDE_PLUGIN_ROOT}/references/render_trace.py" \
"${CLAUDE_PLUGIN_ROOT}/assets/reasoning-trace-viewer.html" <output-path> <<'JSON'
<the workflow's actual JSON result, verbatim>
JSON
Pick a reasonable <output-path> (a scratch/tmp file, or a path the user
suggests). If it renders, tell the user they can view the reasoning trace
interactively at that path — never present this as a required step.
