genesis-development

## Load Gate Before reading any reference, confirm the task is Genesis-*development*, not Genesis-*as-tool*. If uncertain, ask the user: "Are we modifying Genesis itself, or using Genesis for something else?" ## On-Load Mindset Internalize these immediately when this skill fires — they shape how to work from the start, not just what to check before commit. ### Wiring Discipline Every new component needs at least one call site in the actual runtime path. Apply this 4-level verification taxonomy: 1. **Exists** — file/function present. Proves nothing. 2. **Substantive** — tests pass, handles happy + error. No runtime proof. 3. **Wired** — live call site, import chain unbroken. Minimum for "done." 4. **Data-Flow Verified** — real data flows end-to-end. Required for critical paths. Mark nothing "done" below Level 3. ### GROUNDWORK Code Is NOT Dead Code Code tagged `# GROUNDWORK(feature-id): why` is intentional future investment. Never delete or refactor it as dead code. Only remove when the feature is fully active or the user explicitly cancels it. ### Architecture Review For medium-to-large Genesis work (3+ files, new components, wiring changes), dispatch a `genesis-architect` subagent before implementation to check dependencies, edge cases, and DRY violations. Small targeted changes skip this. ### Timeout Policy The burden of proof is on you to justify why a timeout should exist. Do not default to "add a timeout for safety." Instead: 1. **Identify the specific f...