wire-knowledge-graph

Audit and fix which curated seed relations reach a model's knowledge graph edges.

Updated Aug 28, 2026
One-click install
npx skills add https://github.com/jingtao-lbl/A2MC --skill wire-knowledge-graph-jingtao-lbl
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: wire-knowledge-graph
Source: https://github.com/jingtao-lbl/A2MC/tree/main/.claude/skills/wire-knowledge-graph
Command: npx skills add https://github.com/jingtao-lbl/A2MC --skill wire-knowledge-graph-jingtao-lbl

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires pyyaml, networkx.

What problem does it solve? A curated seed field that no graph builder pass reads is silently inert: it passes validation, produces no error, and changes no edge count, so the knowledge graph can be missing relations nobody knows about. This Skill audits which seed relation fields each model's graph builder actually consumes, fixes the gaps, and proves the rebuild is purely additive. ## Core Features & Use Cases - Coverage audit: Run tools/check_graph_coverage.py per profile and grep each model's builder (FATES rag/graph_builder.py, EcoSIM scripts/build_ecosim_rag.py, PFLOTRAN scripts/build_pflotran_rag.py) to find seed relation fields no pass reads. - Safe pass authoring: Write new builder passes that skip unresolved parameters instead of minting phantom nodes, never overwrite existing edges, and record distinctions as attributes rather than weights. - Additive rebuild verification: Diff the graph node-by-node and edge-by-edge before and after a graph-only rebuild, catching silent no-op rebuilds (e.g. FATES --graph-only without --rebuild) and metadata side effects. - Use Case: A Phase 3/4 traversal from a scored output returns nothing because the graph cannot reach the target parameter; use this Skill to trace the missing relation to an unread seed block, wire the pass, rebuild, and pin it with a seed-to-graph completeness test. ## Quick Start Ask the agent to audit whether the model's graph builder reads every relation field in its curated seed and fix any gaps it finds.

Frequently Asked Questions about wire-knowledge-graph

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I check if my knowledge graph builder reads all seed relation fields?▼

Run tools/check_graph_coverage.py for every registered profile; it compares each seed against its graph and exits 1 on a stated relation that reaches no edge. Then grep the model's builder script for each relation-bearing field, since the tool proves an edge exists but not which field produced it.

Why does my knowledge graph miss relations that are stated in the seed YAML?▼

A seed field that no builder pass reads is silently inert: validation only checks that names resolve, not that anything consumes them, and counts never fall for an edge that was never created. The fix is to write a builder pass that walks that field, mirroring a sibling model's builder that already has it.

How do I rebuild only the knowledge graph without reindexing the vector store?▼

EcoSIM supports scripts/build_ecosim_rag.py --graph-only, while FATES requires scripts/build_rag_index.py --rebuild --graph-only --profile <name>; --graph-only alone silently loads and re-saves the existing graph. PFLOTRAN has no graph-only mode, so use the rebuild-rag workflow instead.

What is the difference between wire-knowledge-graph and rebuild-rag?▼

wire-knowledge-graph handles relations stated in the seed that no builder pass reads, which fail silently. rebuild-rag handles reindexing, the vector store, and edges whose endpoints do not resolve, which the FATES builder reports loudly as skipped edges.

Why should a graph builder skip unresolved parameters instead of creating nodes?▼

Minting nodes for unresolved names creates phantom entries that answer queries about variables the model does not have. An unresolved parameter name is a seed defect for a human to fix; the builder should report it and skip, while outputs may legitimately be created since they can precede the parsed registry.

How do I verify a knowledge graph rebuild is purely additive?▼

Save the graph JSON before rebuilding, then diff node by node and edge by edge: a correct rebuild adds edges with zero removals, zero node changes, and zero pre-existing edge attribute changes. A count line alone cannot detect replaced edge attributes, and git diff on metadata files catches side effects like rewritten paths.