clean-code_skill

Overview

This skill is the Foundation: an LLM firewall, 2025 security baseline, and cross-skill coordinator for all code output. It enforces runnable, secure, and minimal implementations while preventing hallucinated imports and lazy placeholders. Use it as the mandatory gate for every generated code artifact. It prioritizes readable, intent-revealing engineering over cleverness.

How this skill works

The skill inspects proposed code for four categories of violations: hallucinated or unverified dependencies, security shortcuts, placeholder or non-runnable implementations, and unnecessary complexity. It enforces production-safe defaults (sanitization, input validation, pinned deps, rate limiting) and rejects changes that break the 50/300 modularity rule. Where needed, it will decompose large functions into complete, testable helpers and require concrete dependency verification steps.

When to use it

• Every time an LLM generates code that will be run, deployed, or integrated.
• Before adding new dependencies or third-party SDKs to a project.
• When producing security-sensitive code: auth, data storage, input/output handling.
• During cross-skill composition to ensure consistent defaults and interfaces.
• When preparing code for production, CI/CD, or public endpoints.

Best practices

• Verify packages exist before importing; prefer battle-tested libraries and pin versions.
• Reject TODOs and placeholder functions — deliver runnable minimal implementations.
• Apply security-first defaults: sanitize outputs, validate inputs, use httpOnly cookies for tokens.
• Keep functions under 50 lines and files under 300 lines; break logic into small, single-responsibility units.
• Favor native solutions for trivial tasks and avoid premature abstraction (YAGNI).

Example use cases

• Generating a new API endpoint: enforce input validation, rate limiting, and origin whitelist.
• Adding AI features: validate LLM outputs, rate-limit calls, and sanitize content before display.
• Onboarding a third-party SDK: verify official source and run an audit before pinning.
• Refactoring a large module: split functions over 50 lines into small, testable helpers.
• Preparing frontend components: ban dangerouslySetInnerHTML and require DOMPurify sanitization.