AcademicForge: a skill picker for Claude Code, OpenCode and Codex

The problem AcademicForge addresses for agent users

Academic skill collections tend to be distributed as whole repositories. You clone one, and you get every skill the author ever wrote, including the ones about protein folding when you only wanted help with a literature review. The README frames the project as a reaction to exactly that: "不用整仓复制全部 skill", or do not copy the entire repository of skills. The stated workflow is three steps, browse and tick packs on the site, generate an install command, then run it in your own project root.

The audience is narrow and specific. The README describes AcademicForge as a skill selection and installation platform for Claude Code, OpenCode and Codex, three agent tools that read skill definitions from a project directory. If you do not use one of those, nothing here applies to you. The project is not a Python package you import, despite Python being the primary language in the repository. It is a registry, an installer script and a static site.

How the registry, the installer and the site fit together

The repository layout shows the split. There is a registry/ directory, a scripts/ directory, a site/ directory, a forge.yaml at the top level, and skills/ holding the actual skill content. The package.json defines the build chain: build:agent-index runs scripts/build-slim-index.mjs, validate:registry runs scripts/validate-registry.mjs, and ci:validate chains validation, tests and the site build. So the registry is machine-checked rather than hand-maintained prose, and the site is built from it.

The installer is a shell script for macOS and Linux and a PowerShell script for Windows, both under scripts/. The site's job is to produce the argument list for those scripts, meaning the site and the CLI share one input format. Skills are grouped into packs, and a pack name can stand in for its members: the README shows --skills claude-science installing the whole 32-skill Claude Science set, while --skills humanizer,superpowers installs two individual skills. That pack-or-skill duality is the core mechanism, and it is why the site can generate a command without knowing anything the script does not also accept.

Installing a first pack with forge-install.sh

The README gives a one-liner that pipes the install script into bash with arguments after --. Run it from the root of the project where you want the skills to appear, not from a home directory, because the script writes relative to the current working directory.

cd your-project
curl -sSL https://raw.githubusercontent.com/HughYau/AcademicForge/refs/heads/site-first/scripts/forge-install.sh | bash -s -- \
  --tool claude \
  --skills humanizer,superpowers

The --tool flag selects the target agent (claude in this example) and --skills takes a comma-separated list. The README states that a skill with the same name already installed is skipped with a message, and that adding --force overwrites and updates it. If you only want the Claude Science collection, the README gives a shorter form with a single pack name.

curl -sSL https://raw.githubusercontent.com/HughYau/AcademicForge/refs/heads/site-first/scripts/forge-install.sh | bash -s -- --tool claude --skills claude-science

On Windows the README downloads the PowerShell script to the current directory first, runs it, then deletes it. Note the flag case changes: -Tool and -Skills, and -Force instead of --force.

cd your-project
$script = Join-Path $PWD 'forge-install.ps1'
Invoke-WebRequest -Uri 'https://raw.githubusercontent.com/HughYau/AcademicForge/refs/heads/site-first/scripts/forge-install.ps1' -OutFile $script
& $script -Tool claude -Skills 'humanizer,superpowers'
Remove-Item $script

After running either script, the skills should be present in your project and readable by the selected agent. The README does not document the exact destination directory per agent, so confirm where the files landed before assuming your agent will pick them up.

Letting the agent choose, and what that depends on

The third documented path skips the site and the flags entirely. You paste a prompt into your agent asking it to fetch https://hughyau.github.io/AcademicForge/agents.md, learn your research needs from the conversation, then pick skills from the AcademicForge catalogue and generate the install command. This is the most interesting design decision in the project, because it turns the registry into something an agent reads rather than something a human browses.

It also concentrates the risk. The quality of the selection depends on the agent's reading of agents.md, and the README does not describe how that file is generated or how often it is regenerated relative to the registry. There is a build:agent-index script, which suggests the file is derived from the registry rather than written by hand, but the README does not state the relationship. If you use this path, check the generated command against the site before running it.

Where AcademicForge is the wrong tool

The project has no releases. The releases section is empty, so there is no versioned artifact to pin, no changelog entry tied to a tag, and no way to say "we are on 1.2" in a methods section. The install path is a curl pipe from a branch named site-first, which means you are tracking a moving target. For a personal project root that is fine. For a shared lab environment where three people need identical tooling, it is not, because two installs a month apart can differ with no version number to point at.

The second limitation is licence scope. The README is explicit that the repository structure, site, scripts and local content are MIT, while third-party skills keep their own licences and author information. The repository's own licence field is reported as NOASSERTION, and the README's MIT badge refers to the repository's own material. So the MIT badge tells you nothing about the 32 Claude Science skills or anything else vendored under skills/. If you are packaging this into something you distribute, that distinction matters more than the badge does.

The third limitation is that this is not a Python library. Python is the primary language in the repository, but the README documents only shell, PowerShell and site workflows. There is no import path, no API, and no documented programmatic interface to the registry.

How it differs from copying a research skill repository

The closest alternative is the approach AcademicForge was built against: clone a research skill repository wholesale and let the agent see everything. Projects like Master-cai/research paper writing-skills and the various researcher skill collections follow that model. The difference is not quality, it is selection and blast radius. A wholesale clone puts every skill in your project, which means every skill's instructions are candidates for your agent to load, and every skill's licence is now something you are carrying.

AcademicForge inverts that. You pick, the site generates a command, the script writes only what you asked for, and the README says same-name skills are skipped unless you pass --force. The cost of that control is a dependency on the project's registry staying accurate and on the installer scripts working. A wholesale clone has no such dependency: once cloned, it is yours. If you want a small, deliberate set and you are willing to re-run an installer, AcademicForge is the better fit. If you want a frozen copy you control completely, clone the source collection instead.

Maintenance, upgrades and what to check before relying on it

The last push to the repository was on 2026-08-30, which is recent, and the repository is not archived. That tells you someone is still committing. It does not tell you anything about release discipline, because there are no releases to look at.

Upgrading is manual by design. The README documents --force (or -Force) as the way to overwrite and update an already-installed skill, which means the upgrade path is re-running the install command with that flag. There is no version pinning, no lockfile, and no documented way to install a specific revision of a skill. If a skill changes in a way that breaks your workflow, your rollback is whatever your own version control recorded when you first ran the installer. That is worth setting up before you install, not after.

On licensing, the practical step is to read ATTRIBUTIONS.md, which the README lists alongside QUICKSTART.md in the documentation section. The README states that third-party skills retain their own licences and author information, so attribution obligations travel with the individual skill directories, not with the repository root. This is a description of what the project says, not legal advice; if you redistribute, check each skill's own licence file.

Editorial conclusion

Adopt AcademicForge if you already work inside Claude Code, OpenCode or Codex and want a smaller, curated set of academic skills instead of cloning a large collection by hand. Skip it if you need a maintained Python library with versioned releases, or if you expect the installer to manage upgrades for you. Before installing, read ATTRIBUTIONS.md and the individual skill directories, because the README says third-party skills keep their own licences and the repository-level MIT badge does not cover them. Then check whether your agent actually reads AGENTS.md or the skills directory layout the installer writes, since that is what decides whether the packs load at all.

Frequently asked questions

Official sources

1. HughYau/AcademicForge on GitHub
2. Issues
3. Project website
4. README