# Claude Scholar: a semi-automated research assistant for Claude Code, Codex CLI and Kimi Code CLI > Galaxy-Dawn/claude-scholar is an MIT-licensed collection of skills, agents and commands that wraps a coding CLI into a literature-to-publication workflow. It is opinionated about evidence, file layout and which CLI you run it on. **Galaxy-Dawn/claude-scholar** — Semi-automated research assistant for academic research and software development. Supports Claude Code, Codex CLI, Kimi Code CLI, and OpenCode across ideation, coding, experiments, writing, and publication. - Repository: https://github.com/Galaxy-Dawn/claude-scholar - Stars: 5,635 · Forks: 442 - Language: Python - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/galaxy-dawn-claude-scholar ## The problem Claude Scholar targets: research work that never leaves the chat window Most AI-assisted research breaks down at the handoff. A model helps you summarise five papers in a session, then the session ends and the summaries are gone. The next task, writing a related-work section, starts from nothing. Claude Scholar is built around that gap. The README describes it as a semi-automated research assistant for academic research and software development, and names computer science and AI researchers as the intended audience. The scope it claims is wide on purpose: literature review, coding, experiments, reporting, writing, and project knowledge management. The word semi-automated is doing real work. The repository is a set of skills, agents, commands, rules and hooks that sit on top of a coding CLI you already use. It does not replace your judgement about which papers matter or whether a result is real. What it does is give those judgements a place to live on disk, so the next step in the pipeline can read them. That is the design bet, and it explains most of the other choices in the repository. ## Skills, agents and branches: how the pieces fit together The top-level layout is the architecture. There is a skills/ directory, an agents/ directory, a commands/ directory, plus hooks/, rules/, templates/, scripts/ and utils/. A settings.json.template at the root suggests configuration is copied into place rather than generated. The .claude-plugin/ directory indicates the project is packaged as a plugin for the Claude Code side. The most consequential detail is the branch model. The README states plainly that main is the Claude Code workflow, and that Codex CLI users should look at the codex branch, Kimi Code CLI users at the kimi branch, and OpenCode users at the opencode branch. These are not cosmetic forks. Each CLI has different conventions for how instructions and tools are exposed, so the same conceptual workflow is re-expressed per host. If you read the main branch README and then try to run it under Codex CLI, you are reading the wrong document. On the evidence side, the changelog for 2026-05-13 describes a shared research-contract.md covering Evidence Records, claim strength, and Claim Promotion Gates, and says research ideation, Zotero ingestion, literature synthesis, results reporting, writing and rebuttal were connected to that contract. It also states that project paper notes live under Sources/Papers before promoted claims move into Knowledge or Writing. That is a data flow, not a slogan: notes start in a staging area, and only claims that clear the gate get promoted. The 2026-04-24 entry describes a project-scoped Obsidian knowledge-base workflow, with OBSIDIAN_SETUP.md at the root for the setup path. The writing stack is named in the 2026-05-14 entry: nature-writing for section drafting and argument construction, nature-polishing for article patterns, nature-response and nature-data for journal work, plus expression-skill as a conclusion-first discipline for reporting and planning, and planning-with-files as the default on-disk planning layer. Figure and table production is routed through publication-chart-skill, which the changelog says wraps two separate Python packages, pubfig and pubtab. ## Installing Claude Scholar and running a first literature task The repository does not present a single install command in the README. What it gives you is a branch per CLI and a settings.json.template at the root, which implies you clone the branch matching your tool and configure it locally. Start by choosing the branch. If you use Claude Code, main is the right one; otherwise substitute codex, kimi or opencode. ```bash git clone -b main https://github.com/Galaxy-Dawn/claude-scholar.git cd claude-scholar ``` The clone above gets the Claude Code edition. The README's branch note is the authority here: the codex, kimi and opencode branches are separate editions, so the -b value is not interchangeable. Next, look at the template before copying it. It is the file the project ships for local configuration, and the README does not document an interactive setup wizard. ```bash cp settings.json.template settings.json ``` After that, the two optional integrations have their own root-level documents. MCP_SETUP.md covers the MCP server setup, and OBSIDIAN_SETUP.md covers the project-scoped Obsidian vault workflow. Both are also available in Japanese and Simplified Chinese variants. Read the one matching your language before wiring anything up. For a first real use, the changelog points at the daily-paper-generator workflow, which the 2026-04-22 entry says was generalised to broader topics with arXiv and bioRxiv support and a fixed Top 10 to Top 3 to Top 1 selection flow. That is a concrete first task: point it at a topic, let it narrow a candidate list, and see whether the surviving paper is one you would actually have picked. If the Top 1 selection is consistently wrong for your field, the rest of the pipeline will inherit that error. ## Where the design creates friction The branch-per-CLI model is the biggest constraint. If your group has people on Claude Code and people on Codex CLI, they are not sharing a checkout. Skills, commands and rules live on different branches, so a fix or a new skill has to be ported. The README does not describe a merge or sync process between branches, and it does not document rollback. That silence matters if you plan to run this across a lab rather than on one laptop. The evidence contract is a second source of friction, but a deliberate one. A Claim Promotion Gate that moves notes from Sources/Papers into Knowledge or Writing implies that something can fail the gate. The changelog does not say what happens to a claim that does not clear it, and the README does not document the gate's criteria beyond the phrase claim strength. In practice you should expect to read research-contract.md directly rather than infer the rules from behaviour. There is also a scope boundary worth naming. The 2026-04-15 entry introduces pubfig and pubtab as separate Python packages, and says publication-chart-skill wraps them. Figure and table production therefore depends on two projects outside this repository. The README does not state version pinning for them. If either package changes its API, the skill that wraps it is the thing that breaks. Finally, the project is honest about being semi-automated, and that is a limitation rather than a feature claim. It will not tell you that your baseline is unfair or that your ablation is confounded. It organises what you decide. ## How this differs from running a plain coding CLI with a prompt library The obvious alternative is what most researchers already do: keep a folder of prompt snippets and paste them into Claude Code or Codex CLI as needed. The difference in approach is persistence and gating. A prompt library has no on-disk state between sessions and no notion of a claim that has been promoted. Claude Scholar adds planning-with-files as a default on-disk planning and progress-tracking workflow, and routes notes through Sources/Papers before they reach Knowledge or Writing. A second alternative is a reference manager plus a writing tool, with the AI used only for drafting. That keeps bibliographic data in a purpose-built application, which Claude Scholar does not attempt to replace: its Zotero integration is described as ingestion, not as a substitute for Zotero. The trade-off runs the other way too. A reference manager will not run your experiment scripts or produce a benchmark table, and Claude Scholar's publication-chart-skill explicitly connects analysis output to figure and table production. The honest comparison is that a prompt library is cheaper to start and has no branch model to maintain, while Claude Scholar asks you to accept a file layout and an evidence contract in exchange for continuity across the research cycle. If your work is one paper with three co-authors and a deadline, the prompt library is probably enough. ## Maintenance cost, licence and what to check before committing The repository is not archived, and the last push was on 2026-08-27. The only release listed is v1.0.0 from 2026-02-25, while the changelog entries run from April through June 2026. That pattern suggests development happens on the branches and in the changelog rather than through tagged releases, which is normal for a workflow project but means you should pin to a commit rather than expect a version number to describe the state you installed. The changelog is dense and dated, with entries covering skill consolidation, agent pruning, install lifecycle changes and a safe install-state based uninstall path added on 2026-04-22. That uninstall support is worth noting: it implies the project writes state outside its own directory, and the README does not document what that state contains. The licence is MIT, stated in the repository badge and the LICENSE file at the root. MIT is permissive, so redistribution and modification are broadly allowed, but the repository also carries sponsor placements in the README and links to third-party API platforms. Those are commercial relationships, not licence terms. Nothing in the repository addresses what happens to sponsor links if you fork. That is a question for your own review, not a legal conclusion I can draw here. Before adopting it, verify three things in the branch you actually intend to use: that skills/ still contains the writing stack you need, that research-contract.md exists and its gate criteria are ones your group can meet, and that the install-state uninstall path works, since the README does not document rollback. ## Conclusion Claude Scholar suits computer science and AI researchers who already drive Claude Code, Codex CLI, Kimi Code CLI or OpenCode from a terminal and want literature review, experiment reporting and paper drafting to share one file layout and one evidence contract. It is the wrong tool if you work primarily in a GUI reference manager, if you need a single cross-CLI install, or if you want the tool to decide what your results mean. Before adopting it, check out the branch that matches your CLI rather than main, read research-contract.md to see what an Evidence Record and a Claim Promotion Gate demand of your notes, and confirm that the skills/ directory in that branch still contains the writing stack you need. ## FAQ ### How do I use Claude Scholar? Clone the branch that matches your CLI, since main is the Claude Code workflow and codex, kimi and opencode are separate branches. Copy settings.json.template to settings.json, then read MCP_SETUP.md or OBSIDIAN_SETUP.md if you need those integrations. A reasonable first task is the daily-paper-generator flow, which narrows candidates through a Top 10 to Top 3 to Top 1 selection. ### What is Claude Scholar? It is described in its README as a semi-automated research assistant for academic research and software development, aimed at computer science and AI researchers. It covers literature review, coding, experiments, reporting, writing and project knowledge management on top of Claude Code, Codex CLI, Kimi Code CLI or OpenCode. ### Which CLI does Claude Scholar support? The README names Claude Code, Codex CLI, Kimi Code CLI and OpenCode, and states that main is the Claude Code workflow while the other three have their own branches. The Kimi Code CLI branch was added on 2026-06-03 with support from the Kimi team. ### Does Claude Scholar replace Zotero? No. The changelog describes Zotero ingestion as one step connected to the shared research-contract.md, not as a replacement for Zotero itself. Project paper notes live under Sources/Papers before promoted claims move into Knowledge or Writing. ### What licence does Claude Scholar use? MIT, per the licence badge in the README and the LICENSE file at the repository root. The README also contains sponsor placements, which are separate from the licence terms. ### Does Claude Scholar produce paper figures and tables? Figure and table work is routed through publication-chart-skill, which the changelog says wraps two external Python packages, pubfig and pubtab. Because those live outside this repository, the skill depends on their APIs staying compatible. ## Sources - [Galaxy-Dawn/claude-scholar on GitHub](https://github.com/Galaxy-Dawn/claude-scholar) - [Issues](https://github.com/Galaxy-Dawn/claude-scholar/issues) - [License: MIT](https://github.com/Galaxy-Dawn/claude-scholar/blob/main/LICENSE) - [README](https://github.com/Galaxy-Dawn/claude-scholar/blob/main/README.md) - [Releases](https://github.com/Galaxy-Dawn/claude-scholar/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/galaxy-dawn-claude-scholar