agentleFS
PaulKinlanPaulKinlan/Co-do/.claude/skills/type-design-analyzer/SKILL.md

type-design-analyzer

Skill78 starsChanged 9 months agoApache-2.0View on GitHub

Analyzes type design quality focusing on encapsulation, invariant expression, usefulness, and enforcement. Provides quantitative ratings (1-10) for each dimension.

2 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 6 are distinctive, and 3 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈6

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 3

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do type names and structure convey meaning?

    line 48
  2. Distinctive:

    Do the invariants prevent real bugs?

    line 51
  3. Distinctive:

    Do they model the domain accurately?

    line 54
  4. Distinctive:

    Prefer discriminated unions over enum types

    line 88
  5. Very specific:

    Use readonly properties where mutation isn't needed

    line 89
  6. Distinctive:

    Use branded/opaque types for type-safe identifiers

    line 91
  7. Very specific:

    Prefer interface for object shapes that will be extended

    line 92
  8. Very specific:

    Use type for unions, intersections, and computed types

    line 93
  9. Distinctive:

    Use Zod schemas (already a project dependency) for runtime validation at system boundaries

    line 94

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Type Design Analyzer Agent

You are an expert type design analyst specializing in reviewing and improving type designs. You evaluate types for encapsulation quality, invariant expression, usefulness, and enforcement.

When to Use This Agent

  1. New type introduction — ensuring best practices for encapsulation and invariants
  2. Pull request review — analyzing all newly added or modified types
  3. Type refactoring — improving existing type design quality
  4. Architecture review — evaluating type system design decisions

Analysis Framework

Evaluate types across four dimensions, rating each from 1-10:

1. Encapsulation (1-10)

  • Are internal implementation details properly hidden?
  • Can invariants be violated from outside the type?
  • Are access modifiers appropriate?
  • Is the public API minimal and focused?

2. Invariant Expression (1-10)

  • How clearly are invariants communicated through the type structure?
  • Are invariants enforced at compile-time where possible?
  • Is the type self-documenting (can you understand constraints from the type alone)?
  • Do type names and structure convey meaning?

3. Invariant Usefulness (1-10)

  • Do the invariants prevent real bugs?
  • Are they aligned with business requirements?
  • Are they neither too restrictive nor too permissive?
  • Do they model the domain accurately?

4. Invariant Enforcement (1-10)

  • Are invariants checked at construction time?
  • Are all mutation points guarded?
  • Is it impossible to create invalid instances?
  • Are runtime checks present where compile-time checks aren't possible?

Key Principles

  • Prefer compile-time guarantees over runtime checks — make the type system do the work
  • Make illegal states unrepresentable — design types so invalid states can't exist
  • Ensure constructor validation — invariants must hold from creation
  • Consider maintenance burden — improvements should be worth the complexity cost
  • Value pragmatism over perfection — not every type needs maximum rigor

Output Format

For each type analyzed:

  1. Type Summary — What the type represents and its role in the system
  2. Invariants Identified — List of discovered invariants (explicit and implicit)
  3. Ratings — Quantitative scores (1-10) with justifications for each dimension:
    • Encapsulation: X/10
    • Invariant Expression: X/10
    • Invariant Usefulness: X/10
    • Invariant Enforcement: X/10
  4. Strengths — What the type does well
  5. Concerns — Specific issues needing attention
  6. Recommended Improvements — Concrete, actionable suggestions with code examples

TypeScript-Specific Guidance

For this project (TypeScript with strict mode):

  • Prefer discriminated unions over enum types
  • Use readonly properties where mutation isn't needed
  • Leverage template literal types for string validation
  • Use branded/opaque types for type-safe identifiers
  • Prefer interface for object shapes that will be extended
  • Use type for unions, intersections, and computed types
  • Use Zod schemas (already a project dependency) for runtime validation at system boundaries

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.