Skip to main content

alex-core-invariants

Use when reviewing architecture, refactors, state/data ownership, duplication, code and test structure, failure handling, debug discipline, work-in-progress hygiene, or concurrency policy against Alex's eight fixed invariants.

Informations de source

Dépôt
aldegad/alex-core-invariants
Dernière activité de la source
6 octobre 2026 à 04:23
Langue détectée de SKILL.md
anglais
Étoiles
43
Forks
8

Options d'installation

Le prompt qui vérifie d'abord la source est sélectionné par défaut. Vous pouvez passer à une commande directe ou télécharger une copie locale.

Vérifiez les fichiers source

Lisez SKILL.md et les fichiers associés affichés par SkillsMP avant de décider de l'installer.

Affichage de SKILL.md

SKILL.md
Instructions source · Aperçu en lecture seule
name
alex-core-invariants
description
Use when reviewing architecture, refactors, state/data ownership, duplication, code and test structure, 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`; on any drift with this file, README.md wins. - Link to `README.md`; never copy the invariants into another file. ## Workflow 1. Read `README.md` first. 2. Identify the canonical owner for each important truth, and flag copies — duplicated wording, features, or tests. 3. Place each changed unit in the domain taxonomy tree; flag a unit carrying two concerns, and tests that do not sit with the code they cover. 4. Flag dual-write, silent fallback, history-as-canonical, and legacy paths the change touched but kept. 5. For each new guard or test, name the failure only it catches; if there is none, it should not exist. Check that only the tests the change can affect were run. 6. Prefer self-heal from live truth over adding another truth surface. 7. If explicit failover exists, verify that it is observable and does not mutate canonical truth. 8. For problems in a standardized domain, search the official documentation before dispatching hypotheses. 9. Recommend the smallest change that restores the invariant boundary. ## Output Expectations - Findings first when doing review work. - Name the invariant, or the Simplicity rule, being violated. - Prefer fixes that remove structure — duplicates, unneeded guards and tests, legacy, ownership overlap, hidden recovery logic — over fixes that add it. - For a taxonomy finding, name the branch the unit belongs on. - Call out explicit failover separately from silent fallback. - For doc-first violations, cite the exact docs page that already had the answer.
Voir sur GitHub