asyrafhussin/agent-skills

clean-code-principles

SOLID principles, design patterns, DRY, KISS, and clean code fundamentals.

Zobacz źródło

Jak używać

  1. Skopiuj polecenie instalacji i sprawdź źródła przed instalacją we własnym środowisku agenta.
  2. W oryginale sprawdź wymagane narzędzia, dane dostępowe i obsługiwane środowiska.
  3. Opisz dane wejściowe i oczekiwany rezultat; porównaj wynik ze źródłami.
npx skills add https://github.com/asyrafhussin/agent-skills --skill clean-code-principles

Przed rozpoczęciem

  • Instalacja nie obejmuje subskrypcji modelu, limitu API ani uprawnień do plików.
  • Gwiazdki i instalacje pokazują aktywność, a nie niezależny test jakości lub bezpieczeństwa.
Oryginalny dokument Skill

Treść z repozytorium z zachowaniem nagłówków, przykładów, kodu, tabel, linków i obrazów.

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

typescript
// 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

Powiązane zadania

z tego samego repozytorium

Więcej Skills

Wszystkie Skills
asyrafhussin
Społeczność

laravel-inertia-react

Laravel + Inertia.js + React integration patterns. Use when building Inertia page components, handling forms with useForm, managing shared data, or implementing persistent layouts. Triggers on tasks involving Inertia.js, page props, form handling, or Laravel React integration.

instalacje
2
GitHub Stars
90
Aktualizacja
27 sie
asyrafhussin
Społeczność

react-vite-best-practices

React and Vite performance optimization guidelines. Use when writing, reviewing, or optimizing React components built with Vite. Triggers on tasks involving Vite configuration, build optimization, code splitting, lazy loading, HMR, bundle size, or React performance.

instalacje
1
GitHub Stars
90
Aktualizacja
27 sie
asyrafhussin
Społeczność

code-slop

Detect AI-generated code patterns ("slop") in PHP/Laravel and TypeScript/React source — comment narration, generic naming, premature interfaces, defensive overdose, mock-everything tests, and the absence of human "scars". Use when reviewing AI-assisted PRs, auditing code for taste/quality (not metrics — that's technical-debt), or hardening a code-review checklist. Triggers on "review for AI slop", "find AI patterns", "check code feels human", "audit code-quality taste".

instalacje
2
GitHub Stars
89
Aktualizacja
27 sie
asyrafhussin
Społeczność

technical-debt

Technical debt inventory, prioritization, and audit for PHP/Laravel (MySQL) and Node/TypeScript/React projects. Use when assessing code health, identifying refactoring candidates, planning debt paydown, or auditing a codebase for accumulated debt. Triggers on "audit technical debt", "find tech debt", "debt inventory", "what should we refactor first", or tasks involving code health, security debt, performance debt, data debt, observability debt, debt prioritization, or remediation planning.

instalacje
2
GitHub Stars
89
Aktualizacja
27 sie