A general-purpose research-assistance skill set for Claude Code, covering the full
arc of a research project across any field -- pure theory, empirical/quantitative
work, wet-lab science, qualitative social science, and humanities -- not just the
energy-systems thesis project the workflow was originally generalized from. See
docs/design-notes.md for the full gap analysis this set is built against, and
CLAUDE.md for the project's working conventions and current status.
Ships as one combined plugin, not independently-movable skill folders: most of
the skills invoke bundled tools under tools/ shared across skills, and several
skills (research-plan/analysis-rigor, research-ideation/literature-survey,
analysis-rigor/fact-check-loop) cross-reference each other directly. Install the
whole repo as a single Claude Code plugin rather than copying individual
<skill-name>/ folders out on their own.
data-collection and analysis-rigor also carry a references/<domain>.md
subfolder each -- general workflow in SKILL.md, field-specific detail loaded only
when relevant.
| Skill | One-line job |
|---|---|
research-ideation |
Map an open area for an actual gap, sanity-check a specific idea's novelty, or rank several candidates -- before committing real time. |
paper-explainer |
Deep, standalone plain-language rewrite of one dense source paper (equations or argument-driven claims, whichever it actually uses), plus a short re-skim summary. |
literature-survey |
Once a direction is set, find and summarize related work, each tagged with why it matters to the project; optionally a side-by-side comparison matrix. |
research-plan |
Turn "reproduce/extend X" into an actionable, ordered build plan, including the intended study design (handed to analysis-rigor) before results exist. |
data-collection |
Find real data (or specimens, participants, primary/archival sources, scraped corpora, workloads -- whatever the field's "data" is) first, fall back to a documented substitute only where the domain allows one, write honest provenance docs. |
analysis-rigor |
Design-time commitment to a rigorous analysis approach -- right test/design, checked assumptions, effect sizes, or the ML/qualitative/interpretive/proof-based equivalents -- before results exist. |
draft-synthesis |
Turn scattered artifacts into one coherent document, picking the target's actual native structure (thesis, paper, technical report, incident postmortem, humanities essay) rather than forcing one template. |
latex-writer |
Draft or convert to LaTeX natively for fields/venues that actually require it, tagging data values from the start and checking structure mechanically before ever compiling. |
fact-check-loop |
Triple-audit YOUR OWN draft against its own data/code/citations and its analysis's methodological soundness, fix with a changelog, repeat until it converges. |
peer-review |
Read-only audit of a document you don't own or can't edit -- a published paper, a manuscript, a colleague's draft -- calibrated to whatever data/code access actually exists, with no fixes applied and no fixed verdict rubric forced. |
friction-log |
Continuously log tool bugs, skill-instruction gaps, and environment limits hit along the way; aggregate logs across many projects/fields to tell general gaps apart from one project's own quirks. |
Roughly the order a project would use them in: research-ideation -> paper-explainer
-> literature-survey -> research-plan (which pulls in analysis-rigor for its
study-design step) -> data-collection -> (build/analysis happens, governed by the
analysis-rigor plan) -> draft-synthesis (or latex-writer in place of it, when
the target venue actually requires LaTeX) -> fact-check-loop (repeatable). In
practice they're invoked as needed, not necessarily in a strict pipeline -- e.g.
literature-survey gets reused mid-project whenever a new assumption needs an
independent check, and fact-check-loop runs however many times it takes to
converge. peer-review sits outside this pipeline entirely -- it's for auditing
someone else's work, not your own, and never hands off into draft-synthesis/
fact-check-loop the way the rest of the sequence does. friction-log runs
alongside all of the above continuously, not as a pipeline stage of its own.
Bundled, stdlib-only Python CLIs for the mechanical, deterministic work a skill
shouldn't re-derive by prompt every time (same principle as ~/.claude/skills/graphify,
scaled down to plain scripts rather than a published package):
| Tool | Backs | What it does |
|---|---|---|
tools/citation-manager |
literature-survey writes, fact-check-loop/peer-review read |
Structured JSON citation store: Crossref/DataCite metadata resolution, DOI dedup, orphaned/dangling \cite{}/[@key] detection against draft files, BibTeX export, plus a store-free check of a document's in-text citations against its own reference list (for peer-review, where no store exists). |
tools/traceable-claims |
draft-synthesis tags, fact-check-loop checks |
Lightweight inline tag (\dataval{path:key}{value}) around any data-derived number; mechanically verifies each tagged number against its live JSON/CSV/YAML source instead of relying on LLM fuzzy-matching. |
tools/research-version |
fact-check-loop snapshots/diffs |
Auto-numbered version store (v1, v2, ...) with a real diff between any two snapshots -- replaces the manual mkdir/cp/git mv dance and its edge cases. |
tools/provenance-manifest |
data-collection writes, fact-check-loop reads |
Structured per-file provenance (source, classification, calibration history, checksum) that generates the provenance README and can be mechanically checked against the actual data files, instead of hand-maintained prose that can drift. |
tools/experiment-tracker |
research-plan/analysis-rigor wrap runs, fact-check-loop reads |
Logs config/seed/git-commit/exit-code/metrics per computational run (a tiny local W&B/MLflow) so "what produced this number" stays answerable. |
tools/repro-package |
fact-check-loop, optional deeper check |
Bundles exactly what's needed to reproduce one result and actually re-runs it in a fresh venv to confirm it works -- not just that the bundle looks complete. Explicitly scoped to Python-based reproductions; not full OS-level isolation. |
tools/latex-tools |
latex-writer checks/compiles |
Structural LaTeX validation (balanced braces/environments, unresolved \cite{} keys, missing figures, stray unescaped %) plus toolchain-aware compilation (tectonic, then latexmk, then pdflatex) instead of assuming one specific engine or none at all. |
tools/friction-log |
Every skill logs to it as friction is hit | Structured JSON log of tool bugs / skill-instruction gaps / environment limits, filterable and exportable, with an aggregate mode that merges logs from many projects (tagged by project) for cross-field comparison. |
Each has its own README.md and a test_*.py suite (stdlib unittest, run directly
with python3 test_*.py). All six tool candidates from docs/design-notes.md §5 are
built, plus two follow-up tools (latex-tools, friction-log) added after real
dogfooding on a full end-to-end project surfaced concrete gaps in both the existing
tools and the skill set's own self-improvement loop.
Local use only for now -- place (or symlink) this repo at
~/.claude/skills/research-suite/; Claude Code auto-loads anything there next
session as research-suite@skills-dir, no marketplace involved:
ln -s /path/to/research-suite ~/.claude/skills/research-suite