Deepdive: a 13-phase research pipeline as a Claude Code skill

The problem Deepdive is aimed at: research that evaporates after the chat closes

A one-shot prompt produces a wall of text with sources scattered through the conversation. Come back a month later and the links are dead, the reasoning is gone, and you cannot tell which claim came from which page. Deepdive is built for that specific failure. The README frames the contrast directly: without the skill, sources are lost in chat history and there is no way to detect bias; with it, each source becomes a file holding verbatim quotes, and every claim resolves through a bracketed link such as [s12] to a specific quote. The intended reader is someone making a decision they will have to defend later, not someone who wants a summary now. The README's own worked example is a trade-off investigation between Postgres logical replication and CDC tooling, ending in a dated report path and a logged decision. That shape (comparison, then a choice, then a record of the choice) is the target use case. A quick factual lookup is not.

Thirteen phases with a model assigned to each one

The pipeline runs thirteen phases in order, and each is bound to a model and a reasoning level. Opus with high reasoning handles reframing (phase 1), synthesis plus multi-angle red team (phase 6), and the decision walkthrough (phase 8). Sonnet with medium reasoning handles genre and block selection (2), the plan (3), search (4), and refresh targets (7). Sonnet at low reasoning covers capability discovery (3.5), the plan-review gate (3.7), the evidence filter (5.5), and wiki reconcile (5.7). Haiku at low reasoning runs the claims-ledger and triangulation step (5) and verification (6.5). The README states that the skill announces this routing and an estimated cost up front, once. That routing table is the design argument: reasoning-heavy steps get the expensive model, the parallel fan-out and mechanical checks get the cheap one. It also means the pipeline's cost profile is not uniform. Running phase 6 on Opus is where the money goes, and the README does not publish a token figure for it, so the cost estimate the skill prints is the only number you will have before committing.

The plan-review gate is the one step worth stopping for

Phase 3.7 shows you the reframing, hypotheses, genre and channels before any search fires, and lets you approve or edit them. Strictness scales with mode: deep waits for an explicit go-ahead, medium is a soft check, shallow skips the gate entirely. This is the clearest judgement in the project. A wrong plan executed perfectly still produces a wrong report, and the gate is the only point in the pipeline where a human correction is cheap. Note what happens if you run in shallow mode: you lose the gate, and with it the main structural advantage over an ad-hoc prompt. The README also describes a router in phase 1 that classifies the question profile (factual, multi-step, relational, comparative, landscape) and picks the decomposition method from that classification. Factual questions get flat independent subquestions, multi-step questions get least-to-most leveling, comparative questions get a shared axis matrix with mandatory opposition queries per candidate. The stated reason is that defaulting everything to flat parallel decomposition is a silent failure mode. That is a real distinction. Whether the router classifies correctly on a borderline question is not something the material lets me confirm.

Search is a bounded loop, not a single pass

Phase 4 runs a loop with three safeguards. After each round a Haiku pass tags every subquestion met, partial or unmet with a one-line reason; that tag set is what the later Opus evaluation reads instead of re-deriving the gap, and it targets the next round's dispatch. A no-progress circuit breaker stops the loop after two consecutive rounds that add nothing new to the source pool, regardless of remaining budget, and the unresolved thread moves to Open Questions. Least-to-most decomposition handles layered questions of the form X given Y. The circuit breaker is the part I would single out. Most agentic research tools have no explicit stopping rule beyond a round count, and a two-round no-progress test is a defensible one. It also has a predictable cost: a question whose useful sources only appear in round three, after two thin rounds, gets cut off and filed as an open question. That is a deliberate trade of completeness for budget, and the README presents it as such.

Installation is a clone, and the skill is invoked in plain language

For Claude Code the README gives one command: git clone https://github.com/Socialpranker/deepdive.git ~/.claude/skills/deepdive. After that you type something like "Investigate X", "Validate this hypothesis", or the Russian-language trigger the README lists. For Claude Desktop the instructions are to clone the repository, then run zip -r ../deepdive.skill . -x ".*" -x "*.zip" and upload the bundle through Settings, Skills, Add Skill. For other LLMs the README says the methodology is portable: load SKILL.md plus references/*.md into the model's context, skip the sub-agent parts, and use separate chat sessions per subtopic. That last path is a real downgrade rather than an equivalent option, since the parallel sub-agent fan-out in phase 4 is where the channel coverage comes from. The README also mentions a QUICKSTART.md promising install to first result in roughly five minutes. I have not run any of this, so I cannot confirm the timing or that the clone path works on every shell.

Catalog scale versus what the pipeline actually verifies

The repository description advertises 105 blocks, 29 channels, 460+ stat sources, 47 APIs and 1072 verified endpoints, with a badge claiming weekly API auto-validation through a workflow file named catalog-sync.yml. The README's comparison table repeats the channel and stat-source figures. Treat these as catalog size, not as output quality. A large channel list means the search phase has more places to look; it says nothing about whether the sources returned are any good, and the material gives no accuracy figure for the catalog itself. The four-layer citation verification in phase 6.5 is the mechanism that matters for trust, and the README does not spell out what those four layers check. If you are evaluating this for high-stakes work, that is the first thing to read in the source rather than the badge count.

Where the pipeline is the wrong tool, and what to use instead

The obvious cost is latency. Thirteen phases, a plan gate that waits for your approval in deep mode, and a bounded search loop mean this is not a tool for a question you want answered in one turn. The second limit is structural: the parallel sub-agent search assumes a host that can spawn sub-agents. On Claude Desktop, or on Codex and Gemini via the manual context-loading path, you lose that fan-out and the pipeline degrades to a single-threaded prompt sequence with the same overhead. The third is the plan gate itself. If you skip it by running in shallow mode, the pipeline's main advantage over a careful prompt disappears while the phase count stays. The closest alternative named in the README is Gemini Deep Research, cited for calling plan review its biggest lever over output quality. The difference in approach is where the artifacts land. Deep Research returns a report in the chat product; Deepdive writes a folder (plan.md, sources/, findings/FN.md, research/<topic>/<date>_decision.md) that you can reopen. If your work stays inside a chat window and you never revisit it, the folder buys you nothing and the phase overhead is pure cost.

Licence, maintenance and what to check before you commit

The project is MIT licensed, which permits commercial use and modification provided the copyright notice and permission notice are retained. That is the standard reading of MIT and not legal advice; check the LICENSE file in your checkout. On maintenance, the material shows a last push in September 2026, no tagged releases retrieved, and a GitHub Actions workflow (catalog-sync.yml) that the badge says validates APIs weekly. Without releases there is nothing to pin to, so an upgrade means pulling main and diffing. The README contains machine-generated markers (counts for phases, channels and stat sources) that are regenerated from the repository, which means the README table and the actual phase files can drift apart between commits. Before adopting, read SKILL.md and the references/ directory and confirm the phase list there matches the thirteen rows in the README table, and confirm that the four-layer verification step is described in enough detail to audit.

Editorial conclusion

Adopt Deepdive if you need a durable, quote-level provenance trail for a decision you will revisit in a month, and you are willing to spend a few minutes editing plan.md at the phase 3.7 gate before any search fires. Do not adopt it if you want a fast answer or if you cannot run Claude Code with sub-agents, since the parallel fan-out is the part that carries the pipeline. Before installing, read SKILL.md and the references/ directory to confirm the phase list in your checkout matches the table in the README, because the README table is machine-generated and the repository has no tagged releases to pin against.

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. Socialpranker/deepdive on GitHub