How do I install the Alex Core Invariants skill?

Run npx skillmds@latest add aldegad/alex-core-invariants in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Alex Core Invariants skill do?

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. It is listed under Coding & Dev Tools on SkillMD.

Is Alex Core Invariants safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Alex Core Invariants?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Alex Core Invariants free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Alex Core Invariants?

aldegad (@aldegad) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Alex Core Invariants by aldegad — Agent Skill

Name: Alex Core Invariants
Author: aldegad

File contents

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.

Frequently asked questions

Alex Core Invariants