subsystem-map
GitHub在回答Genesis能力、审计或架构对比前，必读docs/architecture/CURRENT.md以获取权威子系统映射。避免无依据的缺失声明，确保查询起点正确。变更能力后需同步更新地图及验证时间戳。
Trigger Scenarios
Install
npx skills add WingedGuardian/GENesis-AGI --skill subsystem-map -g -y
SKILL.md
Frontmatter
{
"name": "subsystem-map",
"keywords": [
"capability",
"capabilities",
"subsystem",
"map",
"audit",
"architecture",
"lacks",
"missing",
"compare",
"competitive"
],
"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.\n"
}
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".
Version History
- 83a6c7f Current 2026-07-19 22:29
