imozuru is a Claude Code skill that digs down to primary sources instead of summarizing

A skill that deliberately does not summarize

The project description is a single sentence in Japanese, and it is worth translating precisely because the whole design follows from it. imozuru is a Claude Code skill that digs through an unfamiliar field, potato by potato, until it reaches the original text.

The README explains the difference from an ordinary request. If you ask a language model to research something without a skill, it reads the top few search results and returns a summary. The summary is quick to read, and it has the weakness that the details needed for a judgement are easily lost.

There is a second problem, and it is the one the skill is actually built around. While you do not know the terminology of a field, you cannot choose the right search terms, so the search cannot move beyond the range of the words that occurred to you first.

So the skill starts by establishing the map of the field, the vocabulary, the people at its centre and the places where knowledge gathers, and then follows citations, links and authors to collect the original documents. The collected sources are saved without being summarized, and for each claim the skill only points at which file and which line it comes from. Reading the originals and drawing the conclusion is left to the user.

That refusal to summarize is the defining constraint, and it is grounded in research rather than taste. The design notes cite Kuhlthau from 1991, who argued that summarising in detail at the confused early stage of a search leads to premature closure and obstructs the search process. So imozuru stops at pointing at the place in the original text.

The licence is MIT, the primary language is Python, the repository is not archived, and the last push was on 2026-10-20.

The map, the sources, the log and the extract

The output is a directory, and the README lists exactly what goes into it. The results are saved under a research folder named after the topic, and the contents are a map file, a log file, a sources directory, an extracts file and a report page.

The map is the working document. It holds the question, the claims that need answering, the terminology, the people, the places, a table of the original sources and the next lead to follow. The log records, week by week, what was searched for, what came back, and the judgement made with its reason.

The sources directory holds the collected originals. The README describes the filtering rule: pages that return a 404 or that ask for a login are opened and removed rather than saved, so the directory does not fill up with unreachable links.

The extracts file holds the quotations, and the report page renders them grouped by claim. The README calls this the extract page, and it is the artifact the user is meant to read.

The important verification detail is in the last section of the design notes. The `report.py` script checks that each extracted sentence is present, unchanged, at the specified lines of the source, and if even a single word differs it will not build the page. So the report is not a summary that might have drifted from the document, it is a set of quotations that the script has confirmed against the file on disk.

The mechanism is borrowed from Ellis's model, where extracting is one of the stages of searching behaviour, and the README says the point of extraction is that saving dozens of originals still leaves you with no idea where to start reading.

A sample of the finished page is in the demo directory of the repository, and the scripts alone can be tried against it.

Two searchers with different hypotheses

The method starts with the question. Claude first writes out the question and the three to six claims that the answer has to contain, so the work is framed as a list of things to support rather than a topic to summarise.

Then two search subagents run, deliberately using different search strategies, and they collect the terminology, the people and the places, which are written into the map file.

From there the search follows references, citations and authors until an original source is reached. In fields with no papers, the skill follows the links inside articles and the phrasing that says an article was inspired by someone else's work, which is the trail available when formal literature does not exist.

The two-agent design has a stated reason. The README cites research on HypoSearch, which reports that AI search tends to fail when, at a stage where several directions are possible, it picks one and then keeps following that path in later searches. So when the model is unsure, the skill puts two searchers with different hypotheses side by side and compares their results before continuing.

That is a hypothesis-testing arrangement rather than a redundancy one. Two agents searching the same way would mostly find the same documents, and the comparison that matters is the difference between them, which is where a second direction can appear.

The stopping rule uses the same two agents. The search stops when every claim has a source location attached, or when nothing new turns up any more.

The result of the search is not a text but a set of documents with a table of where they came from, and the read and the judgement stay with the user.

Two stopping rules, one borrowed and one provisional

The stopping conditions are the most interesting part of the design, because they are where a research tool usually gives up and makes something up.

The first rule is that every claim has a source location. The README says this follows the HALT idea of Roh and Han from 2026, which decides when to stop based on whether the evidence is complete. The implementation adds two constraints so that the claims cannot become vacuous. At least one of them has to contain the wording of the request as it was given, and more than half of them have to be shaped so that they cannot be answered without reading the original text.

That second constraint is the one that matters in practice. A claim like the field uses several different methods is answerable from any summary. A claim that has to quote a specific passage is not, which is what stops the tool from satisfying itself with plausible generalities.

The second rule is saturation. The search stops when seven out of ten of the documents the two searchers produce are already in the map. The README says this borrows the idea of estimating the whole from the overlap between two independent searches from Kastner in 2007, and it is explicit that the seven tenths figure is a provisional guide settled by trying it out.

