Skip to content
cccskills
FreePublished on GitHub

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 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.

The English summary is being prepared. Showing the original description.

See how to install

Files included (1)

  • SKILL.md2.7 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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".

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Forward Deployed Engineer delivery contract for AWS engagements, build-first artifacts, grounded cost estimates, Well-Architected review, evolution roadmap

The English summary is being prepared. Showing the original description.

WingedGuardian/GENesis-AGI99Updated Oct 19, 2026

Canonical guide to Genesis browser automation - layers (Camoufox, Chromium, the user's Chrome over CDP, TinyFish, desktop), per-tool timeouts, safety gates, verify-after-act, what a click checks (scroll, hit test, covered targets), overlays, iframes, tabs, and failure diagnosis

The English summary is being prepared. Showing the original description.

WingedGuardian/GENesis-AGI99Updated Oct 19, 2026

Update Claude Code (the CC CLI / "clog code") to a new version, or bump the pinned CC version. Use when the user asks to update Claude Code, bump the CC pin, evaluate a new CC release, or says "clog code update". Routes to the canonical, standardized process in docs/reference/cc-compatibility.md — do NOT re-derive the update mechanism by grepping every time. Do NOT use for general "what changed in CC" trivia with no intent to update.

The English summary is being prepared. Showing the original description.

WingedGuardian/GENesis-AGI99Updated Oct 19, 2026

This skill should be used when a session's job is to DRIVE OPEN PRs TO MERGE rather than to write new code — "close out the open PRs", "review and fix the open PRs", "what's blocking our PRs", "which PRs are mergeable". It owns the In Review column: it reads each PR's gate status, verifies and fixes review findings on PRs OTHER sessions built, replies in-thread, and stops at the merge gate for the user's per-PR approval. Do NOT load it for building a feature and opening its PR — that is a build session (`genesis-development`).

The English summary is being prepared. Showing the original description.

WingedGuardian/GENesis-AGI99Updated Oct 19, 2026

Code understanding tool selection. Use when exploring architecture, finding definitions, tracing call chains, assessing blast radius of changes, or debugging code paths in the Genesis codebase.

The English summary is being prepared. Showing the original description.

WingedGuardian/GENesis-AGI99Updated Oct 19, 2026

End-to-end content creation and publishing. Takes a topic (or generates one), drafts in the user's voice, gets approval via Telegram, and publishes to Medium via browser automation. Invoke with "publish a post about X", "write and publish to Medium", "content-publish", or when an ego-dispatched session needs to create and distribute content.

The English summary is being prepared. Showing the original description.

WingedGuardian/GENesis-AGI99Updated Oct 19, 2026

See all skills by WingedGuardian

Report a problem with this skill