subsystem-map
Skill100 starsChanged 6 days agoMITView on GitHub
This skill should be used before answering "does Genesis have X", "does Genesis lack X", auditing Genesis capabilities, comparing Genesis to an external system, or reviewing/summarizing the architecture. It routes to the canonical judgment-layer subsystem map so audits start from the map, not from a cold grep. Also fires after changing a subsystem's capabilities, to keep the map current.
In this repository19 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- genesis-external-clientSkill
- build-sessionSkill
- cc-updateSkill
- closing-sessionSkill
- code-intelligenceSkill
- content-publishSkill
- deliverable-builderSkill
- genesis-developmentSkill
- genesis-voiceSkill
- shelveSkill
- spec-sessionSkill
- tasteSkill
- unshelveSkill
- validating-mergesSkill
- voice-masterSkill
- web-researchSkill
- youtube-fetchSkill
The file
We split this skill into the rules it gives an agent
3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈2
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 44
After you change a subsystem's capabilities (new mechanism, new gate, wiring flip, removal) or re-verify an entry during an audit:
- Very specific: line 47
Update the owning entry's prose and its modules: block if the package set changed.
- Distinctive: line 58
Never conflate them; everything here is "subsystem map".
≈ “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
The Rule
Read docs/architecture/CURRENT.md FIRST — before any grep, agent
dispatch, or claim about what Genesis has or lacks. It is the canonical
judgment-layer map: what each subsystem is FOR, its easy-to-forget
mechanisms, maturity (live / shadow / dark), and do-not-touch edges.
A claim of absence ("Genesis lacks X", "Genesis should add X") made without consulting the map first is a protocol violation — the 2026-06-30 audit produced 6/7 wrong infrastructure claims exactly this way.
Workflow
- Locate the entry. Find the subsystem entry (or entries) covering the
capability in question. Entries claim modules in fenced
yaml subsystem-mapblocks — the union covers every top-level package insrc/genesis, so "no entry mentions it" means you're using the wrong concept name, not that it doesn't exist. - Trust but verify. The map is judgment-layer, not ground truth. Check
each entry's
verified: <sha> <date>stamp; if its modules have moved since, re-verify the specific claim against the live tree before relying on it. - Then enumerate. For absence/existence conclusions, follow the audit
protocol (procedure
codebase_audit/ dev-skill "Auditing Existing Capabilities"): enumerate the subsystem's module inventory, trace the call graph both directions, grep by concept with synonyms, and verify against RUNTIME state (env gates, logs) — the map tells you where to look, not what to conclude.
Write-Back Duty
After you change a subsystem's capabilities (new mechanism, new gate, wiring flip, removal) or re-verify an entry during an audit:
- Update the owning entry's prose and its
modules:block if the package set changed. - Bump the entry's
verified:stamp to the current short sha + date.
CI enforces the module partition (scripts/check_subsystem_map.py): a new
top-level package that no entry claims fails the build; stale stamps warn.
Naming Trap
capability_map (DB table) and ego/capability_aggregator.py are the
ego's per-domain self-confidence model — completely unrelated to this map.
Never conflate them; everything here is "subsystem map".
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.