unslop
This skill should be used when the user asks to "clean up", "remove slop", "simplify", "unslop", "review for quality", "reduce complexity", "tighten up", "cleanup before PR", "pre-PR review", "too verbose", "over-engineered", "remove unnecessary code", "AI generated mess", "simplify this", "reduce abstractions", or mentions "slop", "bloated code", "defensive coding", "unnecessary complexity", "too many functions", "over-abstracted". Also applicable when reviewing code after an AI generation session, preparing a branch for PR, or when code smells like it was written by a model that optimizes for looking thorough rather than being correct.
What this skill does
# Unslop — Post-Generation Code Quality Cleanup
Reviews git diffs against 14 simplicity directives and proposes concrete fixes. Targets the specific failure mode of AI-generated code: correct but bloated.
## Core Philosophy
AI code generators produce code that is usually correct but systematically verbose. The model optimizes for *appearing thorough* — adding defensive checks, optional parameters, helper abstractions, and error handling for conditions that cannot occur. This isn't a bug; it's an alignment artifact. The model would rather include unnecessary code than risk missing something.
The result: code that works but is harder to read, has more state to track, and is more complex than necessary. This skill identifies and removes that accidental complexity.
**The test is simple: does removing this code change behavior?** If not, remove it.
## How to Detect Changed Code
Use git to find what changed. Try these in order:
1. **Branch diff** (most common): `git diff main...HEAD --name-only` — all changes on this branch
2. **Staged changes**: `git diff --staged --name-only` — about to be committed
3. **Unstaged changes**: `git diff --name-only` — modified but not staged
4. **Explicit files**: User passes `--files path1 path2` — skip detection
Filter out non-code files: lockfiles, `*.generated.*`, `vendor/`, `node_modules/`, images, fonts, `.min.*` files.
For the actual diff content per file: `git diff main...HEAD -- path/to/file.ts`
## The 14 Directives — Summary
| # | Directive | Red Flag |
|---|-----------|----------|
| 1 | Write skimmable code | Long functions requiring full read to understand, poor visual structure |
| 2 | Minimize possible states | Extra arguments, wider types than needed, boolean flags |
| 3 | Use discriminated unions | `type` field + separate checks vs. a single discriminated union |
| 4 | Exhaustively handle multi-type objects | `if/else` chains missing cases, no `default: assertNever()` |
| 5 | Trust the types | Null checks on non-nullable types, redundant `typeof` guards |
| 6 | Assert on load, be opinionated | Permissive defaults, late validation, `?? fallback` for required values |
| 7 | Remove changes not strictly required | Diff includes reformatting, renames, or moves unrelated to the task |
| 8 | Bias for fewer lines | Verbose constructs when concise alternatives exist |
| 9 | No complex or clever code | Nested ternaries, chained reduces, generic abstractions for single use |
| 10 | Don't over-split functions | Helpers called once, 3-line functions wrapping trivial logic |
| 11 | Early returns over nesting | `if/else` chains where early return would flatten the logic |
| 12 | Assert instead of try/catch or defaults | `try { } catch { return default }` hiding real errors |
| 13 | Keep argument count low | Functions taking 4+ parameters, passing unchanged values through |
| 14 | Don't make arguments optional if required | `arg?: Type` where every caller passes the argument |
For detailed guidance, examples, and before/after code for each directive, load **`references/code-quality-directives.md`**.
## Decision Tree — Which Reference to Load
**"I need detailed guidance on a specific directive"**
→ **`references/code-quality-directives.md`** — Full principle, reasoning, red flags, and before/after examples for all 14 directives.
**"I'm not sure if this is a real issue or a false positive"**
→ **`references/gotchas.md`** — Framework conventions, language idioms, test code exceptions, and cases where complexity is genuinely warranted.
**"I need both"**
→ Load both. The directives file is the primary reference; gotchas is the safety net.
## Output Format
Every review produces findings in this structure:
```
## Unslop Review
### Summary
- Files reviewed: N
- Findings: N (breakdown by directive)
- Estimated lines removable: N
### File: path/to/file.ts
1. **Directive #N: [Name]** — Lines L1-L2
- What: [One sentence describing the issue]
- Why: [The principle violated and the concrete cost]
- Fix:
```ts
[replacement code]
```
### Recommendations
- [Top 3 highest-impact simplifications across all files]
```
**Rules for findings:**
- Only flag code in the diff — unchanged code is out of scope
- Every finding needs a concrete fix — "consider simplifying" is not acceptable
- Check gotchas before finalizing — false positives destroy trust
- Group related findings that share a root cause
- Estimate lines removable per finding
## Workflow
### Small diffs (≤10 files)
1. Detect changed files via git
2. For each file: read contents, get diff, evaluate against directives
3. Load `references/code-quality-directives.md` for detailed guidance on flagged directives
4. Check `references/gotchas.md` before finalizing
5. Present report
6. Apply fixes → typecheck → lint → report (skip if `--check`)
### Large diffs (>10 files)
1. Detect changed files via git
2. Spawn `unslop-reviewer` subagent per file or batch of related files
3. Collect reports from subagents
4. Deduplicate and merge findings
5. Present consolidated report
6. Apply fixes sequentially → typecheck → lint → report (skip if `--check`)
## What This Skill Does NOT Do
- **Correctness** — Not checking if the code works. That's what tests are for.
- **Formatting** — Not checking style, indentation, or semicolons. That's the formatter's job.
- **Naming** — Not judging variable or function names. Too subjective, low ROI.
- **Performance** — Not profiling or benchmarking. See the `performance-optimization` skill.
- **Security** — Not scanning for vulnerabilities. Separate concern entirely.
- **Architecture** — Not redesigning the module structure. Just cleaning up within it.
This skill has one job: reduce accidental complexity in recently changed code.
## All Reference Files
| File | Content | Lines |
|------|---------|-------|
| **`references/code-quality-directives.md`** | Detailed per-directive guidance with before/after examples | ~900 |
| **`references/gotchas.md`** | False positive prevention, framework exceptions, language idioms | ~250 |
Related in Code Review
gstack
IncludedFast headless browser for QA testing and site dogfooding. Navigate pages, interact with elements, verify state, diff before/after, take annotated screenshots, test responsive layouts, forms, uploads, dialogs, and capture bug evidence. Use when asked to open or test a site, verify a deployment, dogfood a user flow, or file a bug with screenshots. (gstack)
startup-due-diligence
IncludedLegal due diligence review for seed-stage and Series A startups (US, Delaware C-Corp focus). Supports both investor and founder perspectives. Capabilities include: (1) Interactive document review and issue spotting; (2) Document request list generation; (3) Cap table and SAFE/convertible note analysis; (4) Red flag identification with severity ratings; (5) Diligence report generation. TRIGGERS: due diligence, DD, startup investment, cap table review, Series A, seed round, investor diligence, legal review startup, SAFE analysis, convertible note, 409A, founder vesting.
interview-master
IncludedThis skill should be used when the user asks to "generate interview questions", "prepare for interview", "optimize resume", "conduct mock interview", "analyze git commits for resume", "generate resume from code", "review my resume", or mentions interview preparation, career assistance, or extracting project experience from git history. Provides comprehensive interview and career development guidance for both job seekers and interviewers.
fix-issue
IncludedFixes GitHub issues using parallel analysis agents for root cause investigation, code exploration, and regression detection. Reads issue context from gh CLI, searches codebase and memory for related patterns, generates a fix with tests, and links the resolution back to the issue via PR. Includes prevention analysis to avoid recurrence. Use when debugging errors, resolving regressions, fixing bugs, or triaging issues.
sf-apex
IncludedGenerates and reviews Salesforce Apex code with 150-point scoring. TRIGGER when: user writes, reviews, or fixes Apex classes, triggers, test classes, batch/queueable/schedulable jobs, or touches .cls/.trigger files. DO NOT TRIGGER when: LWC JavaScript (use sf-lwc), Flow XML (use sf-flow), SOQL-only queries (use sf-soql), or non-Salesforce code.
swift-development
IncludedComprehensive Swift development for building, testing, and deploying iOS/macOS applications. Use when Claude needs to: (1) Build Swift packages or Xcode projects from command line, (2) Run tests with XCTest or Swift Testing framework, (3) Manage iOS simulators with simctl, (4) Handle code signing, provisioning profiles, and app distribution, (5) Format or lint Swift code with SwiftFormat/SwiftLint, (6) Work with Swift Package Manager (SPM), (7) Implement Swift 6 concurrency patterns (async/await, actors, Sendable), (8) Create SwiftUI views with MVVM architecture, (9) Set up Core Data or SwiftData persistence, or any other Swift/iOS/macOS development tasks.