CtrlK
BlogDocsLog inGet started
Tessl Logo

pantheon-ai/software-design-principles

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.

Review — 93%

Does it follow best practices?

Evaluation — 99%

↑ 1.01x

Agent success when using this tile

Validation — 11 / 11 Passed

Validation for skill structure

Overview
Skills
Evals
Files

comp-common-closure.mdreferences/

title:
Group Classes That Change Together
impact:
HIGH
impactDescription:
localizes change impact, reduces deployment risk
tags:
comp, common-closure, cohesion, change

Group Classes That Change Together

Classes that change for the same reasons and at the same times should be in the same component. This is the Common Closure Principle (CCP) - the Single Responsibility Principle for components.

Incorrect (classes that change together are separated):

src/
├── entities/
│   └── Invoice.ts           # Changes when billing rules change
├── repositories/
│   └── InvoiceRepository.ts # Changes when billing rules change
├── services/
│   └── InvoiceService.ts    # Changes when billing rules change
├── validators/
│   └── InvoiceValidator.ts  # Changes when billing rules change
└── mappers/
    └── InvoiceMapper.ts     # Changes when billing rules change

# A billing rule change touches 5 directories
# Risk of forgetting one, inconsistent changes

Correct (classes that change together are grouped):

src/
├── billing/
│   ├── domain/
│   │   ├── Invoice.ts
│   │   ├── InvoiceLine.ts
│   │   ├── InvoiceRules.ts
│   │   └── InvoiceValidator.ts
│   ├── application/
│   │   ├── CreateInvoiceUseCase.ts
│   │   └── ports/
│   │       └── InvoiceRepository.ts
│   └── infrastructure/
│       ├── PostgresInvoiceRepository.ts
│       └── InvoiceMapper.ts
├── payments/
│   └── ...  # Changes for different reasons
└── shipping/
    └── ...  # Changes for different reasons

# Billing rule change isolated to billing/
# Single PR, single review, single deployment

How to identify change reasons:

  • "When X business rule changes, which classes change?"
  • "When the Y team requests a feature, which code changes?"
  • Group by actor/stakeholder, not by technical layer

Reference: Clean Architecture - Common Closure Principle

Install with Tessl CLI

npx tessl i pantheon-ai/software-design-principles

references

adapt-anti-corruption-layer.md

adapt-controller-thin.md

adapt-gateway-abstraction.md

adapt-mapper-translation.md

adapt-presenter-formats.md

anti-patterns-and-frameworks.md

bound-boundary-cost-awareness.md

bound-defer-decisions.md

bound-humble-object.md

bound-main-component.md

bound-partial-boundaries.md

bound-service-internal-architecture.md

comp-common-closure.md

comp-common-reuse.md

comp-reuse-release-equivalence.md

comp-screaming-architecture.md

comp-stable-dependencies.md

dep-acyclic-dependencies.md

dep-data-crossing-boundaries.md

dep-interface-ownership.md

dep-inward-only.md

dep-no-framework-imports.md

dep-stable-abstractions.md

detailed-examples.md

entity-encapsulate-invariants.md

entity-no-persistence-awareness.md

entity-pure-business-rules.md

entity-rich-not-anemic.md

entity-value-objects.md

frame-di-container-edge.md

frame-domain-purity.md

frame-logging-abstraction.md

frame-orm-in-infrastructure.md

frame-web-in-infrastructure.md

test-boundary-verification.md

test-layer-isolation.md

test-testable-design.md

test-tests-are-architecture.md

usecase-explicit-dependencies.md

usecase-input-output-ports.md

usecase-no-presentation-logic.md

usecase-orchestrates-not-implements.md

usecase-single-responsibility.md

usecase-transaction-boundary.md

SKILL-FULL.md

SKILL.md

tile.json