| name | alex-core-invariants |
| description | Use when reviewing architecture, refactors, state/data ownership, failure handling, debug discipline, work-in-progress hygiene, or concurrency policy against Alex's eight fixed invariants. |
Alex Core Invariants Skill
Source of Truth
- Canonical policy text lives in
README.md.
- If this file and
README.md differ, README.md wins.
- On policy drift, README.md wins.
When To Use
Use this skill when reviewing architecture, refactors, data flow, persistence boundaries, migration design, failure-handling behavior, or debug discipline (especially when a problem lives in a standardized infra/spec domain — Cloudflare, HTTP, OAuth, browser APIs, AWS/GCP, Kubernetes, build toolchains).
Workflow
- Read
README.md first.
- Identify the canonical owner for each important truth.
- Flag dual-write, legacy shadow paths, silent fallback, and history-as-canonical patterns.
- Prefer self-heal from live truth over adding another truth surface.
- If explicit failover exists, verify that it is observable and does not mutate canonical truth.
- For problems in a standardized domain, search the official documentation before dispatching hypotheses.
- Recommend the smallest change that restores the invariant boundary.
Output Expectations
- Findings first when doing review work.
- Name which invariant is being violated.
- Prefer fixes that reduce structure, ownership overlap, or hidden recovery logic.
- Call out explicit failover separately from silent fallback.
- For doc-first violations, cite the exact docs page that already had the answer.
Do Not
- Create a second canonical copy of the eight invariants in another file.
- Keep legacy write paths alive "just in case".
- Hide primary-path failure with quiet fallback behavior.
- Burn cycles dispatching guesses on a problem the official docs already solved.
