Apply software design principles across architecture and implementation using deterministic decision workflows, SOLID checks, structural patterns, and anti-pattern detection; use when reviewing designs, refactoring modules, or resolving maintainability and coupling risks.
Does it follow best practices?
Evaluation — 99%
↑ 1.01xAgent success when using this tile
Validation for skill structure
Classes grouped into a component should be releasable together. A component should have a version number, release notes, and clear documentation. This is the Reuse/Release Equivalence Principle (REP).
Incorrect (arbitrary grouping):
shared-lib/
├── src/
│ ├── auth/
│ │ ├── JwtValidator.ts
│ │ └── PermissionChecker.ts
│ ├── logging/
│ │ └── Logger.ts
│ ├── email/
│ │ └── EmailSender.ts
│ └── payment/
│ └── StripeClient.ts
└── package.json // version 1.2.3
# Version 1.2.4 fixes JWT bug
# But users of EmailSender must also upgrade
# Changelog unclear which features affect which usersCorrect (cohesive releasable components):
packages/
├── auth/
│ ├── src/
│ │ ├── JwtValidator.ts
│ │ ├── PermissionChecker.ts
│ │ └── index.ts
│ ├── CHANGELOG.md # Auth-specific changes
│ └── package.json # @company/auth v2.1.0
├── logging/
│ ├── src/
│ │ └── Logger.ts
│ ├── CHANGELOG.md
│ └── package.json # @company/logging v1.0.3
├── email/
│ ├── src/
│ │ └── EmailSender.ts
│ ├── CHANGELOG.md
│ └── package.json # @company/email v1.5.0
└── payments/
├── src/
│ └── StripeClient.ts
├── CHANGELOG.md
└── package.json # @company/payments v3.0.0
# Clear ownership: auth team owns @company/auth
# Independent versioning: JWT fix only bumps auth
# Semantic versioning: breaking change in payments doesn't affect othersBenefits:
Reference: Clean Architecture - Reuse/Release Equivalence Principle
Install with Tessl CLI
npx tessl i pantheon-ai/software-design-principles@0.1.4evals
scenario-1
scenario-2
scenario-3
scenario-4
scenario-5
scenario-6
scenario-7
references