PluginBench
Skill
Review
Audit score 70

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-principles
Claude Code
Cursor
Windsurf
Cline

How to use clean-code-principles

  1. 1.Trigger the skill with keywords: 'review architecture', 'check code quality', 'SOLID principles', 'design patterns', or 'clean code'
  2. 2.Reference the rule categories by priority: SOLID (critical), Core Principles (critical), Design Patterns (high), Code Organization (high)
  3. 3.Read individual rule files for detailed explanations and code examples
  4. 4.Use the output format to document findings: file:line - [principle] description
  5. 5.Apply the quick examples (TypeScript) to your codebase as templates

Use cases

Good for
  • 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
Who it's for
  • 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

What's the difference between SOLID and core principles?

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.

Can I use this for non-object-oriented languages?

Yes. While SOLID examples use OOP terminology, the underlying concepts (single responsibility, composition, abstraction) apply to functional and procedural code too.

How do I know which principle to apply first?

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).

Are all 23 rules fully implemented?

Currently 3 categories are implemented (SOLID, Core Principles, Design Patterns with 1 rule). Code Organization, Naming & Readability, and Functions & Methods are planned.

What if my code violates multiple principles?

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

PriorityCategoryImpactPrefix
1SOLID PrinciplesCRITICALsolid-
2Core PrinciplesCRITICALcore-
3Design PatternsHIGHpattern-
4Code OrganizationHIGHorg-
5Naming & ReadabilityMEDIUMname-
6Functions & MethodsMEDIUMfunc-
7Comments & DocumentationLOWdoc-

Quick Reference

1. SOLID Principles (CRITICAL)

  • solid-srp - Single Responsibility Principle
  • solid-ocp - Open/Closed Principle
  • solid-lsp - Liskov Substitution Principle
  • solid-isp - Interface Segregation Principle
  • solid-dip - Dependency Inversion Principle

2. Core Principles (CRITICAL)

  • core-dry - Don't Repeat Yourself
  • core-kiss - Keep It Simple, Stupid
  • core-yagni - You Aren't Gonna Need It
  • core-separation-of-concerns - Separate different responsibilities
  • core-composition-over-inheritance - Favor composition
  • core-law-of-demeter - Principle of least knowledge
  • core-fail-fast - Detect and report errors early
  • core-encapsulation - Hide implementation details

3. Design Patterns (HIGH)

  • pattern-factory - Factory pattern for object creation
  • pattern-strategy - Strategy pattern for algorithms
  • pattern-repository - Repository pattern for data access
  • pattern-decorator - Decorator pattern for behavior extension
  • pattern-observer - Observer pattern for event handling
  • pattern-adapter - Adapter pattern for interface conversion
  • pattern-facade - Facade pattern for simplified interfaces
  • pattern-dependency-injection - DI for loose coupling

4. Code Organization (HIGH) — planned

  • org-feature-folders - Organize by feature, not layer
  • org-module-boundaries - Clear module boundaries
  • org-layered-architecture - Proper layer separation
  • org-package-cohesion - Related code together
  • org-circular-dependencies - Avoid circular imports

5. Naming & Readability (MEDIUM) — planned

  • name-meaningful - Use intention-revealing names
  • name-consistent - Consistent naming conventions
  • name-searchable - Avoid magic numbers/strings
  • name-avoid-encodings - No Hungarian notation
  • name-domain-language - Use domain terminology

6. Functions & Methods (MEDIUM) — planned

  • func-small - Keep functions small
  • func-single-purpose - Do one thing
  • func-few-arguments - Limit parameters
  • func-no-side-effects - Minimize side effects
  • func-command-query - Separate commands and queries

7. Comments & Documentation (LOW) — planned

  • doc-self-documenting - Code should explain itself
  • doc-why-not-what - Explain why, not what
  • doc-avoid-noise - No redundant comments
  • doc-api-docs - Document public APIs

Essential Guidelines

For detailed examples and explanations, see the rule files:

SOLID Principles (Summary)

PrincipleDefinition
Single ResponsibilityA class should have only one reason to change
Open/ClosedOpen for extension, closed for modification
Liskov SubstitutionSubtypes must be substitutable for base types
Interface SegregationDon't force clients to depend on unused interfaces
Dependency InversionDepend on abstractions, not concretions

Core Principles (Summary)

PrincipleDefinition
DRYDon't Repeat Yourself - single source of truth
KISSKeep It Simple - avoid over-engineering
YAGNIYou 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

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