| name | subsystem-map |
| description | 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.
|
| keywords | ["capability","capabilities","subsystem","map","audit","architecture","lacks","missing","compare","competitive"] |
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-map blocks — the union covers every top-level package
in src/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".
