Building ResearchComb to Keep Claims Tied to Sources

A working link identifies a source. It does not establish whether that source supports the claim sitting next to it. I built ResearchComb so a research task inside an AI chat can carry that distinction all the way through search, drafting, critique, and citation checks.

The problem I kept hitting

When discovery, comparison, drafting, and review happen in separate steps, context falls off the table. That is worse in a chat with an AI assistant, because the model can produce a fluent paragraph with a DOI attached and still be wrong about what the paper actually says.

I wrote about this when I shared ResearchComb on LinkedIn: the toolkit is meant to run directly inside Codex or Antigravity, using the host’s existing tools. There is no ResearchComb server, separate app, or API key. The goal is to make research easier to inspect—connect claims to sources, record access limitations, and flag unsupported conclusions.

The current public bundle is v0.5.23, MIT licensed. You can read the case study or the repository. This note is the longer version of why the pieces are shaped the way they are.

The core ideaKeep bibliographic identity, link access, and claim support as separate records, and reuse source and claim IDs across every stage of the task.

How the workflows fit together

Codex and Antigravity already browse, read files, and run commands. ResearchComb adds portable skill folders they can load: a general researchcomb router, twelve focused research workflows, and a separate comb-update command that checks GitHub only when asked.

The focused workflows cover surveys, investigations, source summaries, comparisons, paper-to-code audits, implementation plans, manuscripts, critiques, citation checks, experiment loops, reproductions, and a one-request topic-to-paper path called comb-paper. I do not ask the model to invent a pipeline each time. I ask it to load the skill that already names the stages.

comb-paper is the long path in one request: find and assess sources, read and compare evidence, draft to a requested length, then critique and verify. It keeps one shared evidence record throughout. For open-ended live research it attempts the scholarly sources in the shared guide and follows citation trails; five papers is only the discovery floor. It skips live search when you supply a closed corpus. Experiments need authorization. If the evidence is not enough, the draft is labelled partial.

Claims in the record can be supported, qualified, contradicted, unsupported, or unverified. A substantial task can save evidence.json; a narrow lookup can stay as a compact table in context. That is the same separation the case study starts from: identity is not support.

A citation check is the smallest version of the idea

The repository includes a recorded citation fixture. A draft uses a real DOI to claim that FeNi and NiPt are equally selective for producing propylene. In that test, comb-check finds the DOI belongs to Gomez et al. (2018) while the draft names another paper’s author and year, and that under the studied conditions FeNi favors propylene while NiPt favors dry reforming. A resolving DOI identified a source; checking the source decided the claim.

That fixture is a regression outcome, not a promise that every live paper will be fully readable. Several publisher pages in the recorded runs were inaccessible and stayed labelled as abstract or excerpt evidence.

Install it in Codex or Antigravity

The README’s current install prompt pins version v0.5.23 at commit c43d1dcaef4d930c463fe51ab31ae60a1999fc73. Paste this into Codex or Antigravity with GitHub and local file access:

Install ResearchComb version v0.5.23 at commit
c43d1dcaef4d930c463fe51ab31ae60a1999fc73 from
https://github.com/diaznakh/ResearchComb for my account.
Check out that exact commit before copying or installing.
Use your native plugin installer if it accepts this
GitHub repository; otherwise copy every complete skill
folder under skills/, including supporting files, into
your user skills directory. Confirm researchcomb and all
thirteen comb-* commands are available. Do not execute
repository code during installation.

The host may ask for its normal approval to fetch GitHub or write to its skills directory. A bare link may only open the repository; the instruction above is what requests installation.

If you prefer the Codex CLI, the same pin looks like this:

codex plugin marketplace add https://github.com/diaznakh/ResearchComb.git --ref c43d1dcaef4d930c463fe51ab31ae60a1999fc73
codex plugin add researchcomb@researchcomb

Start a new chat after installation. If plugins are unavailable in your Codex surface, the README says to ask $skill-installer to install every complete folder under skills/ from that commit.

For Antigravity, copy every complete folder under skills/ into ~/.gemini/config/skills/ for all workspaces, or into the workspace .agents/skills/ directory for one project. Check Customizations → Installed → Skills & Rules for researchcomb and the thirteen comb-* skills.

Then give it a task. In Codex, type $ and select a skill. In Antigravity, use a /comb-* slash command. Plain-language requests such as “Use comb-check to…” work in either host:

Use comb-paper to draft a 3,000–3,500-word sourced
literature review on when retrieval-augmented generation
improves factual accuracy. Search and compare primary
studies, synthesize findings, check citations, and save
paper.md with evidence.json and checks.md for me to revise.

comb-update compares the installed version against the public repository when you ask. Research workflows do not add a GitHub lookup to each task. There are no GitHub Releases on the repo as of this writing; the version lives in plugin.json and skills/researchcomb/VERSION.

Design decisions I would not give up

The first was to stay inside the host. ResearchComb is an instruction-based skill bundle. It has no bundled server or API client and requires no ResearchComb account. Your AI host’s normal access and usage limits still apply. That constraint forced the interesting work into records and checks instead of a private backend.

The second was to keep the projects as folders the host can copy. Each workflow is a skill with supporting files. Source and claim IDs are meant to survive a handoff from survey to manuscript to critique. If those IDs reset every stage, the evidence record is just another generated file.

The third was to put completion checks next to the prose, not in place of judgment. For open-ended live searches and manuscripts with a requested word range, the skills tell the host to run a local completion checker. It flags missing broad-source attempts, too few distinct papers, empty or duplicate records, and drafts outside the requested length. A local safe fetcher can check DNS addresses and redirects before retrieving links. Both scripts use Python’s standard library. The checker cannot prove that a browser call happened or that a citation supports a claim. For those judgments you still inspect the host tool log and run comb-check.

Live-search tests made that limit concrete. Instruction-only skills cannot enforce tool calls or stop a host from misreporting them. When complete coverage matters, the tool history is part of the evidence.

What the recorded runs actually cover

I am not going to treat passing tests as a user count or a quality guarantee. The public case study and README record native Codex runs on 8–9 October 2026. Earlier focused workflow cases passed 11 / 11. The one-request comb-paper case produced 567 measured body words inside a requested 400–600 range, preserved source IDs, and used two supplied synthetic excerpts—it did not browse or run experiments. An earlier long manuscript case produced 6,201 measured body words. An experiment kept an improvement and rejected a regression within its two-trial budget. A reproduction case correctly reported a mismatched claimed result as not reproduced.

Eight research cases use synthetic fixtures. Antigravity skill installation was checked; its behavioral tests remain unverified. Passing tests do not guarantee research accuracy.

What I am not promising next

The repository does not publish a roadmap. The remaining limits are already documented: inaccessible sources stay recorded, experiments need an authorized local environment, recurring monitoring needs the host’s scheduler, and ResearchComb does not provision cloud compute. Outputs can still be wrong. Check sources, citations, calculations, code, and conclusions before relying on them.

If you try it, I welcome feedback, issues, and contributions on the GitHub repository—the same invitation I put on the launch post.

This note expands the LinkedIn launch post and the ResearchComb case study. The install commands and workflow names are from the v0.5.23 README.

Read the LinkedIn launch post ↗