subsystem-map

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 architectu

SKILL.md

GitHub

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

  1. 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.
  2. 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.
  3. 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".