The SWE loop binding every implementation session in this repo - fire whenever code is about to be written, changed, or resumed, at every chunk start and end, and whenever unsure what the next step is. Covers orient -> plan -> implement -> verify -> document -> commit (NEVER push) -> reflect. Nested lazy parts; load references/scale.md when work outgrows one context window (massive task/refactor, flood of tasks, mass research); load references/rot-check.md before a release, after a long repo gap, or on "rot check"/"is anything stale". Not for scaffolding new stacks (bootstrap) or skill hygiene (skill-manager).
The genome's lifecycle and hygiene, all in one place. Fire on "review the skills", before adding/splitting/merging any skill, when docs/state/miss-log.md has entries, or periodically when no pass has run for a while. ALSO fire the moment a lesson lands (a root cause found, a tool swapped, a convention decided, a default overridden, a mistake repeated) - load references/evolve.md; and on "absorb/steal from <repo>" or "spawn a project from this one" - load references/absorb.md. Owns abstraction altitude, consolidation, the skill cap, authoring standards, and decay.
Phase 0 of any project - fire whenever asked to start, scaffold, set up, or adopt a project ("new Python CLI", "set this repo up properly", "add a frontend stack"). Interview, scaffold via OFFICIAL creators, describe into project.yaml, prove with gates.
Publishing and discoverability - fire whenever the user wants to post, announce, launch, or promote anything (a LinkedIn post, an X thread, a Show HN, a launch/reflection draft), wants something findable (GitHub repo invisible in search, topics/description/social preview), or asks for a hook, post draft, or post image/GIF. Runs decide -> optimize -> draft -> post; the human always does the actual posting. Load references/linkedin.md, references/github.md, references/visuals.md on their triggers. Not for long-form video production, and not for in-repo docs (workflow step 4 owns those).
Fire between phases, before planning any new realism increment, or on "what should we simulate next" / "realism scan" / "what's missing from the sim". Inventories what the simulator already models, hunts real-world traffic phenomena it does not, and ranks the gaps by realism value vs integration cost against the current architecture's extension points. Output is a reviewed backlog document, never code. Not for planning the implementation itself (that's a phase plan via workflow) and not for bug hunting.