home / skills / vudovn / antigravity-kit / clean-code

This skill enforces pragmatic clean-code principles in TypeScript, delivering concise, maintainable, and scalable solutions with minimal boilerplate.

npx playbooks add skill vudovn/antigravity-kit --skill clean-code

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
6.5 KB
---
name: clean-code
description: Pragmatic coding standards - concise, direct, no over-engineering, no unnecessary comments
allowed-tools: Read, Write, Edit
version: 2.0
priority: CRITICAL
---

# Clean Code - Pragmatic AI Coding Standards

> **CRITICAL SKILL** - Be **concise, direct, and solution-focused**.

---

## Core Principles

| Principle | Rule |
|-----------|------|
| **SRP** | Single Responsibility - each function/class does ONE thing |
| **DRY** | Don't Repeat Yourself - extract duplicates, reuse |
| **KISS** | Keep It Simple - simplest solution that works |
| **YAGNI** | You Aren't Gonna Need It - don't build unused features |
| **Boy Scout** | Leave code cleaner than you found it |

---

## Naming Rules

| Element | Convention |
|---------|------------|
| **Variables** | Reveal intent: `userCount` not `n` |
| **Functions** | Verb + noun: `getUserById()` not `user()` |
| **Booleans** | Question form: `isActive`, `hasPermission`, `canEdit` |
| **Constants** | SCREAMING_SNAKE: `MAX_RETRY_COUNT` |

> **Rule:** If you need a comment to explain a name, rename it.

---

## Function Rules

| Rule | Description |
|------|-------------|
| **Small** | Max 20 lines, ideally 5-10 |
| **One Thing** | Does one thing, does it well |
| **One Level** | One level of abstraction per function |
| **Few Args** | Max 3 arguments, prefer 0-2 |
| **No Side Effects** | Don't mutate inputs unexpectedly |

---

## Code Structure

| Pattern | Apply |
|---------|-------|
| **Guard Clauses** | Early returns for edge cases |
| **Flat > Nested** | Avoid deep nesting (max 2 levels) |
| **Composition** | Small functions composed together |
| **Colocation** | Keep related code close |

---

## AI Coding Style

| Situation | Action |
|-----------|--------|
| User asks for feature | Write it directly |
| User reports bug | Fix it, don't explain |
| No clear requirement | Ask, don't assume |

---

## Anti-Patterns (DON'T)

| āŒ Pattern | āœ… Fix |
|-----------|-------|
| Comment every line | Delete obvious comments |
| Helper for one-liner | Inline the code |
| Factory for 2 objects | Direct instantiation |
| utils.ts with 1 function | Put code where used |
| "First we import..." | Just write code |
| Deep nesting | Guard clauses |
| Magic numbers | Named constants |
| God functions | Split by responsibility |

---

## šŸ”“ Before Editing ANY File (THINK FIRST!)

**Before changing a file, ask yourself:**

| Question | Why |
|----------|-----|
| **What imports this file?** | They might break |
| **What does this file import?** | Interface changes |
| **What tests cover this?** | Tests might fail |
| **Is this a shared component?** | Multiple places affected |

**Quick Check:**
```
File to edit: UserService.ts
└── Who imports this? → UserController.ts, AuthController.ts
└── Do they need changes too? → Check function signatures
```

> šŸ”“ **Rule:** Edit the file + all dependent files in the SAME task.
> šŸ”“ **Never leave broken imports or missing updates.**

---

## Summary

| Do | Don't |
|----|-------|
| Write code directly | Write tutorials |
| Let code self-document | Add obvious comments |
| Fix bugs immediately | Explain the fix first |
| Inline small things | Create unnecessary files |
| Name things clearly | Use abbreviations |
| Keep functions small | Write 100+ line functions |

> **Remember: The user wants working code, not a programming lesson.**

---

## šŸ”“ Self-Check Before Completing (MANDATORY)

**Before saying "task complete", verify:**

| Check | Question |
|-------|----------|
| āœ… **Goal met?** | Did I do exactly what user asked? |
| āœ… **Files edited?** | Did I modify all necessary files? |
| āœ… **Code works?** | Did I test/verify the change? |
| āœ… **No errors?** | Lint and TypeScript pass? |
| āœ… **Nothing forgotten?** | Any edge cases missed? |

> šŸ”“ **Rule:** If ANY check fails, fix it before completing.

---

## Verification Scripts (MANDATORY)

> šŸ”“ **CRITICAL:** Each agent runs ONLY their own skill's scripts after completing work.

### Agent → Script Mapping

