claude-deep-research-skill: an eight phase research pipeline inside Claude Code

The output is a filed report, not a chat reply

Most research prompts end in a paragraph or two inside a conversation window. This skill takes a different route: it finishes by writing a report directory to disk. Reports land in `~/Documents/[Topic]_Research_[Date]/` and come in three shapes, a Markdown file that the documentation calls the primary source of truth, an HTML rendering in a McKinsey style that is opened in the browser automatically, and a PDF produced through WeasyPrint for print. That is the actual product. A reader is meant to open a file, not scroll back through a transcript. The Markdown is listed as the source of truth, which means the HTML and PDF are derived artifacts and the order of authorship runs in the opposite direction from what most publishing pipelines assume. The intended user is someone who has to hand the output to a colleague, an editor, or a decision forum, where a bare answer with a handful of links would not survive scrutiny. The value proposition is traceability rather than speed, and the documentation is explicit that a report is expected to carry an executive summary of 200 to 400 words, findings of 600 to 2,000 words each, and a full bibliography with URLs and no placeholders.

Mode choice sets both the phase count and the wall clock time

Four modes are defined, and the table makes the trade-off between speed and depth explicit rather than leaving it to a single slider. Quick runs 3 phases and finishes in 2 to 5 minutes, aimed at initial exploration. Standard runs 6 phases in 5 to 10 minutes and is described as the right choice for most research questions. Deep runs the full 8 phases in 10 to 20 minutes for complex topics and critical decisions. UltraDeep lists 8+ phases across 20 to 45 minutes, aimed at comprehensive reports with maximum rigor. The gap between Deep and UltraDeep is therefore not phase count but what happens inside the phases, and the README attributes the difference to the multi-persona red teaming that the documentation says applies to Deep and UltraDeep. Since the phases are fixed, the modes are the only knob a user has for trading time against coverage. A team that has committed to a weekly research memo can budget against the 5 to 10 minute band of Standard, while a document that will be read by legal or a board needs the 20 to 45 minute band before a human opens it.

Phase 6 can send work back to Phase 3

The pipeline is written as a single chain: Scope, Plan, Retrieve, Triangulate, Outline Refinement, Synthesize, Critique, Refine, Package. The interesting part is the arrow between Synthesize and Critique. The documentation describes a critique loop-back in which Phase 6 can return to Phase 3 with delta-queries when critical gaps are found in the draft. In practice this means the retrieval stage is not a single pass that happens before writing begins. A report that fails its own critique is sent back for targeted additional searching rather than patched with prose. Two other mechanisms sit alongside it. Step 0 retrieves the current date before any searching, which the documentation frames as a way to prevent stale training-data year assumptions from leaking into the question being asked. Retrieval itself is described as 5 to 10 concurrent searches plus 2 to 3 focused sub-agents that return structured evidence objects, and a "First Finish Search" rule applies adaptive quality thresholds by mode, so the stopping condition for collecting sources differs between Quick and UltraDeep. Whether that adaptive threshold behaves as intended is the sort of thing you only learn by running a mode and inspecting the evidence objects.

Cloning into the skills directory, then wiring a search provider

Installation is a single clone into the Claude Code skills directory, and the README states that no additional dependencies are required for basic usage. The optional part is search-cli, which aggregates Brave, Serper, Exa, Jina, and Firecrawl, and it is the primary search path in the documented tool priority table. The Python side needs nothing beyond the 3.9+ standard library; WeasyPrint is listed as optional and used only for the PDF output at Phase 8. The commands below are the ones the project publishes, in the order you would run them. After cloning, invoke the skill in Claude Code with a plain language request, and the documentation shows these two forms:

git clone https://github.com/199-biotechnologies/claude-deep-research-skill.git ~/.claude/skills/deep-research
brew tap 199-biotechnologies/tap && brew install search-cli
search config set keys.brave YOUR_KEY  # configure at least one provider

deep research on the current state of quantum computing

deep research in ultradeep mode: compare PostgreSQL vs Supabase for our stack

The fallback is WebSearch, which the tool table lists as a built-in fallback for when search-cli fails or is rate limited, and Exa MCP is listed as an optional semantic search addition. The skill should still run without search-cli, but you lose the primary path and the multi-provider aggregation.

sources.json is what survives a compacted context

The most concrete engineering decision in the repository is the one the documentation calls disk-persisted citations. Citations are written to a `sources.json` file rather than held only in the conversation, which the README says lets them survive context compaction and continuation agents. That matters because the skill can spawn recursive agents: reports longer than 18K words auto-continue through recursive agent spawning with context preservation. Once a run is longer than the window, anything held only in the prompt is a liability, and anything in a file is recoverable. The same idea shows up elsewhere in the design, with progressive file assembly appearing as a separate change in version 2.1, and in the reference directory, which splits the guidance into methodology, report assembly, quality gates, HTML generation, continuation, and WeasyPrint guidelines. The entry point stays small at roughly 100 lines, with the detail pushed into reference files. For auditing, the practical question is whether that sources file is written early enough to inspect and whether the final bibliography is generated from it, since the quality standards call for a full bibliography with URLs and no placeholders.

Two validators, nine checks, and a three cycle fix loop

Quality is enforced by code rather than by prose instruction. The repository ships `validate_report.py`, described as a 9-check structure validator, and `verify_citations.py`, described as a DOI, URL, and hallucination checker, alongside `source_evaluator.py` for source credibility scoring and `citation_manager.py` for citation tracking. The documented sequence is validate, fix, retry, with a maximum of 3 cycles. The standard the checks are aimed at is specific: 10 or more sources, at least 3 per major claim, prose-first findings where the README asks for at least 80 percent prose, and a complete bibliography. The citation verifier name implies an attempt to detect citations that do not resolve, but the README does not document the tolerance for a failing check, so a hard failure on a single bad URL is a plausible reading and an unverified one. The scripts are plain Python in the `scripts/` directory, and the repository also carries `tests/fixtures/` with test report fixtures, so a reviewer can look at sample output without spending a search-provider budget.

The cost of running it, and what the repository does not say

Three limitations deserve attention. First, the retrieval half depends on external services. The search priority table puts search-cli first, with WebSearch as fallback, and the README asks you to configure at least one provider key. A deep run is billed against that provider and burns a wall clock of 10 to 45 minutes depending on mode. Second, the licence status is not clean. The README's licence section states MIT and invites modification, and `requirements.txt` labels the project as the standard library only, but the license field in the repository metadata is unknown, so treat the MIT line as an assertion in the README rather than a verified licence file. Third, the maintenance signal is thin. The last push was on 2026-04-11, more than six months before the current date, and the repository has no GitHub releases, so the version table in the README is the only upgrade record available. The last listed version is 2.3.1 dated 2026-03-19, which brought template and validator harmonization, structured evidence, critique loop-back, and multi-persona red teaming. Upgrading is a git pull of a skill directory, but the project publishes no release notes, so the changelog in the README is what you have to read.

Editorial conclusion

Adopt this skill if your work produces written research that someone else will have to defend, and if you can supply at least one search provider key. Do not adopt it for quick lookups, for topics where the web has little primary material, or if your team needs a documented licence, because the repository metadata does not record one and the README only asserts MIT. Before the first real run, check that search-cli returns results under your key, that the chosen mode matches the time you are willing to spend, and that sources.json lands in the report directory where you can audit it.

Frequently asked questions

Official sources

1. 199-biotechnologies/claude-deep-research-skill on GitHub
2. Issues
3. README