mcpField
C
check-invariants

check-invariants

github.com/jayden-dangTesting & quality135 installsUpdated 3d ago
Repository

About check-invariants

check-invariants is a review skill that judges whether a feature design or code diff follows the architecture invariants it cites or affects. It returns advisory, evidence-based verdicts rather than a pass/fail gate.

Key features

  1. 01Assess design or diff against invariants
  2. 02Consider cited and clearly relevant rules
  3. 03Return respects, violates, or unclear findings
  4. 04Give a concrete rationale for each verdict

Use cases

  1. 01Review a feature design before implementation
  2. 02Inspect a diff for architecture rule violations
  3. 03Surface unclear compliance for human review

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/jayden-dang/skills --skill check-invariants

After installing, type/check-invariantsin Claude Code to confirm it loaded.

Details

From the project README

Check Invariants

Judge whether a design (or a diff) honors the architecture invariants it relies on.

This is the semantic counterpart to trace. trace checks that a Respects: ARCH-N citation points at a live invariant — existence and liveness, deterministically, by grep. It never reads whether the design actually respects the rule. That judgment is this skill's job, and because it is a judgment it is advisory: its verdicts inform review, they are never a hard merge gate.

When there is nothing to check

If docs/architecture/ does not exist, there is no spine — say so once and stop. This skill only runs where a project has opted into the architecture layer.

Inputs

  • The architecture spine: docs/architecture/INDEX.md (+ any docs/architecture/<domain>.md). Read the invariants — each is a bold **ARCH-N** ID and one imperative rule. A struck-through ~~**ARCH-N**~~ is retired; ignore it.
  • The subject: a feature design.md, or a diff (git diff <base>...HEAD). Collect its Respects: ARCH-N citations; for a diff, also weigh invariants the changed code plainly touches even if uncited.

The judgment

For each cited invariant (and each clearly-relevant uncited one), read the rule, read what the design/diff does, and return one verdict:

VerdictMeaning
respectsThe design is consistent with the invariant.
violatesThe design does something the invariant forbids, or omits something it requires.
unclearThe design neither clearly honors nor clearly breaks it — a human should look.

Every verdict carries a one-line rationale naming the invariant and the concrete spot (a design section, a file, a hunk). Do not restate the invariant as its own rationale.

Output

check-invariants (3 citations, spine: docs/architecture/INDEX.md)
  violates ARCH-2  design.md §Cross-module sync calls the persistence module directly (invariant: only via the event bus)
  respects ARCH-4  every write goes through the migration guard
  unclear  ARCH-5  can't tell from the design whether the cache is invalidated on write

Report all verdicts; do not drop unclear ones — they are the point. This skill returns findings, never a pass/fail. The caller (code-review, execute-plan, establish-project) decides what to do with a violates.

Comments

Markdown supported