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
- euxx/claude-skills-for-copilottheir own version, first seen Nov 8, 2026
- neronain/ClaudeSkills-Neronainedited, first seen Aug 9, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- neronain/ClaudeSkills-Neronain★ 310% same
Wrote their own version · 1
- euxx/claude-skills-for-copilot★ 4same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository9 other files it gives its agents.
- CLAUDE.mdCLAUDE.md
- agent-reviewsSkill
- code-reviewerSkill
- code-simplifierSkill
- comment-analyzerSkill
- fix-pr-commentsSkill
- moder-web-devSkill
- pr-test-analyzerSkill
- silent-failure-hunterSkill
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
- Distinctive: line 48
Do type names and structure convey meaning?
- Distinctive: line 51
Do the invariants prevent real bugs?
- Distinctive: line 54
Do they model the domain accurately?
- Distinctive: line 88
Prefer discriminated unions over enum types
- Very specific: line 89
Use readonly properties where mutation isn't needed
- Distinctive: line 91
Use branded/opaque types for type-safe identifiers
- Very specific: line 92
Prefer interface for object shapes that will be extended
- Very specific: line 93
Use type for unions, intersections, and computed types
- Distinctive: line 94
Use Zod schemas (already a project dependency) for runtime validation at system boundaries
≈ “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.
Files
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
- New type introduction — ensuring best practices for encapsulation and invariants
- Pull request review — analyzing all newly added or modified types
- Type refactoring — improving existing type design quality
- 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:
- Type Summary — What the type represents and its role in the system
- Invariants Identified — List of discovered invariants (explicit and implicit)
- 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
- Strengths — What the type does well
- Concerns — Specific issues needing attention
- 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
readonlyproperties where mutation isn't needed - Leverage template literal types for string validation
- Use branded/opaque types for type-safe identifiers
- Prefer
interfacefor object shapes that will be extended - Use
typefor unions, intersections, and computed types - Use Zod schemas (already a project dependency) for runtime validation at system boundaries
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
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.

