Review type invariants (prompt)

curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/review-type-invariants-prompt/raw' -o ~/'.claude/skills/review-type-invariants-prompt/SKILL.md' && curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/review-type-invariants-prompt/files/LICENSE.txt' -o ~/'.claude/skills/review-type-invariants-prompt/LICENSE.txt' && curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/review-type-invariants-prompt/files/NOTICE.txt' -o ~/'.claude/skills/review-type-invariants-prompt/NOTICE.txt'

curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/review-type-invariants-prompt/raw' -o '.cursor/skills/review-type-invariants-prompt/SKILL.md' && curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/review-type-invariants-prompt/files/LICENSE.txt' -o '.cursor/skills/review-type-invariants-prompt/LICENSE.txt' && curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/review-type-invariants-prompt/files/NOTICE.txt' -o '.cursor/skills/review-type-invariants-prompt/NOTICE.txt'

curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/review-type-invariants-prompt/raw' -o '.agents/skills/review-type-invariants-prompt/SKILL.md' && curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/review-type-invariants-prompt/files/LICENSE.txt' -o '.agents/skills/review-type-invariants-prompt/LICENSE.txt' && curl -fsSL --create-dirs 'https://theskillvault.ai/api/skills/review-type-invariants-prompt/files/NOTICE.txt' -o '.agents/skills/review-type-invariants-prompt/NOTICE.txt'

{
  "mcpServers": {
    "theskillvault": {
      "url": "https://theskillvault.ai/mcp"
    }
  }
}

Good types make bugs hard to write. If an order can be both "paid" and "refunded", or an email field can hold any string, the code has to guard against it everywhere. This prompt reviews each new type and asks how well it protects its own rules.

When to use

• You added a new type, class or domain model and want its design checked.
• A change adds several data types and you want them reviewed together.
• Bugs keep coming from objects in states that should not exist.

When not to use

• You want the words and names in your domain sorted out first. Use model-domain-and-glossary-prompt.
• You want database tables designed. Use design-postgres-tables.
• You want a broad review of a whole branch's structure. Use review-maintainability-strictly-prompt.

Steps

1. Commit your work, then open the branch in your AI coding tool.
2. Paste the prompt below. Change the base branch, or name the types to review.
3. Read the invariants list for each type first. Correct any rule the AI got wrong before reading the ratings.
4. Pick the improvements worth their cost. Prefer small ones such as a validating constructor or a union of states.
5. Add a test that tries to build an invalid value, then make the change and run the tests.

Prompt

Review the design of each type, class, interface or schema added or changed in this branch (git diff main...HEAD). Do not edit code yet.

For each type:
1. Invariants: list the rules it must always keep, such as field relationships, allowed values, valid state changes and pre and post conditions. Say which are enforced and which are only assumed.
2. Rate 1-10, with one line of reasons each:
   - Encapsulation: can outside code break the rules? Are internals hidden and the interface small?
   - Expression: are the rules visible in the type itself, ideally checked at compile time?
   - Usefulness: do the rules prevent real bugs and match the business need, without being too strict?
   - Enforcement: are rules checked on creation and on every change? Can an invalid value be built?
3. Flag: exposed mutable internals; rules kept only in comments; no validation at construction; some mutators checking rules and others not; types doing too many jobs; plain data bags where behaviour belongs with the data; booleans or optional fields that allow impossible combinations.

Prefer compile-time guarantees, immutability and making invalid states impossible to represent. Weigh each suggestion against the complexity and breaking changes it adds; a simpler type can be the better answer.
Output per type: invariants; four ratings with reasons; strengths; concerns; up to three recommended changes, smallest first, with a short code sketch.

How to adapt

• Not TypeScript? Name your language. In Python ask for dataclasses or Pydantic, in Rust for enums and newtypes.
• Types come from an API or database schema? Ask it to check where the data is parsed and validated at the boundary.
• Reviewing existing code? Replace the diff with "the types in src/orders/".
• Team prefers plain data and functions over classes? Say so, and it will suggest constructors and unions instead.

Gotchas

• Ratings are opinions, not measurements. Use them to compare types, not as a target score.
• Stricter types can break callers. Check who uses a type before you change it.
• Types for secrets, such as API keys or tokens, should not print their value in logs or toString output.

Portability

Works with any typed language and any AI coding tool or chat AI. In a chat without repo access, paste the type definitions and the code that creates them.

Done when

• Each new type has its invariants written down and checked by someone who knows the domain.
• Accepted changes have a test showing an invalid value is now rejected or cannot be built.
• No accepted change added more complexity than the bugs it prevents.

Example prompt

"Review the new types in my branch. List the rules each must keep, rate encapsulation, expression, usefulness and enforcement 1 to 10, and suggest the smallest changes that make invalid states impossible."

---

Modified from the "type-design-analyzer" agent in anthropics/claude-plugins-official (pr-review-toolkit, by Anthropic; README credits Daisy). Licensed Apache-2.0 per the LICENSE file at commit a7ba5b9. Original: https://github.com/anthropics/claude-plugins-official/blob/a7ba5b93db0c7c8d17f3f1d25853adca79598a1a/plugins/pr-review-toolkit/agents/type-design-analyzer.md. Changes by TheSkillVault are listed in the metadata above and in NOTICE.txt. See LICENSE.txt.

Bundled files

• LICENSE.txt
• NOTICE.txt

Licence

Adapted from Anthropic (anthropics/claude-plugins-official, pr-review-toolkit, type-design-analyzer; the plugin README credits Daisy, daisy@anthropic.com) (Anthropic (the upstream LICENSE keeps the blank Apache template line 'Copyright [yyyy] [name of copyright owner]'; no other copyright notice at this commit). Apache License 2.0 text in LICENSE.txt, attributions in NOTICE.txt), Apache License 2.0. Modified by TheSkillVault on 2026-11-04: the persona and the Claude Code invocation notes were removed; the four rating axes and the anti-pattern list were rewritten as one copy-paste prompt with a fixed per-type template, a complexity-cost check and a test-first rule for changes; added steps, adapt notes, gotchas and done-when. Not the original file.

Licence: Apache License 2.0. Attribution when you reuse it: Based on work by Anthropic (anthropics/claude-plugins-official, pr-review-toolkit, type-design-analyzer; the plugin README credits Daisy, daisy@anthropic.com) (Anthropic (the upstream LICENSE keeps the blank Apache template line 'Copyright [yyyy] [name of copyright owner]'; no other copyright notice at this commit). Apache License 2.0 text in LICENSE.txt, attributions in NOTICE.txt, Apache License 2.0), https://github.com/anthropics/claude-plugins-official/blob/a7ba5b93db0c7c8d17f3f1d25853adca79598a1a/plugins/pr-review-toolkit/agents/type-design-analyzer.md; adapted by TheSkillVault, https://theskillvault.ai