| Agent | Script | Command |
|-------|--------|---------|
| **frontend-specialist** | UX Audit | `python .agent/skills/frontend-design/scripts/ux_audit.py .` |
| **frontend-specialist** | A11y Check | `python .agent/skills/frontend-design/scripts/accessibility_checker.py .` |
| **backend-specialist** | API Validator | `python .agent/skills/api-patterns/scripts/api_validator.py .` |
| **mobile-developer** | Mobile Audit | `python .agent/skills/mobile-design/scripts/mobile_audit.py .` |
| **database-architect** | Schema Validate | `python .agent/skills/database-design/scripts/schema_validator.py .` |
| **security-auditor** | Security Scan | `python .agent/skills/vulnerability-scanner/scripts/security_scan.py .` |
| **seo-specialist** | SEO Check | `python .agent/skills/seo-fundamentals/scripts/seo_checker.py .` |
| **seo-specialist** | GEO Check | `python .agent/skills/geo-fundamentals/scripts/geo_checker.py .` |
| **performance-optimizer** | Lighthouse | `python .agent/skills/performance-profiling/scripts/lighthouse_audit.py <url>` |
| **test-engineer** | Test Runner | `python .agent/skills/testing-patterns/scripts/test_runner.py .` |
| **test-engineer** | Playwright | `python .agent/skills/webapp-testing/scripts/playwright_runner.py <url>` |
| **Any agent** | Lint Check | `python .agent/skills/lint-and-validate/scripts/lint_runner.py .` |
| **Any agent** | Type Coverage | `python .agent/skills/lint-and-validate/scripts/type_coverage.py .` |
| **Any agent** | i18n Check | `python .agent/skills/i18n-localization/scripts/i18n_checker.py .` |

> āŒ **WRONG:** `test-engineer` running `ux_audit.py`
> āœ… **CORRECT:** `frontend-specialist` running `ux_audit.py`

---

### šŸ”“ Script Output Handling (READ → SUMMARIZE → ASK)

**When running a validation script, you MUST:**

1. **Run the script** and capture ALL output
2. **Parse the output** - identify errors, warnings, and passes
3. **Summarize to user** in this format:

```markdown
## Script Results: [script_name.py]

### āŒ Errors Found (X items)
- [File:Line] Error description 1
- [File:Line] Error description 2

### āš ļø Warnings (Y items)
- [File:Line] Warning description

### āœ… Passed (Z items)
- Check 1 passed
- Check 2 passed

**Should I fix the X errors?**
```

4. **Wait for user confirmation** before fixing
5. **After fixing** → Re-run script to confirm

> šŸ”“ **VIOLATION:** Running script and ignoring output = FAILED task.
> šŸ”“ **VIOLATION:** Auto-fixing without asking = Not allowed.
> šŸ”“ **Rule:** Always READ output → SUMMARIZE → ASK → then fix.

Overview

This skill encodes pragmatic clean-code standards for TypeScript projects: concise, direct, and focused on working solutions without over-engineering. It prescribes naming, function size, structure, and a strict edit checklist so changes are safe and maintainable.

How this skill works

The skill inspects code for violations of core principles (SRP, DRY, KISS, YAGNI) and enforces concrete rules: meaningful names, small single-purpose functions, limited arguments, guard clauses, and flat control flow. It also includes a mandatory pre-edit checklist and a verification flow that requires running targeted validation scripts and summarizing their output before making fixes.

When to use it

  • Starting a new TypeScript module or refactor to improve readability
  • Responding to a bug report where minimal, focused changes are required
  • Reviewing pull requests to enforce consistent naming and function size
  • Cleaning up technical debt without adding features
  • Before editing shared files to avoid breaking dependent code

Best practices

  • Prefer self-documenting names; if a comment is needed, rename instead
  • Keep functions 5–20 lines and one level of abstraction each
  • Use guard clauses and avoid nesting deeper than two levels
  • Limit function arguments to 0–3, favor composition over large helpers
  • Run only the specified validation scripts, parse their output, summarize, and ask before fixing

Example use cases

  • Refactor a 150-line function into small composable functions to restore SRP
  • Rename cryptic variables to reveal intent and remove explanatory comments
  • Handle edge cases with guard clauses to reduce nesting and improve tests
  • Perform a scoped edit: update a file and all dependent files in the same task
  • Run lint/type coverage scripts, summarize findings, and await approval to apply fixes

FAQ

What if a change requires updating many files?

Edit the target file and all dependent files in the same task. Verify imports, signatures, and tests before declaring the task complete.

When should I add a comment?

Only when intent cannot be conveyed by code. Prefer renaming or extracting a small function so the code is self-explanatory.

Which validation scripts must I run?

Run the scripts mapped to your agent role and the shared checks (lint, type coverage, i18n). Capture output, summarize errors/warnings/passes, and ask before fixing.