That honesty is worth noting. A rule presented as a heuristic is easier to argue with than one presented as a constant, and a researcher who disagrees with the threshold can change it.

The sources for the rules themselves are collected in a theory file inside the skill, and the README says that file records which paper each rule came from and where in it.

Marking the kind of source when there are no papers

The skill covers fields where the knowledge does not live in journals, and it needs a way to say what kind of document it has found.

The design notes give five markers. The first marks a peer reviewed or conference paper, including preprints on arXiv. The second marks a first person record, meaning the account of the person who did the thing themselves, describing the process of trying, building or measuring it. The third marks an observation, where somebody wrote up the features of another person's work or method. The fourth marks a summary, an article that collects or restates other people's knowledge. The fifth marks an official document, the documentation from whoever made the tool or product.

Each saved source is tagged with these, and the README is explicit that the choice of what to believe is left to the user.

This is a small design decision with a large effect on the output's usefulness. A field like mixing paint or DJ mixing has almost no papers, and its knowledge sits in personal blogs and videos. Without the markers, a blog post and a peer reviewed result would be indistinguishable in the report. With them, the reader can see at a glance that a claim rests on somebody's own account, and decide accordingly.

The five categories also make the extraction report readable, since the page groups quotations by claim and each quotation carries the kind of source it came from.

Installing it as a plugin or as a skill

There are two installation routes, and the README gives both in a handful of commands.

The first treats the repository as a Claude Code plugin marketplace and installs the plugin from it.

/plugin marketplace add MaryCache/imozuru
/plugin install imozuru@imozuru

The versioning behaviour here is unusual and worth understanding. The README says the plugin carries no version number, so every commit to the main branch is treated as a new version. To keep it up to date automatically you enable the automatic update for imozuru in the marketplace screen, and to update it by hand you run `claude plugin marketplace update imozuru`.

The second route uses the skills command line tool, and the README links the tool's repository for that.

npx skills add MaryCache/imozuru

For a manual install, the README says to copy the skill directory into your own skills directory, placing `skills/imozuru/` under `~/.claude/skills/imozuru/`.

The plugin route is the one to prefer if you want the updates, and the trade is that an unversioned plugin means a change to the main branch changes your behaviour without a version marker to track. That is a reasonable trade for a research helper whose output you read yourself, and a different one for a tool whose output you act on without reading.

Using it is then a request in a session, and the README shows prompts of the form of asking for a potato-style dig into a topic, and a watch command that takes a keyword.

/imozuru watch react

The watch mode is the other half of the skill. The README describes it as a lookout mode where the places found while digging, such as Qiita and Zenn tags, notes, YouTube, blogs and arXiv, are collected over RSS and lined up.

Standard library Python with four optional extractors

The dependency story is unusually light, and the README is precise about what is missing when.

The scripts run on Python 3.10 or above using only the standard library, and the commands in the table are used if they happen to be installed. `pdftotext` from poppler or Xpdf extracts the body text from a PDF, and without it a PDF fails. `pdftoppm` together with `tesseract` runs OCR over an old PDF that has no text layer, and without it that PDF fails. `yt-dlp` fetches subtitles for video, and without it a video fails. And `ax` converts HTML into markdown, where the fallback is the standard library extracting plain text only, and the README notes that headings and table structure survive better with `ax`.

The failure behaviour is the important part. A missing extractor does not produce an empty document and a confident answer, it produces a failure for that source, which is the correct outcome for a tool whose whole value is that the quotes are real.

There is one network dependency that needs no credentials. The `chain.py` script, which follows the citation chain, uses the OpenAlex API, and the README states that no API key is required.

The three caveats at the end of the README are the ones to read before using it. The search agents search the web, so the content of the question is sent out as search terms, and the README says not to use it for research involving confidential information or personal data. The skill does not use methods to obtain paywalled papers, and reports what it could not reach as not delivered. And the saved originals are copies for your own reading, so they should not be redistributed.

The licence is MIT, and the repository carries a `tests/` directory alongside the `skills/` and `examples/` directories and a plugin manifest.

Editorial conclusion

imozuru fits a researcher or a technical writer who has to justify a claim with a source rather than a summary, and who is willing to read the collected documents themselves. Skip it if you wanted a quick answer with citations, since the skill deliberately withholds the summary, or if your question contains details that must not reach a search engine. Verify first that the optional command line tools you need are installed, because a missing extractor makes the relevant document fail rather than degrade, and check the theory file that maps each rule to the research it comes from.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MaryCache/imozuru on GitHub
4. README