design-principles

Applies DRY, KISS, YAGNI, SOLID, and GoF patterns as a review lens during planning and code review.

Updated May 21, 2026
One-click install
npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill design-principles-cagesthrottleus
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: design-principles
Source: https://github.com/CagesThrottleUs/private-ai-harness/tree/main/skills/design-principles
Command: npx skills add https://github.com/CagesThrottleUs/private-ai-harness --skill design-principles-cagesthrottleus

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Codebases accumulate design debt when principles like DRY, SOLID, and separation of concerns are applied inconsistently or only remembered after problems surface. This Skill enforces a mandatory design lens during planning, implementation, and review so violations are caught before they ship. ## Core Features & Use Cases - Principle Enforcement: Covers DRY, KISS, YAGNI, SoC, loose coupling, high cohesion, Law of Demeter, CQS, composition over inheritance, Fail Fast, POLA, and full SOLID with violation/fix tables and test questions for each. - GoF Pattern Guidance: Maps code smells (god class, telescoping constructor, switch-on-type) to the correct creational, structural, or behavioral pattern, including confused-pair comparisons and pattern evolution triggers. - Planning & Review Checklists: Provides runnable checklists that integrate with plan-writing, plan-execution, and code-review workflows, plus conflict-resolution rules (e.g., DRY vs YAGNI decided by the Rule of Three). - Use Case: While reviewing a pull request, run the Review Checklist to catch a method that both mutates state and returns data (CQS violation), a subclass breaking its base contract (LSP), or a new ad-hoc branch bolted onto an unrelated flow. ## Quick Start Ask the AI to apply design-principles to review the current module's class structure and flag any SOLID or coupling violations.

Frequently Asked Questions about design-principles

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I apply SOLID principles during code review?

Run the Review Checklist against the changed code: verify each class has one reason to change (SRP), subtypes satisfy base contracts without instanceof checks (LSP), no implementor stubs interface methods (ISP), and dependencies are injected through interfaces rather than constructed inline (DIP).

When should I use a design pattern versus plain code?

Apply a GoF pattern only when a concrete smell exists: a giant switch on type maps to Strategy or State, a telescoping constructor maps to Builder, and notification spaghetti maps to Observer. YAGNI applies to patterns too — never add one without a documented need.

How do I resolve conflicts between DRY and YAGNI?

Use the Rule of Three: duplicate logic once is fine, twice is coincidence, and extraction happens at the third occurrence. YAGNI wins until then, and readability wins over DRY when an abstraction would obscure two simple identical blocks.

What is the difference between Strategy and State patterns?

Strategy implementations are independent and unaware of each other, swapped by the client per context. State implementations may trigger transitions between each other based on the object's internal state. Both replace if/else chains but solve different coordination problems.

When should I not split code into smaller modules?

Avoid splitting when the resulting modules are shallow — interfaces nearly as complex as what they hide — or when the real behavior lives in the composing glue that becomes untested. Prefer deep modules that hide substantial implementation behind simple interfaces.