cc-tree

Language: English (canonical). Chinese: README.zh.md.

cc-tree is a Claude Code plugin that turns open-ended thinking into a tree you can audit. One universal radial-tree exploration engine, four swappable presets: divergent brainstorming, adversarial critique, design-space exploration, and code audit — same engine, different vocabulary. It is a disciplined, disk-persisted take on tree-of-thoughts search: every node is derived in full with file:line or URL evidence, defer / future-work / TODO / NEEDS-MORE-INFO leaves are hard-banned, and the run stops on substantive convergence rather than on a node budget.

claude plugin marketplace add skymanbp/cc-tree
claude plugin install cc-tree@cc-tree

Refactor of sci-paper's brainstorm + paper-attack-tree skills, stripped of paper-specific anchors and parameterized via presets.

1 · The problem, and what cc-tree does about it

1.1 The problem it targets

Ask any LLM to brainstorm, review this critically, compare these designs, or audit this file, and the same five failure modes come back every time. They are not model bugs; they are the lazy equilibria of free-form generation.

The target effect is the inverse of every row: fixed-breadth coverage, no deferrals, deduplicated branches, a convergence test you can check, and every claim carrying a file:line or a URL.

1.2 What it does — five capabilities

All five are the same engine. A preset changes the vocabulary, never the loop — §10 of docs/ENGINE.md is the exact extension surface.

1.3 Working scope — what cc-tree is not

• Not a one-shot brainstorm tool. The engine is recursive and convergence-terminated; a real run takes minutes to hours.
• Not a chat interface. Once invoked it runs to convergence without further prompting (§F6). You steer with flags on the next invocation.
• Not a substitute for a domain expert. It produces a cited, structured exploration; a human still decides which leaves to act on.
• Not bundled with a model. It is pure prompt engineering on top of your existing Claude Code model setting.
• Not a linter. code-audit looks for what a static analyzer cannot: threat-model-dependent, contract-level, and cross-file reasoning bugs.

2 · How it works

2.1 The shape — one root, growing outward

cc-tree treats any open-ended thinking task as a phylogenetic tree growing outward from one root. The root is your input — a topic, a document, a code path, a design prompt. Every node is expanded by the same 12 framing passes, each child is fully derived and scored, and only the high-value (advances) leaves get re-expanded, until the tree reaches substantive convergence rather than an arbitrary count.

Inspired by the radial tree of life. The vocabulary the rest of this README uses is all in this one picture: root (the input at the centre — topic · artifact · code · design), node (one idea / critique / option / finding, each with the same 12-field derivation), depth (the concentric framing-recursion rings; branches stop at different rings because only advances leaves re-expand), width (the terminal leaves, wherever they land — set by convergence, not a hand-picked cap, and never counting a blocked tip until it is completed, per §0.1), and n (total nodes in the tree). Diagram source: tools/gen_radial_tree.py.

  the tree grows OUTWARD from one root. a branch can WIN, hit a DEAD END, or
  keep BRANCHING and be judged again — no single winner, wins at any depth:

    ROOT ──┬── pruned                      (dead end at depth 1)
           ├── advances                    (a win at depth 1)
           └── advances ──┬── pruned        (this branch keeps going…)
                          └── advances ──┬── advances   (…a deeper win)
                                         └── blocked

  each node → 12 framings (§3.A–§3.L) → 12-field derivation → score → verdict;
  branches that keep advancing grow deeper; pruned / blocked ones stop.

2.2 The five irreducible steps

All five are specified in docs/ENGINE.md and binding on every preset.

flowchart LR
    R([root<br/>topic · artifact · code · design]) --> F{{12 framing passes<br/>§3.A–§3.L}}
    F --> D[per-node 12-field derivation<br/>evidence · no hedging · no defer]
    D --> S[score 5 dims → verdict]
    S -->|advances| RE((re-expand<br/>this leaf))
    RE --> F
    S -->|kept / pruned| K[keep in tree,<br/>don't re-expand]
    S -->|blocked| B[INCOMPLETE_FORBIDDEN<br/>drive to completion]
    B --> D
    S --> C{§6 convergence?<br/>6 conditions all true}
    C -->|no| RE
    C -->|yes| OUT[/final report +<br/>tree.md · tree.json/]

Step 1 — Ground the root (§2)

The preset supplies the recipe; the engine enforces that every root field carries a file:line, URL, or command-output citation. An optional glossary-grill prelude (§2.0) locks the root's technical noun-phrases to your project's term sheet before a single branch is generated, so the tree does not spend a hundred leaves solving the wrong problem.

Step 2 — Expand every node through 12 framings (§3)

Each node — root first, then every advances leaf — is put through all 12 framing passes, each of which must yield at least one child. The set is fixed so that the model cannot quietly skip the uncomfortable angles.

A thirteenth pass, §3.X, runs one external cross-check per node (WebSearch then WebFetch of the actual page) unless --no-online is set. Full prompts and per-preset examples: docs/framings.md.

Step 3 — Derive every child in 12 fields (§4)

Each child is filled into the preset's 12-field node schema —