# Qinyan Academic Skills is 182 in one place, 187 in another > Qinyan Academic Skills is a plain-text library of research skills for six AI coding assistants, installed by piping one shell script and updated from the same moving branch. Its most interesting part is a five-step manuscript pipeline whose middle step checks for overclaiming, and whose most awkward detail is a skill count that does not match its own description. **LeonChaoX/qinyan-academic-skills** — A curated, multilingual library of 182 installable AI agent skills for end-to-end academic research—spanning literature discovery, scientific writing, grant development, bioinformatics, drug discovery, clinical research, machine learning, and data analysis. - Repository: https://github.com/LeonChaoX/qinyan-academic-skills - Stars: 932 · Forks: 83 - Language: Python - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/leonchaox-qinyan-academic-skills ## Three different totals for one library The repository's own description says the library holds 182 installable skills. The line under the title on the page says 187. The body text says the repository contains 187 skills across 18 domains. Two of those three numbers agree with each other and one does not agree with anything else on the page, which is the sort of thing a catalogue should be checked against. The category table is the third data point, and it is the only one a reader can verify. Nine entries are fully visible, an unnumbered first-party group plus categories 01 through 08, holding 10, 10, 6, 9, 10, 21, 12, 18 and 7 skills. That is 103 of the stated 187, across 18 domains in total, so a little over half the library is never enumerated in the table and category 09 is cut off mid-word. The remaining categories have to carry 84 skills between them, which is plausible but unchecked. None of this is a reason to distrust the library. It is a reason to treat any specific number quoted about it, including the ones on the page, as a snapshot of a moment when the two halves of the documentation were last edited together. ## The middle of the pipeline is built to catch overclaiming The first-party suite is five skills mapped to five stages of a manuscript, and the table states the primary output of each. Argument and drafting produces an evidence-led narrative, section drafts, a title, an abstract and a submission package. Structural and language revision produces concise academic prose with meaning-preservation checks and an anti-overclaim check. Pre-submission assessment produces prioritised, traceable review findings carrying stable issue identifiers. Figures and visual evidence produces reproducible multi-panel figures with export and preflight validation. Study design and statistics produces estimand-aware analysis plans, reporting audits and figure-ready results. Two of those are worth more attention than the others. The revision stage is the one that says no. A skill whose job is to remove overclaiming from a draft is aimed at the most common failure in a submitted paper, and pairing it with a meaning-preservation check is the right pairing, because tightening prose is exactly where a claim quietly gains strength. A revision tool that only removed hedges would be dangerous; one that also reports what meaning changed is usable. The review stage issues findings with stable identifiers. That is a small design decision with a large consequence: it makes findings addressable, so a later pass can assert that every issue raised earlier was closed rather than asking a reader to diff two prose documents. A reviewer who emits numbered, traceable findings is doing something closer to a compiler diagnostic than to a comment. The statistics stage being described as estimand-aware means the analysis plan starts from a formal statement of what quantity is being estimated, which is the current direction of travel in clinical research design and is not something a generic assistant would ask about unprompted. ## A suite named for a journal, and a project that disclaims the journal The suite is called Nature-style and its purpose is stated as moving from a defensible claim to a submission-ready manuscript. The page then carries a note that the phrase describes editorial and scientific communication goals, that the project is independent, and that it is not affiliated with, endorsed by, or guaranteed acceptance by Nature Portfolio or Springer Nature. That disclaimer is the correct thing to publish and it is also the thing to read carefully. A suite organised around one journal's house style, with a stage called submission packaging and a review step, is a bet that matching a specific venue's conventions is a useful thing to automate. The note makes clear that the project is not speaking for that venue and does not imply an outcome. Nothing on the page promises a higher acceptance rate, and the outputs are described as artefacts rather than results. The rest of the presentation is international in a way the file names are not. Five translations of the readme are offered, and the skills themselves live under category directories named in Chinese, while every skill identifier, every category id and every installer flag is plain ASCII. That combination works, and it is worth knowing that a shell installer walking non-ASCII directory names is a slightly different risk from one walking ASCII names, particularly on Windows where the page's own advice is to use a Linux-like shell instead. ## Install and update both read from a moving branch The installation path is a script fetched over the network and handed to a shell: ```bash curl -fsSL https://raw.githubusercontent.com/LeonChaoX/qinyan-academic-skills/main/install.sh | bash ``` The page anticipates the objection and answers it in the right way: the installer needs Bash, Git and curl, on Windows you should use a Linux-like shell, and if your environment requires source inspection you should read the script before piping it. That is an honest note rather than a dismissal. What the page does not offer is a version. The script is fetched from the project's default branch, and the repository has no published releases at all. So there is no tag to pin, no checksum to compare and no changelog entry to match an installed set against. The installer compounds this with its own maintenance commands: ```bash bash install.sh --status bash install.sh --check-update bash install.sh --update ``` A library that can update itself from a branch is convenient and means an installed skill set can change under you between two runs with no version marker. For a collection whose selling point is that every skill is plain text and reviewable, being able to diff the skill files after an update is the mitigation, and the repository being a plain git clone makes that diff easy. ## One installer, six layouts, and one that breaks the pattern The page gives a table of six supported agents, each with a tool value and two directories. Five of them follow the same shape, a hidden directory named after the agent at the top of the home directory for a global install and a matching hidden directory inside the project for a local one. The sixth does not. OpenCode's global directory is under the configuration directory for the user rather than a hidden folder in the home directory, while its project directory is the plain hidden form the other five use. So the same flag installs into two differently named locations depending on the agent, and a user who assumes the pattern will install somewhere OpenCode does not read. That is a small thing to get wrong, and it is the kind of small thing that produces a support question nobody can reproduce, because the install succeeded. The one installer covering six layouts is a reasonable design, and the table is the right place for it to be documented, which is where it is. The other choice the table implies is scope. Installation can be global or confined to a single project, and a project-scoped install is the one to prefer if you are trying one skill out, since it leaves the global agent configuration untouched and the skills are deleted with the directory. ## Most of the catalogue is discovered by search, not by reading The category table is a map, not an index. Nine groups are visible with counts ranging from 6 to 21 skills, spanning literature discovery and reference management, scientific writing and communication, academic presentation and visualisation, research methods and scientific reasoning, bioinformatics and genomics, cheminformatics and drug discovery, clinical medicine and precision health, and protein engineering and structural biology. The page states 18 domains in all, and the list is cut off partway through the ninth. Discovery is therefore delegated to the installer. Listing every skill, listing them briefly and searching by term are all commands the same script provides, and the page points at them instead of printing the index. For a library whose largest category is bioinformatics with 21 entries and whose first-party group sits outside the numbering entirely, that is a reasonable call. The unnumbered first-party group is worth a second look on its own. Ten skills covering paper search, analysis, citations and the five writing-suite skills sit in a directory with a name of their own rather than a numbered category, which suggests they are maintained separately from the rest. The distinction is not explained anywhere on the page, so a reader cannot tell whether they are updated on a different schedule or simply arrived first. ## Plain text skills, one executable, and a documentation directory The design claim in the highlights table is that every skill is plain text, reviewable, portable and easy to customise. That claim is checkable from the repository root, and it holds: the root holds a licence file, a readme in five languages, a separate document for the first-party suite, a documentation directory, the installer, and the skills directory. One executable file is visible at the root, the installer itself. The recorded primary language for the repository is Python, and none of it is at the root. That places the code inside the skill directories, which is consistent with skills that analyse data being more than prose, and also means the language statistic describes the contents of those directories rather than anything a user runs. A documentation directory sits at the root and is not linked in the part of the page that can be read here, while the first-party suite's own document is linked twice from the same page. So the depth of documentation is uneven by design: the five skills that matter most have their own guide, and the hundred and eighty others have the installer. That is a defensible allocation of writing effort for a library this size, and it is also why the count discrepancy matters more here than it would in a project with a real index. ## Conclusion This is a library rather than a tool, and the value is in the writing pipeline at its centre rather than in the hundred and eighty other skills. If you write papers, the five-step suite is the part to read, because the middle step is built to catch overclaiming and the review step issues findings with stable identifiers so a revision pass can be checked for closure. Three things to check before you install any of it. Read the installer, as the page itself advises, and note that the update command re-fetches from a branch rather than a tag, so an installed skill can change without a version number changing. Confirm the count, because three different totals appear for one library and the catalogue table only enumerates part of it. And check the project flags before a global install, because one of the six agents reads its skills from a different global path than the other five. ## FAQ ### What is qinyan-academic-skills? It is a library of installable research skills for AI coding assistants, stated on the page as 187 skills across 18 domains, covering literature discovery, scientific writing, grant development, bioinformatics, drug discovery, clinical research, machine learning and data analysis. Every skill is a plain text file. ### Which AI assistants does qinyan-academic-skills support? Six, each with a tool value and both a global and a project skills directory: Claude Code, Cursor, Codex, Gemini CLI, OpenClaw and OpenCode. One installer handles all six, and installation can be global or confined to a single project. OpenCode reads global skills from a configuration directory rather than a hidden folder in the home directory. ### Can I install one skill instead of the whole library? Yes. The installer takes a skill name, a category id, a project flag and a target tool, with short forms for the first three. It can also list skills, search by term, report status, check for updates, and update either everything or one named skill. ### Is qinyan-academic-skills affiliated with Nature? The page states that Nature-style describes editorial and scientific communication goals, and that the project is independent, not affiliated with, not endorsed by, and not guaranteed acceptance by Nature Portfolio or Springer Nature. ### What does the Nature-style suite in qinyan-academic-skills produce? Five skills covering one manuscript pipeline: argument and drafting, structural and language revision with meaning-preservation and anti-overclaim checks, pre-submission review returning prioritised findings with stable issue identifiers, reproducible multi-panel figures with export and preflight validation, and estimand-aware study design and statistics. ## Sources - [Issues](https://github.com/LeonChaoX/qinyan-academic-skills/issues) - [LeonChaoX/qinyan-academic-skills on GitHub](https://github.com/LeonChaoX/qinyan-academic-skills) - [License: MIT](https://github.com/LeonChaoX/qinyan-academic-skills/blob/main/LICENSE) - [README](https://github.com/LeonChaoX/qinyan-academic-skills/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/leonchaox-qinyan-academic-skills