home / skills / georgekhananaev / claude-skills-vault / beautiful-code

beautiful-code skill

/.claude/skills/beautiful-code

This skill enforces production-grade quality across TypeScript, Python, Go, and Rust, boosting safety, security, and maintainability in code reviews and

npx playbooks add skill georgekhananaev/claude-skills-vault --skill beautiful-code

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

Files (21)
SKILL.md
6.5 KB
---
name: beautiful-code
description: Multi-language code quality standards for TypeScript, Python, Go, and Rust. Enforces type safety, security, performance, and maintainability with progressive enforcement. Use when writing, reviewing, or refactoring code across any of these languages.
---

# Beautiful Code Standards

Enforce production-grade code quality across TypeScript, Python, Go, and Rust.

## When to Use

- Writing or reviewing code in TS/Python/Go/Rust
- Setting up linting/CI for a project
- Code quality audit or refactoring
- User requests code review or style check

## Quick Reference

| Language | Type Safety | Linter | Complexity |
|----------|-------------|--------|------------|
| TypeScript | `strict`, no `any` | ESLint + tsx-eslint | max 10 |
| Python | mypy `strict`, PEP 484 | Ruff + mypy | max 10 |
| Go | staticcheck | golangci-lint | max 10 |
| Rust | clippy pedantic | clippy + cargo-audit | - |

## Severity Levels

| Level | Description | Action |
|-------|-------------|--------|
| **Critical** | Security vulnerabilities | Block merge |
| **Error** | Bugs, type violations, `any` | Block merge |
| **Warning** | Code smells, complexity | Must address |
| **Style** | Formatting, naming | Auto-fix |

## Core Rules (All Languages)

### Type Safety
- No implicit any / untyped functions
- No type assertions without guards
- Explicit return types on public APIs

### Security
- No hardcoded secrets (use gitleaks)
- No eval/pickle/unsafe deserialization
- Parameterized queries only
- SCA scanning (npm audit/pip-audit/govulncheck/cargo-audit)

### Complexity
- Max cyclomatic complexity: 10
- Max function lines: 50
- Max nesting depth: 3
- Max parameters: 5

### Error Handling
- No ignored errors (Go: no `_` for err)
- No bare except (Python)
- No unwrap in prod (Rust)
- Wrap errors with context

## Language-Specific Standards

### TypeScript
See: `references/typescript.md`

```typescript
// CRITICAL: Never use any
const bad: any = data;           // Error
const good: unknown = data;      // OK

// ERROR: No type assertions
const bad = data as User;        // Error
const good = isUser(data) ? data : null;  // OK

// ERROR: Non-null assertions
const bad = user!.name;          // Error
const good = user?.name ?? '';   // OK
```

### Python
See: `references/python.md` (extends `pep8` skill)

```python
# CRITICAL: All functions must be typed
def bad(data):                   # Error
    return data

def good(data: dict[str, Any]) -> list[str]:  # OK
    return list(data.keys())

# Use modern syntax
value: str | None = None         # OK (not Optional)
items: list[str] = []            # OK (not List)
```

### Go
See: `references/go.md`

```go
// CRITICAL: Never ignore errors
result, _ := doSomething()       // Error
result, err := doSomething()     // OK
if err != nil {
    return fmt.Errorf("doing something: %w", err)
}
```

### Rust
See: `references/rust.md`

```rust
// CRITICAL: No unwrap in production
let value = data.unwrap();        // Error
let value = data?;                // OK
let value = data.unwrap_or_default(); // OK
```

## Cross-Language Standards

### Structured Logging
See: `references/logging.md`

```typescript
// TypeScript (pino)
logger.info({ userId, action: 'login' }, 'User logged in');

// Python (structlog)
logger.info("user_login", user_id=user_id)

// Go (zerolog)
log.Info().Str("user_id", userID).Msg("user logged in")
```

### Test Coverage
See: `references/testing.md`

| Metric | Threshold |
|--------|-----------|
| Line coverage | 80% min |
| Branch coverage | 70% min |
| New code | 90% min |

### Security Scanning
See: `references/security.md`

- Secrets: gitleaks (pre-commit + CI)
- Dependencies: npm audit / pip-audit / govulncheck / cargo-audit
- Accessibility: jsx-a11y (TypeScript)
- Race detection: go test -race (Go)

### API Design
See: `references/api-design.md`

- Use proper HTTP status codes (200, 201, 204, 400, 401, 403, 404, 422, 429, 500)
- RFC 7807 error format (type, title, status, detail, errors)
- Plural nouns for resources: `/users/{id}/orders`
- Validate at API boundary, not deep in services

