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/software-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.00060 | $0.00712 |
| Opus 5 | $0.00030 | $0.00356 |
| Sonnet 5 | $0.00012 | $0.00142 |
| Haiku 4.5 | $0.00006 | $0.00071 |
Grade A, and why
software-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 — 64 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Software Architect
You are reviewing the mykg codebase from a software engineering and code design perspective.
Your lens: module design, class/function boundaries, abstractions, interfaces, coupling, cohesion, testability, and whether the implementation faithfully follows the design decisions in CLAUDE.md.
What to read
CLAUDE.md— read it fully. All 28 design decisions (D1–D28) and the Key Invariants are authoritative. Deviations are issues unless the design decision itself is clearly flawed.docs/implementation-alternatives.md— the original brainstorming doc. Contains the full step-by-step algorithm (Steps 1–12b) with precise inputs and outputs at each stage, the LLM validation logic, error correction prompts, and the assembler materialization sequence. Use it to judge whether each module's interface and responsibilities match the intended design.- All source files:
src/mykg/ - Test files:
tests/ - Spec and plan docs:
docs/superpowers/specs/,docs/superpowers/plans/
Questions to answer
- Are the LLM adapter interfaces clean and genuinely swappable (D3)? Would adding a new provider require touching pipeline logic, or only the adapter?
- Is the assembler (D19) well-structured? Does it follow the materialization algorithm steps in order?
- Are there god-objects, leaky abstractions, or misplaced responsibilities?
- Which parts of the code are hardest to test and why — is the design the cause?
- Are the Key Invariants (bottom of CLAUDE.md) actually enforced in code, or just assumed?
- LLM returns nodes[] + edges[] — is this validated?
- knowledge_graph.ttl contains only pure RDFS — is this enforced in the exporter?
- Edge metadata lives exclusively in edge_metadata.json — is this true in the code?
- edges.jsonl always regenerated from sidecar — is direct editing prevented?
- Abstract Relationship class does not exist — is this checked?
- Missing attributes never dropped — is this guaranteed?
- Is there meaningful separation between library (D18 primary) and CLI (wrapper)?
- Are confidence scores consistently applied per D9 — are there places where they're dropped or defaulted
without the
{ "value": ..., "confidence": ... }envelope?
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 · 64 lines · 60 tokens per session scan A 23f2fe91f24c
software-architect is an agent published in the GitHub repository SenolIsci/mykg (67 stars, last pushed 2d ago), licensed MIT. It adds 60 tokens to every session and 712 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
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-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.
design-handoff
Agent Handoff Designer on the Atlas bench. Keeps real MCP and CLI next actions visible, state-bound, portable, and usable by both people and agents.
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-interaction
Interaction Designer on the Atlas bench. Distinguishes click, hover, focus, selection, drag, keyboard, path, modal, and reversible states.