clean-code-principles
asyrafhussin/agent-skills
SOLID principles, design patterns, and clean code fundamentals for architecture review and refactoring.
What is clean-code-principles?
A language-agnostic reference for writing maintainable, scalable software. Covers SOLID principles, core practices (DRY, KISS, YAGNI), design patterns, and code organization. Use when reviewing architecture, refactoring code, or discussing design decisions.
- Apply SOLID principles (Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion)
- Reference core principles: DRY, KISS, YAGNI, separation of concerns, composition over inheritance
- Identify design patterns (Factory, Strategy, Repository, Decorator, Observer, Adapter, Facade, Dependency Injection)
- Audit code against 23+ rules organized by priority and impact level
- Output findings in standardized format with file, line, principle, and description
How to install clean-code-principles
npx skills add https://github.com/asyrafhussin/agent-skills --skill clean-code-principlesHow to use clean-code-principles
- 1.Trigger the skill with keywords: 'review architecture', 'check code quality', 'SOLID principles', 'design patterns', or 'clean code'
- 2.Reference the rule categories by priority: SOLID (critical), Core Principles (critical), Design Patterns (high), Code Organization (high)
- 3.Read individual rule files for detailed explanations and code examples
- 4.Use the output format to document findings: file:line - [principle] description
- 5.Apply the quick examples (TypeScript) to your codebase as templates
Use cases
- Review code architecture for SOLID violations and suggest refactoring
- Check code quality during pull request reviews using principle-based criteria
- Design new features or systems with established patterns and best practices
- Refactor legacy code by identifying DRY violations and separation-of-concerns issues
- Discuss design decisions with team using shared principle vocabulary
- Software architects and senior engineers
- Code reviewers and quality assurance leads
- Full-stack and backend developers refactoring systems
- Teams establishing coding standards and design guidelines
clean-code-principles FAQ
SOLID principles (5 rules) focus on class design and object-oriented structure. Core principles (DRY, KISS, YAGNI, etc.) are broader practices applicable across any codebase. Both are marked CRITICAL priority.
Yes. While SOLID examples use OOP terminology, the underlying concepts (single responsibility, composition, abstraction) apply to functional and procedural code too.
Follow the priority table: start with SOLID Principles and Core Principles (CRITICAL impact), then Design Patterns and Code Organization (HIGH), then Naming and Functions (MEDIUM).
Currently 3 categories are implemented (SOLID, Core Principles, Design Patterns with 1 rule). Code Organization, Naming & Readability, and Functions & Methods are planned.
Prioritize by impact: fix CRITICAL violations first (SOLID, DRY, KISS), then HIGH (patterns, organization), then MEDIUM and LOW. Refactor incrementally.
Full instructions (SKILL.md)
Source of truth, from asyrafhussin/agent-skills.
name: clean-code-principles description: SOLID principles, design patterns, DRY, KISS, and clean code fundamentals. Use when reviewing architecture, checking code quality, refactoring, or discussing design decisions. Triggers on "review architecture", "check code quality", "SOLID principles", "design patterns", or "clean code". license: MIT metadata: author: AsyrafHussin version: "1.0.2"
Clean Code Principles
Fundamental software design principles, SOLID, design patterns, and clean code practices. Language-agnostic guidelines for writing maintainable, scalable software.
When to Apply
Reference these guidelines when:
- Designing new features or systems
- Reviewing code architecture
- Refactoring existing code
- Discussing design decisions
- Improving code quality
Rule Categories by Priority
| Priority | Category | Impact | Prefix |
|---|---|---|---|
| 1 | SOLID Principles | CRITICAL | solid- |
| 2 | Core Principles | CRITICAL | core- |
| 3 | Design Patterns | HIGH | pattern- |
| 4 | Code Organization | HIGH | org- |
| 5 | Naming & Readability | MEDIUM | name- |
| 6 | Functions & Methods | MEDIUM | func- |
| 7 | Comments & Documentation | LOW | doc- |
Quick Reference
1. SOLID Principles (CRITICAL)
solid-srp- Single Responsibility Principlesolid-ocp- Open/Closed Principlesolid-lsp- Liskov Substitution Principlesolid-isp- Interface Segregation Principlesolid-dip- Dependency Inversion Principle
2. Core Principles (CRITICAL)
core-dry- Don't Repeat Yourselfcore-kiss- Keep It Simple, Stupidcore-yagni- You Aren't Gonna Need Itcore-separation-of-concerns- Separate different responsibilitiescore-composition-over-inheritance- Favor compositioncore-law-of-demeter- Principle of least knowledgecore-fail-fast- Detect and report errors earlycore-encapsulation- Hide implementation details
3. Design Patterns (HIGH)
pattern-factory- Factory pattern for object creationpattern-strategy- Strategy pattern for algorithmspattern-repository- Repository pattern for data accesspattern-decorator- Decorator pattern for behavior extensionpattern-observer- Observer pattern for event handlingpattern-adapter- Adapter pattern for interface conversionpattern-facade- Facade pattern for simplified interfacespattern-dependency-injection- DI for loose coupling
4. Code Organization (HIGH) — planned
org-feature-folders- Organize by feature, not layerorg-module-boundaries- Clear module boundariesorg-layered-architecture- Proper layer separationorg-package-cohesion- Related code togetherorg-circular-dependencies- Avoid circular imports
5. Naming & Readability (MEDIUM) — planned
name-meaningful- Use intention-revealing namesname-consistent- Consistent naming conventionsname-searchable- Avoid magic numbers/stringsname-avoid-encodings- No Hungarian notationname-domain-language- Use domain terminology
6. Functions & Methods (MEDIUM) — planned
func-small- Keep functions smallfunc-single-purpose- Do one thingfunc-few-arguments- Limit parametersfunc-no-side-effects- Minimize side effectsfunc-command-query- Separate commands and queries
7. Comments & Documentation (LOW) — planned
doc-self-documenting- Code should explain itselfdoc-why-not-what- Explain why, not whatdoc-avoid-noise- No redundant commentsdoc-api-docs- Document public APIs
Essential Guidelines
For detailed examples and explanations, see the rule files:
- core-dry.md - Don't Repeat Yourself principle
- pattern-repository.md - Repository pattern for data access
SOLID Principles (Summary)
| Principle | Definition |
|---|---|
| Single Responsibility | A class should have only one reason to change |
| Open/Closed | Open for extension, closed for modification |
| Liskov Substitution | Subtypes must be substitutable for base types |
| Interface Segregation | Don't force clients to depend on unused interfaces |
| Dependency Inversion | Depend on abstractions, not concretions |
Core Principles (Summary)
| Principle | Definition |
|---|---|
| DRY | Don't Repeat Yourself - single source of truth |
| KISS | Keep It Simple - avoid over-engineering |
| YAGNI | You Aren't Gonna Need It - build only what's needed |
Quick Examples
// Single Responsibility - one class, one job
class UserService {
constructor(
private validator: UserValidator,
private repository: UserRepository,
) {}
createUser(data) {
this.validator.validate(data);
return this.repository.create(data);
}
}
// Dependency Inversion - depend on abstractions
interface Repository<T> {
find(id: string): Promise<T | null>;
save(entity: T): Promise<T>;
}
class OrderService {
constructor(private repository: Repository<Order>) {}
}
// DRY - single source of truth
const EMAIL_REGEX = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
const isValidEmail = (email: string) => EMAIL_REGEX.test(email);
// Meaningful names over magic numbers
const MINIMUM_AGE = 18;
if (user.age >= MINIMUM_AGE) { }
Output Format
When auditing code, output findings in this format:
file:line - [principle] Description of issue
Example:
src/services/UserService.ts:15 - [solid-srp] Class handles validation, persistence, and notifications
src/utils/helpers.ts:42 - [core-dry] Email validation duplicated from validators/email.ts
src/models/Order.ts:28 - [name-meaningful] Variable 'x' should describe its purpose
How to Use
Read individual rule files for detailed explanations:
rules/solid-srp-class.md
rules/core-dry.md
rules/pattern-repository.md
References
This skill is built on established software engineering principles:
Core Books
- Clean Code by Robert C. Martin - Foundation for clean code practices
- Design Patterns by Gang of Four - Classic design pattern catalog
- Refactoring by Martin Fowler - Improving code structure
- The Pragmatic Programmer by Hunt & Thomas - Practical wisdom
Online Resources
- Refactoring Guru - Design patterns and code smells
- Martin Fowler's Refactoring Catalog - Comprehensive refactoring techniques
- Uncle Bob's Clean Coder Blog - Software craftsmanship articles
Pattern Catalogs
Metadata
Version: 1.0.2 Status: Active Coverage: 23 rules across 3 implemented categories (SOLID, Core Principles, Design Patterns); 4 planned Last Updated: 2026-03-07
Rule Statistics
- SOLID Principles: 10 rules
- Core Principles: 12 rules
- Design Patterns: 1 rule
Related skills
More from asyrafhussin/agent-skills and the wider catalog.

laravel-best-practices
Laravel 13 conventions and best practices for scalable, maintainable applications.

laravel-inertia-react
Laravel + Inertia.js + React integration patterns for full-stack monolithic applications.

php-best-practices
PHP 8.x modern patterns, PSR standards, and SOLID principles for code review and quality audits.

react-vite-best-practices
23 React + Vite performance optimization rules for build, code splitting, and bundle efficiency.
atxp
Agent wallet, identity, and paid tools—register, fund via Stripe/USDC, access 100+ LLM models and paid APIs.
atxp-memory
Agent memory management — cloud backup, restore, and local vector search of .md memory files