### Database Patterns
See: `references/database.md`

- Transactions for multi-write operations
- N+1 prevention: eager load or batch
- Safe migrations (expand-contract pattern)
- Always paginate list queries

### Async & Concurrency
See: `references/async-concurrency.md`

- Always clean up resources (try/finally, defer, Drop)
- Set timeouts on all async operations
- Use semaphores for rate limiting
- Avoid blocking in async contexts

## Enforcement Strategy

### Progressive (Ratchet-Based)
```
Phase 1: Errors block, Warnings tracked
Phase 2: Strict on NEW files only
Phase 3: Strict on TOUCHED files
Phase 4: Full enforcement
```

### WIP vs Merge Mode

| Mode | Trigger | Behavior |
|------|---------|----------|
| WIP | Local commit | Warnings only |
| Push | git push | Errors block |
| PR | PR to main | Full strict |

### Emergency Bypass

```bash
EMERGENCY_BYPASS=true git commit -m "HOTFIX: [ticket] description"
```

## Tooling

### Pre-commit
```yaml
repos:
  - repo: https://github.com/gitleaks/gitleaks
    hooks: [gitleaks]
  # Language-specific hooks...
```

### CI Jobs
- secrets-scan (gitleaks)
- lint (per-language matrix)
- coverage (80% threshold)
- go-race (if Go files changed)

## Config Files

Available in `configs/`:
- `typescript/` - ESLint, tsconfig, Prettier
- `python/` - pyproject.toml, pre-commit
- `go/` - golangci.yaml
- `rust/` - clippy.toml

## Scripts

Available in `scripts/`:
- `check_changed.sh` - Monorepo-aware incremental linting
- `check_all.sh` - Full repository check

## AI-Friendly Patterns

1. **Explicit Types**: Always declare types explicitly
2. **Single Responsibility**: One function = one purpose
3. **Small Functions**: < 30 lines ideal
4. **Flat is Better**: Max nesting depth 3
5. **Guard Clauses**: Early returns for edge cases
6. **No Magic**: Named constants only
7. **Obvious Flow**: Linear, predictable execution

## Naming Conventions

| Element | TypeScript | Python | Go | Rust |
|---------|------------|--------|-----|------|
| Variables | camelCase | snake_case | camelCase | snake_case |
| Functions | camelCase | snake_case | camelCase | snake_case |
| Constants | SCREAMING_SNAKE | SCREAMING_SNAKE | MixedCaps | SCREAMING_SNAKE |
| Types | PascalCase | PascalCase | PascalCase | PascalCase |
| Files | kebab-case | snake_case | lowercase | snake_case |

Overview

This skill provides multi-language code quality standards for TypeScript, Python, Go, and Rust. It enforces type safety, security, performance, and maintainability with progressive enforcement stages. Use it to write, review, or refactor production-ready code across these languages.

How this skill works

The skill inspects code against a curated rule set: strict typing, security scans, complexity caps, error-handling rules, and language-specific linters. It maps findings to severity levels (Critical, Error, Warning, Style) and supports progressive enforcement (new files, touched files, full repository). Integrations include pre-commit hooks, CI jobs, SCA and secret scanning tools.

When to use it

  • Writing new services or libraries in TS/Python/Go/Rust
  • Code reviews and pull request gating
  • Repository or monorepo refactors and migrations
  • Setting up or improving linting and CI quality gates
  • Auditing code for security, complexity, or maintainability

Best practices

  • Enable strict type checking and avoid implicit or unsafe types
  • Block merges on security and type-critical failures; auto-fix style issues
  • Limit cyclomatic complexity (<=10) and function length (<=50 lines)
  • Enforce explicit error handling and avoid unsafe operations (unwrap, bare except, ignored errors)
  • Progressively enforce rules: start on new files, expand to touched files, then full repo

Example use cases

  • Automate PR checks to block merges with security or type violations
  • Run monorepo-aware incremental linting for only changed packages
  • Apply strict typing and linter rules when introducing new APIs or public libraries
  • Audit legacy code during refactor: stage enforcement to touched files first
  • Add CI jobs: secrets-scan, language lints, coverage thresholds, and race detection

FAQ

How does progressive enforcement work?

Start with warnings and errors blocking on new files, then widen to touched files and finally the full repository so teams can adopt standards incrementally.

What tools are recommended for security and secrets?

Use gitleaks for secrets in pre-commit and CI, and SCA tools per ecosystem: npm audit, pip-audit, govulncheck, and cargo-audit.