Skip to content
Back to skills

Go Domain Invariant

ASecurity

Use when business acceptance, rejection, transitions, replay meaning, or effect order changes what states and moves are legal.

  • 7 stars
  • 0 votes
  • 0 copies
  • 0 views
  • Added September 24, 2026
developmentgo

Security analysis

A100/100

Pro scans all 11 files and shows the line behind each finding

Scanned September 24, 2026

npx -y skills add Dankosik/go-service-template-rest --skill go-domain-invariant --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Go Domain Invariant?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Go Domain Invariant
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/dankosik-go-domain-invariant/badge)](https://www.skillsdirectory.com/skills/dankosik-go-domain-invariant)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: go-domain-invariant
description: "Use when business acceptance, rejection, transitions, replay meaning, or effect order changes what states and moves are legal."
metadata:
  invocation: model
  kind: method
---

# Go Domain Invariant

A business rule is an **invariant**: a statement about state and transitions that stays true under every accepting path, replay, and version mix — or it is a wish, not a rule.

`accepted terms -> states and transitions -> acceptance conditions -> rejection surfaces -> effect order -> replay -> proof`

State each invariant in accepted business terms with the input, sequence, or
replay that falsifies it and the surface that rejects the attempt. The domain
owns effect order, duplicate meaning, and out-of-order meaning.

For a delegated Decision or Review, or when the active artifact requires its
result interface, load the
[shared specialist contract](../../contracts/specialist-contract.md).
When meaningful ordering, comparison, exhaustive accounting, or a required
decision/review handoff needs structured representation, trace each changed accepting path through its false case and replay in
`InvariantRecord{rule, owner, accepting_paths, transitions, false_case,
rejection, effect_order, replay, mixed_version, proof}`. A rule is incomplete
until every accepting path and invalid move has a disposition.
Otherwise, a single local path may retain its grounded invariant judgment and
proof for its false-case and replay disposition.

## Choose The Branch

- **Decision** — load one matching [decision reference](references/decision/index.md)
  and cover every invariant and transition with rejection, effect boundary,
  forced consequence, and proof obligation.
- **Review** — load one matching [review reference](references/review/index.md)
  and follow every affected accepting path into the finding envelope with
  falsifying proof.

Complete when every invariant is falsifiable in accepted business terms, every
invalid move has one deterministic rejection surface, and proof would fail if
an alternate accepting path bypassed the rule.

Files in this skill

  • SKILL.md2 KB
  • references/decision/idempotency-replay-and-async-domain-rules.md2.3 KB
  • references/decision/index.md1.6 KB
  • references/decision/invariant-register-patterns.md2.3 KB
  • references/decision/invariant-violation-semantics.md1.9 KB
  • references/decision/state-machine-and-transition-rules.md1.7 KB
  • references/review/acceptance-and-rejection-semantics.md2 KB
  • references/review/domain-test-traceability.md1.6 KB
  • references/review/effect-escape-and-duplication-review.md2.4 KB
  • references/review/index.md1.4 KB
  • references/review/invalid-state-and-transition-review.md1.9 KB

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…