literature-graph-builder
Skill20 starsChanged 22 days agoMITView on GitHub
Build, validate, and QA auditable literature graphs from deep-read notes and survey artifacts. Use when an agent needs to turn a literature review into an interactive graph with paper/method/topic nodes, source-backed edges, embedded notes, portable relative links, rendered math, verified figures, and browser-tested interactions.
In this repository34 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- citation-triangulationSkill
- claim-groundingSkill
- claude-cli-runnerSkill
- codex-cli-runnerSkill
- deep-literature-reviewSkill
- derivation-verifySkill
- dsh-cli-runnerSkill
- figure-hygieneSkill
- gemini-cli-runnerSkill
- hep-calcSkill
- hep-mcp-usageSkill
- idea-allocationSkill
- idea-generationSkill
- idea-pairwise-matchSkill
- idea-posteriorSkill
- julia-packageSkill
- julia-perfSkill
- kimi-cli-runnerSkill
- literature-to-packageSkill
- markdown-hygieneSkill
- numerical-reliability-gateSkill
- opencode-cli-runnerSkill
- paper-reviserSkill
- pdg-lookupSkill
- physics-diagramsSkill
- referee-reviewSkill
- research-harnessSkill
- research-integritySkill
- research-teamSkill
- research-writerSkill
- review-swarmSkill
- zotero-importSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 7 are distinctive, and 5 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
5
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 12
Use deep-literature-review first for source discovery, source-first per-paper notes, graph-ready exports, and synthesis.
- Distinctive: line 13
Use this skill after notes exist, or while designing the graph-ready export that will consume those notes.
- Very specific: line 14
Use markdown-hygiene before rendering notes and again after graph pages are generated.
- Very specific: line 15
Use claim-grounding for source-support checks on graph edge claims or figure relevance claims.
- Very specific: line 16
Use review-swarm for independent review of the current graph artifact after each substantive correction.
- Very specific: line 20
Read references/graph-ready-contract.md when creating or auditing a graph export.
- Distinctive: line 37
Run the validator on the graph JSON whenever graph content changes.
- Distinctive: line 45
no displayed EPS/PS figure paths.
- Distinctive: line 64
Figures: every figure card uses an actual local image/PDF source.
- Distinctive: line 65
Connected literature: every connected-node entry is clickable and resolves to a rendered note or the corresponding node.
- Distinctive: line 68
Use screenshots or DOM checks for the above when browser tooling is available.
- Distinctive: line 80
After fixing reviewer findings, rerun review on the fixed artifact before declaring convergence.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Literature Graph Builder
Build an inspectable graph layer on top of already deep-read literature notes. This skill owns graph artifact contracts, rendering checks, link and figure portability, note embedding, and browser QA. It does not replace source reading, citation discovery, or claim grounding.
Boundaries
- Use
deep-literature-reviewfirst for source discovery, source-first per-paper notes, graph-ready exports, and synthesis. - Use this skill after notes exist, or while designing the graph-ready export that will consume those notes.
- Use
markdown-hygienebefore rendering notes and again after graph pages are generated. - Use
claim-groundingfor source-support checks on graph edge claims or figure relevance claims. - Use
review-swarmfor independent review of the current graph artifact after each substantive correction.
Workflow
- Read
references/graph-ready-contract.mdwhen creating or auditing a graph export. - Build or normalize a
literature_graph_v1JSON artifact with stable node ids, node kinds, relative note paths, source locators, and source-backed edges. - Validate the graph before rendering:
SKILL_DIR="${SKILL_DIR:-$(for r in "${CLAUDE_CONFIG_DIR:-$HOME/.claude}" "${CODEX_HOME:-$HOME/.codex}" "$HOME/.config/opencode" "$HOME/.kimi-code"; do [ -d "$r/skills/literature-graph-builder" ] && echo "$r/skills/literature-graph-builder" && break; done || true)}"
python3 "$SKILL_DIR/scripts/bin/validate_literature_graph.py" --graph path/to/literature_graph.json --project-root .- Render the graph as a portable local artifact. Keep local paths relative to the graph HTML file or project root; do not emit machine-specific absolute paths.
- Embed note content in the page or route note links through a local renderer. Clicking a node must open the rendered note on the first click, not only after a layout jitter.
- Render math with a real math renderer such as MathJax or KaTeX. Do not leave mathematical expressions as raw plain text or code spans in notes, tables, sidebars, or tooltips. Before browser QA, run
markdown-hygienewith--raw-math-preset ascii-mathand any project-supplied--raw-tokenpatterns that catch domain-specific symbols or reactions. - Display real figure assets, not filenames, paper front pages, or title-page screenshots. Convert EPS/PS sources to PNG/PDF before linking them.
- Browser-test the graph: first-click behavior, node dragging, collision/label overlap, viewport fit, side-panel links, raw-note links, image loading, and math rendering.
Contract Checks
Run the validator on the graph JSON whenever graph content changes. It checks:
- unique node ids and valid edge endpoints;
- required node labels, kinds, and relative
note_pathvalues; - portable paths with no absolute local paths or parent-directory escapes;
- existing Markdown notes for graph nodes;
- source-backed edge metadata rather than unlabeled visual lines;
- figure assets that exist, are relative, and are renderable image/PDF formats;
- no displayed EPS/PS figure paths.
The validator is intentionally conservative. If a project needs extra relation names or node kinds, pass them explicitly instead of weakening the baseline:
python3 "$SKILL_DIR/scripts/bin/validate_literature_graph.py" \
--graph path/to/literature_graph.json \
--project-root . \
--allow-relation reuse \
--allow-node-kind datasetRendering QA
For an HTML graph, verify these properties before calling it usable:
- First click: a click on the visual node body opens the note without requiring a second click.
- Drag and collision: nodes can be dragged; labels remain readable; the layout avoids stacking nodes over captions, legends, or side-panel text.
- Math: rendered notes and summary tables contain MathJax/KaTeX output, not raw math-like ASCII or code spans.
- Figures: every figure card uses an actual local image/PDF source; source locators link to the note, converted figure, or original source artifact.
- Connected literature: every connected-node entry is clickable and resolves to a rendered note or the corresponding node.
- Portability: moving the artifact directory to another machine preserves relative graph, note, and figure links.
Use screenshots or DOM checks for the above when browser tooling is available. A graph that renders visually but has broken node clicks, missing images, unrendered math, or dead side-panel links is not complete.
Review Gate
For durable or public graph artifacts, run independent reviewers on the current files, not on a prose summary. Ask them to inspect:
- whether every node has a substantive note;
- whether important edges are source-backed and not merely topical similarity;
- whether figure assets are meaningful and actually displayed;
- whether browser interactions and portable links work;
- whether the skill boundary stayed domain-neutral and avoided project-specific hardcoding.
After fixing reviewer findings, rerun review on the fixed artifact before declaring convergence.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

