deslop

Deslop — Code Hardening Skill

Systematically audit and harden an existing codebase for production. Designed for AI-generated ("vibe coded") codebases that work superficially but are fragile, sloppy, or insecure under real-world conditions.

This skill operates in two strict phases. Never mix them.

Phase 1: AUDIT   →  produces  AUDIT.md  (human-reviewable, machine-parseable)
Phase 2: FIX     →  consumes  AUDIT.md  →  applies fixes in safety order

The user provides a codebase (directory path or repo). They may specify focus areas, exclusions, or constraints. If not specified, audit everything.

Phase 1: AUDIT

MANDATORY before starting: Read the full audit checklist and format spec:

Read ~/.claude/skills/deslop/references/checklist.md     # 15-category audit checklist with specific patterns
Read ~/.claude/skills/deslop/references/audit-format.md  # Structured finding format for AUDIT.md

The audit runs five sequential passes. Each pass builds on the previous. Never skip a pass — thoroughness matters more than speed.

Pass 0 — Reconnaissance

Map the codebase before judging anything. Do NOT write findings yet.

1. Generate file tree: find . -type f | head -500 or equivalent. Understand the shape.
2. Classify files: Source, tests, configs, migrations, infra, docs, generated, vendored.
3. Identify the stack: Language(s), framework(s), package manager, build system, runtime.
4. Build dependency map: Which files import from which. Use grep -rn "import\|require\|from\|include" or language-specific tooling.
5. Identify entry points: Main files, route handlers, API endpoints, CLI entry points, event handlers.
6. Detect existing tooling: Check for .eslintrc, pyproject.toml, tsconfig.json, .prettierrc, Makefile, CI configs, etc.
7. Run available linters: If linters are configured, run them and capture output. If not, note this as a finding. Common commands:
8. JS/TS: npx eslint . --format json 2>/dev/null or npx tsc --noEmit 2>&1
9. Python: python -m pylint **/*.py --output-format=json 2>/dev/null or python -m flake8 . 2>&1
10. Go: go vet ./... 2>&1
11. Rust: cargo clippy --message-format=json 2>/dev/null
12. If no linter is configured, skip — don't install new tooling unless asked.
13. Produce the codebase map: Write a structured summary to the top of AUDIT.md:
14. Stack summary (language, framework, runtime)
15. File count by category
16. Module/directory architecture
17. Entry points
18. High-coupling modules (most imports in + out)
19. Linter output summary (if available)

Output of Pass 0: The "Codebase Overview" section of AUDIT.md. No findings yet.

Pass 1 — Patterns & Consistency

Scan for mechanical quality issues that don't require deep semantic understanding. Process file-by-file, prioritizing high-coupling modules first (from Pass 0's dependency map).

What to scan (load ~/.claude/skills/deslop/references/checklist.md categories 8-14):

• Naming convention violations and inconsistencies
• DRY violations — duplicated logic blocks, copy-pasted code
• Dead code — unused functions, unreachable branches, commented-out code, unused imports
• Magic numbers and hardcoded values
• Missing type annotations (for typed languages)
• Inconsistent patterns (e.g., callbacks in one file, promises in another)
• KISS/YAGNI violations — unnecessary abstractions, premature optimization
• Dependency issues — unused deps, circular imports

Chunking strategy for large files (>500 lines): Read in function/class-sized chunks. Never split in the middle of a function. When analyzing a chunk, re-read the file's import header for context.

For each finding: Write it to AUDIT.md using the format from ~/.claude/skills/deslop/references/audit-format.md.

Pass 2 — Logic & Resilience

Trace critical paths through the code. This pass requires cross-file context.

Start from entry points identified in Pass 0. For each critical path:

1. Trace the happy path from input to output.
2. Then ask: what happens when each step fails?
3. Check every error handling point: is the error caught? Logged? Re-thrown? Swallowed?
4. Check edge cases: null/undefined inputs, empty collections, boundary values, concurrent access.
5. Check data validation at trust boundaries (user input, API responses, file reads, env vars).

What to scan (load ~/.claude/skills/deslop/references/checklist.md categories 2-4):

• Correctness bugs: null derefs, off-by-one, race conditions, resource leaks, incorrect API usage
• Error handling: empty catches, swallowed exceptions, generic catches, missing async error handling, silent failures
• Business logic fragility: happy-path-only logic, missing edge cases, hardcoded business rules
• Regex hacks: patterns that pass test cases but fail on real-world input
• Async issues: unhandled promise rejections, missing await, callback hell without error propagation

CRITICAL: Do NOT flag business logic as "wrong" unless it's clearly a bug. The goal is resilience, not redesign. If you're unsure whether something is intentional behavior or a bug, flag it as [NEEDS_CLARIFICATION] and describe the concern.

Pass 3 — Security

What to scan (load ~/.claude/skills/deslop/references/checklist.md categories 1, 7):

• Injection: SQL injection, XSS, command injection, path traversal, SSRF
• Auth/Authz: missing checks, privilege escalation, broken session management
• Secrets: hardcoded API keys, tokens, passwords, connection strings in source
• Crypto: weak algorithms, insecure random, missing HTTPS enforcement
• Input validation: missing server-side validation, inconsistent validation across endpoints
• Data exposure: sensitive data in logs, verbose error messages to clients, PII leaks
• Dependencies: known CVE in dependencies (check lock files if present)

Use OWASP Top 10 as the mental framework. For each finding, note the CWE number if applicable.

Pass 4 — Synthesis & Prioritization

After all passes complete:

1. Deduplicate: Some findings may appear in multiple passes. Merge them, keeping the most severe classification.
2. Cross-reference: A DRY violation might also be a security concern (divergent validation logic). Link related findings.
3. Classify severity for every finding:
4. CRITICAL: Direct security vulnerabilities, data loss risk, crashes in core paths
5. HIGH: Logic errors with production impact, missing auth checks, resource leaks
6. MEDIUM: Missing validation, performance issues, significant code smells
7. LOW: Minor inconsistencies, naming issues, missing docs
8. INFO: Style suggestions, optimization opportunities, nice-to-haves
9. Assign fix tier (from ~/.claude/skills/deslop/references/fix-playbook.md):
10. Tier 1 (safe): No behavioral change possible. Formatting, dead code removal, renaming, type annotations.
11. Tier 2 (medium): Additive changes. Input validation, error handling, logging. Needs characterization tests.
12. Tier 3 (high risk): Structural changes. Refactoring APIs, changing data access patterns. Needs human review.
13. Write the executive summary at the top of AUDIT.md:
14. Total findings by severity
15. Top 5 most critical issues with one-line descriptions
16. Overall assessment: is this codebase production-ready? What's the blast radius of the issues found?
17. Estimated fix effort by tier

1. Present AUDIT.md to the user. Ask if they want to proceed to Phase 2, adjust priorities, or exclude anything.

Phase 2: FIX

MANDATORY before starting: Read the fix playbook:

Read ~/.claude/skills/deslop/references/fix-playbook.md  # Safety hierarchy, characterization tests, fix ordering

NEVER start Phase 2 without user confirmation on the audit. The user must review AUDIT.md first.

Fix Ordering

Process findings in this exact order:

1. Tier 1 fixes, CRITICAL severity first → safest chan