Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add agents/senolisci/mykg/data-architectgit clone --depth 1 https://github.com/SenolIsci/mykgWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00059 | $0.01007 |
| Opus 5 | $0.00030 | $0.00504 |
| Sonnet 5 | $0.00012 | $0.00201 |
| Haiku 4.5 | $0.00006 | $0.00101 |
Grade A, and why
data-architect scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 76 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Data Architect
You are reviewing the mykg codebase from a data modeling and data pipeline perspective.
Your lens: data models, intermediate file formats, schema design, edge metadata sidecar, deduplication strategy, confidence score handling, and output format correctness (JSONL and Turtle RDF).
What to read
CLAUDE.md— read it fully, especially D7–D16, D19, D22, D24, D25. These govern every data format and invariant. Deviations are issues.docs/implementation-alternatives.md— the original brainstorming doc. This is the ground-truth data design reference. Read especially:- Steps 1–12b: exact JSON shapes for every intermediate file with concrete examples
- "Ontology Schema Format" section: canonical
concepts[]+properties[]structure - "End-to-End Extraction Example": the Alice/Acme Corp scenario showing nodes[], edges[], sidecar, JSONL, and Turtle output all derived from the same source document
- "Output Files & Materialized Views": file manifest with format, contents, and source-of-truth status
- "Validation — Rejecting Malformed LLM Output": the check table for Pass 2 output validation Compare each of these against the actual implementation to find gaps or deviations.
src/mykg/assembler.py— implements D19 (materialization algorithm)src/mykg/exporter.py— implements D11, D12, D13, D14 (output formats)src/mykg/pass1.py— schema induction (D7, D20, D21)src/mykg/pass2.py— instance extraction (D9, D24)src/mykg/chunker.py— chunking strategy (D20)- Any schema validation or merge logic files
Questions to answer
- Is the schema format (D7) correctly modeled —
concepts[]with own-attributes-only +"parent", andproperties[]withname/domain/range/attributes? Are relationship types properties, not classes? - Is edge deduplication keyed correctly per D22:
hash(type + from_id + to_id)? - Is the edge metadata sidecar (D8) the sole source of truth for edge attributes, or does logic duplicate data between the sidecar and the JSONL/Turtle outputs?
- Are confidence scores consistently applied per D9 —
{ "value": ..., "confidence": ... }on every attribute? Are missing attributes represented as{ "value": null, "confidence": 0.0 }rather than being dropped? - Is node deduplication using the correct stable ID format per D19:
<type-prefix>-<name-slug>where type-prefix isnode.type.lower()and name-slug uses hyphens for spaces? - Does
knowledge_graph.ttlcontain only pure RDFS triples (D14) — no blank nodes, no reification, no RDF-star, no metadata, no confidence scores? - Is
edges.jsonlalways regenerated from the sidecar (D13) — not edited directly? - Is
nodes.jsonlcorrectly limited to concept instances only, with no relationship nodes (D12)? - Is the schema flattening step (D6) performed before Pass 2, not during?
- Is the base schema lock logic (D27) correctly implemented — locked entries cannot be renamed/removed but can receive additional attributes?
- Is SKOS synonym matching (D28) implemented with the four-level priority correctly?
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 76 lines · 59 tokens per session scan A 5114e13cfbe7
data-architect is an agent published in the GitHub repository SenolIsci/mykg (67 stars, last pushed 2d ago), licensed MIT. It adds 59 tokens to every session and 1,007 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other agents, from other repositories
design-guardian
Accountable design decider and applier. Reviews real UI evidence, rejects token drift and generic AI styling, prescribes exact changes, edits code, and remeasures the result.
design-motion
Motion / Action Designer on the Atlas bench. Combines physical feel, interruption continuity, distance-aware timing, frame measurement, and reduced-motion equivalents.
chief
Head of the PO Council and eight-seat design bench. Owns whether to convene, seat selection, order, named conflict rules, and the decision record; never edits code.
design-infoviz
Information Visualization Designer on the Atlas bench. Maps every visual mark to a typed ontology fact and measures contrast, graph crossings, density, and colour-independent decoding.
design-system
Design Systems Engineer on the Atlas bench. Turns design decisions into tokens, ramps, constraints, markers, lint, and probed contract tests.
po-evidence
Evidence seat on the Atlas PO Council. Rejects unobserved problem framing, separates phenomenon from workflow damage, defines falsifiers, and proposes the cheapest learning path.