agentleFS
fkguofkguo/nullius/skills/literature-graph-builder/SKILL.md

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.

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
  1. Very specific:

    Use deep-literature-review first for source discovery, source-first per-paper notes, graph-ready exports, and synthesis.

    line 12
  2. Distinctive:

    Use this skill after notes exist, or while designing the graph-ready export that will consume those notes.

    line 13
  3. Very specific:

    Use markdown-hygiene before rendering notes and again after graph pages are generated.

    line 14
  4. Very specific:

    Use claim-grounding for source-support checks on graph edge claims or figure relevance claims.

    line 15
  5. Very specific:

    Use review-swarm for independent review of the current graph artifact after each substantive correction.

    line 16
  6. Very specific:

    Read references/graph-ready-contract.md when creating or auditing a graph export.

    line 20
  7. Distinctive:

    Run the validator on the graph JSON whenever graph content changes.

    line 37
  8. Distinctive:

    no displayed EPS/PS figure paths.

    line 45
  9. Distinctive:

    Figures: every figure card uses an actual local image/PDF source.

    line 64
  10. Distinctive:

    Connected literature: every connected-node entry is clickable and resolves to a rendered note or the corresponding node.

    line 65
  11. Distinctive:

    Use screenshots or DOM checks for the above when browser tooling is available.

    line 68
  12. Distinctive:

    After fixing reviewer findings, rerun review on the fixed artifact before declaring convergence.

    line 80

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

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-review first 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-hygiene before rendering notes and again after graph pages are generated.
  • Use claim-grounding for source-support checks on graph edge claims or figure relevance claims.
  • Use review-swarm for independent review of the current graph artifact after each substantive correction.

Workflow

  1. Read references/graph-ready-contract.md when creating or auditing a graph export.
  2. Build or normalize a literature_graph_v1 JSON artifact with stable node ids, node kinds, relative note paths, source locators, and source-backed edges.
  3. 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 .
  1. 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.
  2. 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.
  3. 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-hygiene with --raw-math-preset ascii-math and any project-supplied --raw-token patterns that catch domain-specific symbols or reactions.
  4. Display real figure assets, not filenames, paper front pages, or title-page screenshots. Convert EPS/PS sources to PNG/PDF before linking them.
  5. 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_path values;
  • 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 dataset

Rendering 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.

Download now (ZIP)

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
What did you use it for? e.g. Reviewing pull requests in a Rails app

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.