clean-code-principles — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited clean-code-principles (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Fundamental software design principles, SOLID, design patterns, and clean code practices. Language-agnostic guidelines for writing maintainable, scalable software.
Reference these guidelines when:
| 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- |
solid-srp - Single Responsibility Principlesolid-ocp - Open/Closed Principlesolid-lsp - Liskov Substitution Principlesolid-isp - Interface Segregation Principlesolid-dip - Dependency Inversion Principlecore-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 detailspattern-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 couplingorg-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 importsname-meaningful - Use intention-revealing namesname-consistent - Consistent naming conventionsname-searchable - Avoid magic numbers/stringsname-avoid-encodings - No Hungarian notationname-domain-language - Use domain terminologyfunc-small - Keep functions smallfunc-single-purpose - Do one thingfunc-few-arguments - Limit parametersfunc-no-side-effects - Minimize side effectsfunc-command-query - Separate commands and queriesdoc-self-documenting - Code should explain itselfdoc-why-not-what - Explain why, not whatdoc-avoid-noise - No redundant commentsdoc-api-docs - Document public APIsFor detailed examples and explanations, see the rule files:
| 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 |
| 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 |
// 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) { }When auditing code, output findings in this format:
file:line - [principle] Description of issueExample:
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 purposeRead individual rule files for detailed explanations:
rules/solid-srp-class.md
rules/core-dry.md
rules/pattern-repository.mdThis skill is built on established software engineering principles:
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
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.