# deep-research writes chapters in parallel with no tool calls, so every fact must arrive in the prompt > A skill that takes a topic and returns a report of several hundred lines with tables, citations, and counter-arguments, in whichever of nineteen languages the topic is written in. The pipeline is four stages and the third one is the interesting constraint: chapters are written simultaneously, facts are pasted straight into the prompt, and the writer is not allowed to search. Everything the report asserts was gathered before the writing began. **hoolulu/deep-research** — Professional deep research report generation Skill — one command, ten minutes, broker-grade deep research / 深度调研报告生成 Skill — 一条命令，十分钟出券商级深度调研报告 - Repository: https://github.com/hoolulu/deep-research - Website: https://www.h33.top - Stars: 587 · Forks: 59 - Language: Python - License: MIT - Published: 2026-09-17 · Updated: 2026-09-17 · Language: en - Canonical page: https://hysenlabs.com/projects/hoolulu-deep-research ## One command, and a headline time that is the optimistic end The pitch is a single slash command taking a topic, with the report landing in about ten minutes and no manual intervention. The detailed table underneath gives the real range, and it is worth reading before you plan around the headline. Quick mode is quoted at roughly eight to twelve minutes and standard at ten to fifteen, with total time for a standard run between ten and twenty. Data collection is one to three minutes of that, so the writing dominates. The output shape is also fixed and quantified: five hundred to seven hundred lines, fifteen to twenty-five data tables, eighty to a hundred and twenty analysis paragraphs, fifteen to twenty-five distinct sources, and three to eight opposing viewpoints with at least one controversy per chapter. Each analysis paragraph is specified as conclusion, data, causation, and judgement in that order, which is a template you can check a report against. ## The writer gets no tools, so every fact is pasted in ahead of time This is the constraint that shapes everything else. In the third stage, all chapters are written in parallel, and the parenthetical is explicit that this runs sequentially by itself when there is no multi-agent setup. More importantly, the facts are embedded directly in the prompts and the writing step makes no tool calls. So the writer cannot search, cannot fetch, and cannot check anything. Whatever ends up in the report had to be collected in stage two and injected into the prompt. That is a deliberate trade: it makes parallel writing cheap and predictable, since no chapter can block on a network call, and it makes the citation story tractable, since the model is not inventing sources it half-remembered. The cost is that anything the collector missed is unrecoverable at write time, and a chapter that needs one more number cannot go and get it. ## Four search layers issued in parallel is a merge order, not a priority The search stage is described as a four-layer priority strategy with all layers issued in parallel, which is a slightly odd combination and tells you how it actually behaves. Layer zero is whatever search engine the tool already has, detected at runtime, with two example names given. Layer one is sources the outline itself suggests, so a topic about arctic shipping produces a recommendation for a specific council. Layer two draws from a bundled source list, and a fourth fallback exists for when nothing else returns anything. Because every layer fires at once, priority cannot mean sequencing, which means the upper layers do not actually prevent traffic to the lower ones. They define the order results are merged in. That is a sensible way to get breadth cheaply, and it also means the query volume against the free fallback is not bounded by how good the first layer was. ## Stage four is a fixed chain of post-processing passes The last stage is listed as a sequence rather than a description: batch validation, then assembling the report, then converting citations, then a currency-escaping pass. Each name implies a specific failure being handled. Batch validation is what catches a chapter that is missing a required element before it reaches the reader. Citation conversion is what turns whatever the search layer returned into a consistent reference form. Currency escaping is the least obvious of the three and suggests that the report is emitted somewhere that treats currency symbols as markup, which is exactly the kind of bug that only shows up in a long document with many tables. The stage list is truncated in the README, so there are further passes after that one. The order is sensible, since validating before assembling avoids rewriting a finished document. ## The repository is a skill, a tool server, and a static site at once The top level is unusually busy for something described as one command. There is a skill manifest, and beside it a rules file and a types file, so the instructions and their schema are separated rather than merged. There is a version file, a profiles file for per-platform settings, and a bundled sources list that the second search layer reads. There is a prompts directory, a command directory, and a tools directory. And there are two things that are not documentation at all: a Python script at the root that serves as an MCP server wrapping the fetching library, and a directory holding a static report browser. So the project is a skill, an MCP server, and a small web application in one repository. That is why the sixth major release was about being platform-agnostic: the profiles file is what lets one skill behave differently per client. ## Reports are browsable and exportable without a server The output side is treated as a product rather than a file. After each run, a local browser page is written and refreshed, with search, filtering, sorting, and a preview. From that preview you can export to PDF or to a word-processor format, and both exports are described as happening entirely client-side with no server required. That is a real constraint on the output format: the export is done by code running in the page, which means it inherits the browser's font set and its page model rather than a typesetting engine's. For a report that is meant to look institutional, that is the difference between a document and a web page that prints. The offline path is the same: local files in several formats are parsed directly into the data pool, and the README notes that no internet connection is needed for that route. ## Twenty languages by detection, which is not the same as twenty corpora The language story has two halves and only one of them is a feature. Detection is automatic: the skill works out the language of your topic and writes the report in the same language, and the README makes the stronger claim that it searches for material in that target language rather than translating a result set. That is the part that matters for anything outside English, because a pipeline that searches in English and translates will miss local-language sources entirely. The table of commands demonstrates the range across Chinese, English, Russian, Japanese, and Korean. What is not demonstrated is coverage. Nothing in the repository says which language-specific sources exist beyond the bundled list, and a bundled list is the layer you reach only when the earlier ones return nothing, so a language with a thin bundled list degrades quietly toward whatever the tool's built-in engine returns. ## The cost table is your own model, priced from one vendor's list The cost section is honest about what it is and what it is not. Three of the four rows are zero: fetching runs locally, domestic sources connect directly with no proxy, and the runtime is the MIT-licensed tool you already have. All of the money is in the model row, where a specific model is used as the baseline with per-tier token estimates and a cost under three cents for quick mode, under six for standard, and under ten for deep. The footnote gives the price list the arithmetic comes from, with a link to the vendor's pricing page, and notes that actual cost varies with cache hit rate and topic complexity. Two things to keep in mind. The estimate is anchored to one vendor's rates on one day, so a different model changes the number substantially. And the deep tier's several hundred thousand tokens is the figure to test first, since everything else in the table is free. ## Conclusion Use it for landscape-style questions where structure matters more than novelty, since the report shape is fixed, conclusions first, with sources and opposing views. Two numbers to check against your own expectations. The headline says ten minutes and the table says ten to twenty for standard mode, so plan for the longer figure. And the token cost is substantial, in the hundreds of thousands for a single report, so the cheap part is the fetching and the expensive part is the model you already pay for. ## FAQ ### What is deep-research in this repository? An MIT-licensed agent skill that takes a topic and produces a long research report, with conclusions first, traceable sources, counter-arguments, and scenario forecasting, in whichever of 19 languages the topic is written in. It runs on a four-stage pipeline and works with any AI coding tool rather than one client. ### How long does a deep-research report take? The headline claim is about ten minutes. The detailed figures give quick mode at roughly eight to twelve minutes and standard at ten to fifteen, with a total of about ten to twenty minutes for a standard run, of which data collection is one to three. The README notes that actual times vary with topic complexity and data availability. ### How much does a deep-research run cost? Only the language model costs anything. Fetching runs locally, domestic sources are fetched directly with no proxy, and the runtime is free and open source. Against a specific flash-tier model as baseline, quick mode is quoted at under three cents, standard under six, and deep under ten, with the estimate derived from that vendor's published input and output rates and varying with cache hit rate. ### Can deep-research work on local files without internet access? Yes. The offline branch of the collection stage reads local files directly, in PDF, word-processor, plain text, and markdown formats, and parses them into the same data pool the online branch fills. The README points to its FAQ rather than documenting the prompts for this mode. ### How does deep-research search for sources? With a four-layer strategy issued in parallel: the tool's own built-in search engine detected at runtime, sources the outline itself recommends for the topic, a bundled source list, and a free fallback. Results are merged by layer, and the layers are described as priorities even though all of them fire at once, so the upper layers do not bound traffic to the lower ones. ## Sources - [hoolulu/deep-research on GitHub](https://github.com/hoolulu/deep-research) - [License: MIT](https://github.com/hoolulu/deep-research/blob/main/LICENSE) - [Project website](https://www.h33.top) - [README](https://github.com/hoolulu/deep-research/blob/main/README.md) - [Releases](https://github.com/hoolulu/deep-research/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hoolulu-deep-research