How do I install the Principles skill?

Run npx skillmds@latest add tomevault-io/principles in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Principles safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Principles?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Principles free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Principles?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Principles by tomevault-io — Agent Skill

Name: Principles
Author: tomevault-io

Principles

Apply SOLID, KISS, DRY, YAGNI principles to code design decisions. Use when building new features from scratch and need to decide on class structure, interface boundaries, or dependency direction. Make sure to use this skill when the user faces design trade-offs, asks about SOLID principles, debates whether to abstract or keep things simple, or needs to evaluate competing design approaches — but not for code smell detection (use refactoring skill instead). Use when this capability is needed.

tomevault-io ff65b94 2 files · 4.2 KB Updated Sep 17, 2026

File contents

Related Skills

Detected a code smell (long method, feature envy)? → Use refactoring for specific techniques
Need a specific pattern (Strategy, Factory)? → Use design-patterns for selection and implementation
Deciding which architectural layer code belongs in? → Use clean-architecture

Applicability Rubric

Condition	Pass	Fail
New feature from scratch	Building without existing reference	Modifying existing code
Design trade-off	Choosing between competing approaches	Implementation path is clear
Interface/boundary design	Defining class responsibilities or contracts	Internal implementation detail
Dependency structure	Deciding coupling and injection strategy	No dependency decisions

Apply when: Any condition passes Do NOT apply when: The task is purely about restructuring existing code (use refactoring) or detecting code smells (use refactoring)

Core Principles

SOLID

Principle	Description	Violation Sign
Single Responsibility	One reason to change	Class does too many things
Open/Closed	Open for extension, closed for modification	Frequent changes to existing code
Liskov Substitution	Subtypes must be substitutable	Type checks or conditional logic on types
Interface Segregation	Many specific interfaces over one general	Clients implement unused methods
Dependency Inversion	Depend on abstractions, not concretions	Direct instantiation of dependencies

KISS (Keep It Simple, Stupid)

Prefer straightforward solutions
Avoid unnecessary complexity
Write code that's easy to understand
If it's hard to explain, it's too complex

DRY (Don't Repeat Yourself)

Extract repeated logic into functions
BUT: Premature abstraction is worse than duplication
Rule of three: Abstract after third repetition
Accept some duplication for clarity

YAGNI (You Aren't Gonna Need It)

Don't build features until needed
Avoid speculative generality
Solve today's problem, not tomorrow's

Completion Rubric

Use the Violation Sign column in the SOLID table above as the primary checklist. Additionally verify:

Criterion	Pass	Fail
Describable	Each class/function describable in one sentence	Needs a paragraph to explain
Simplest solution	Chosen approach is the simplest that works	Over-engineered for hypothetical needs
Dependencies injected	High-level modules depend on abstractions	Direct instantiation of concretions

Scope Boundary

This skill addresses design-level decisions (abstraction level, coupling, interface shape). For code-level restructuring (long methods, duplicated code, feature envy), use the refactoring skill — it has specific techniques and safe steps for each smell.

Converted and distributed by TomeVault — claim your Tome and manage your conversions.

---name: principlesdescription: Apply SOLID, KISS, DRY, YAGNI principles to code design decisions. Use when building new features from scratch and need to decide on class structure, interface boundaries, or dependency direction. Make sure to use this skill when the user faces design trade-offs, asks about SOLID principles, debates whether to abstract or keep things simple, or needs to evaluate competing design approaches — but not for code smell detection (use refactoring skill instead). Use when this capability is needed.---## Related Skills- Detected a code smell (long method, feature envy)? → Use **refactoring** for specific techniques- Need a specific pattern (Strategy, Factory)? → Use **design-patterns** for selection and implementation- Deciding which architectural layer code belongs in? → Use **clean-architecture**## Applicability Rubric| Condition | Pass | Fail ||-----------|------|------|| New feature from scratch | Building without existing reference | Modifying existing code || Design trade-off | Choosing between competing approaches | Implementation path is clear || Interface/boundary design | Defining class responsibilities or contracts | Internal implementation detail || Dependency structure | Deciding coupling and injection strategy | No dependency decisions |**Apply when**: Any condition passes**Do NOT apply when**: The task is purely about restructuring existing code (use refactoring) or detecting code smells (use refactoring)## Core Principles### SOLID| Principle | Description | Violation Sign ||-----------|-------------|----------------|| **S**ingle Responsibility | One reason to change | Class does too many things || **O**pen/Closed | Open for extension, closed for modification | Frequent changes to existing code || **L**iskov Substitution | Subtypes must be substitutable | Type checks or conditional logic on types || **I**nterface Segregation | Many specific interfaces over one general | Clients implement unused methods || **D**ependency Inversion | Depend on abstractions, not concretions | Direct instantiation of dependencies |### KISS (Keep It Simple, Stupid)- Prefer straightforward solutions- Avoid unnecessary complexity- Write code that's easy to understand- If it's hard to explain, it's too complex### DRY (Don't Repeat Yourself)- Extract repeated logic into functions- BUT: Premature abstraction is worse than duplication- Rule of three: Abstract after third repetition- Accept some duplication for clarity### YAGNI (You Aren't Gonna Need It)- Don't build features until needed- Avoid speculative generality- Solve today's problem, not tomorrow's## Completion RubricUse the **Violation Sign** column in the SOLID table above as the primary checklist. Additionally verify:| Criterion | Pass | Fail ||-----------|------|------|| Describable | Each class/function describable in one sentence | Needs a paragraph to explain || Simplest solution | Chosen approach is the simplest that works | Over-engineered for hypothetical needs || Dependencies injected | High-level modules depend on abstractions | Direct instantiation of concretions |## Scope BoundaryThis skill addresses **design-level decisions** (abstraction level, coupling, interface shape). For **code-level restructuring** (long methods, duplicated code, feature envy), use the **refactoring** skill — it has specific techniques and safe steps for each smell.---> Converted and distributed by [TomeVault](https://tomevault.io/claim/elct9620) — claim your Tome and manage your conversions.

Frequently asked questions