deslop
Correct code hygiene by detecting AI slop with a three-phase HIGH/MEDIUM/LOW certainty scan, safely auto-fixing only deterministic HIGH findings, verifying with the repo's own test command, and rolling back on regression. Use when the user says "deslop", "clean AI slop", "remove debug code", "find placeholders", "find stub code", or "remove dead code".
What this skill does
# deslop — correct slop invariant, preserve behavior
Run a `correct` op-cell: restore the invariant that production code has no debug leftovers, placeholder bodies, swallowed errors, hardcoded credentials, or formatter noise. Classify every finding by certainty; apply only HIGH-certainty mechanical fixes; MEDIUM and LOW are report-only unless the user explicitly asks for a separate manual refactor.
The detailed pattern catalog lives in `references/slop-catalog.md`. Load it when choosing exact pattern recipes or deciding whether a finding is fixable.
## When to Apply / NOT
Apply when the request names AI slop, debug-code cleanup, placeholder/stub cleanup, empty error handlers, hardcoded secrets, dead code, or a pre-PR hygiene sweep.
Do **not** apply for broad architecture simplification, ordinary lint formatting, security audit beyond hardcoded credential patterns, or behavior-changing cleanup. Do not use this to justify deleting code whose purpose is unclear.
## Certainty Contract
| Level | Source | Action |
|---|---|---|
| **HIGH** | Deterministic regex/AST match in non-test, non-fixture, non-generated code | Eligible for mechanical fix, then repo tests |
| **MEDIUM** | Reasoned structural signal or codegraph/context signal | Report only; cite evidence; no auto-fix |
| **LOW** | Optional external CLI heuristic, if tool already exists | Report only; no install; no auto-fix |
Certainty is not severity. A hardcoded token is HIGH certainty and high severity, but still usually `flag-only` because the safe fix is secret rotation plus replacement by an environment read. A trailing-space match is HIGH certainty and low severity, but safe to remove.
## Workflow
1. **Scope files.** Prefer changed files when the user did not request a full sweep. Exclude tests, fixtures, mocks, examples, generated output, vendored code, lockfiles, build artifacts, and minified bundles:
- `**/test/**`, `**/tests/**`, `**/__tests__/**`, `*.test.*`, `*.spec.*`, `*_test.*`, `*Test.java`
- `**/fixtures/**`, `**/mocks/**`, `**/testdata/**`, `**/examples/**`, `**/benches/**`
- `dist/**`, `build/**`, `target/**`, `coverage/**`, `vendor/**`, `node_modules/**`, `*.min.*`, generated/protobuf/openapi outputs
- keep Markdown out of whitespace cleanup because trailing spaces can be semantic line breaks.
2. **Phase 1 — HIGH deterministic scan.** Use `search` for line patterns and `ast-grep` where syntax shape matters. Record `{file, line, pattern, certainty: HIGH, strategy}`. Recipes:
- Debug output: `console.log/debug`, Python `print(`/`breakpoint(`/`import pdb`, Rust `println!`/`dbg!`/`eprintln!`, Go `fmt.Print*` with debug labels, Java/Kotlin `System.out/println` when not CLI output.
- Placeholder bodies: `throw new Error("TODO/not implemented")`, `todo!()`, `unimplemented!()`, `panic!("TODO")`, `raise NotImplementedError`, `def x(): pass`, `def x(): ...`, Go `panic("TODO")`, Java `UnsupportedOperationException`, Kotlin `TODO()`.
- Empty handlers: JS/TS `catch (...) {}`, Python `except ...: pass`, Java/Kotlin/C++ empty catch blocks, Go `if err != nil {}`.
- Rust panic shortcuts: bare `.unwrap()` and `.expect()` in non-test code. Flag them HIGH for presence, but do not rewrite automatically.
- Hardcoded credentials: `sk-`, `ghp_`/`github_pat_`, `AKIA`, `Bearer <token>`, JWT-looking strings, private-key blocks, Slack/Stripe/NPM/Twilio/SendGrid/Discord token forms. Flag only.
- Mechanical whitespace: mixed tabs+spaces on one indentation prefix, trailing whitespace outside Markdown.
3. **Phase 1b — MEDIUM contextual scan.** Use codegraph first when indexed; otherwise combine `ast-grep`, `search`, and direct reads of the narrow files. Report only:
- Doc-to-code ratio >3 for a real function with at least 3 code lines.
- Verbosity ratio >2 comments per code line inside a function; filler/hedging/buzzword comments.
- Dead code after `return`, `throw`, `break`, or `continue` that is not a language-required fallthrough case.
- Over-engineering indicators: file/export ratio >20, lines/export >500, directory depth >4 without real module boundaries.
- Buzzword inflation: claims like "production-ready", "secure", "enterprise-grade", "scalable" with fewer than two concrete supporting code signals.
- Infrastructure without implementation: `Client`, `Connection`, `Pool`, `Service`, `Provider`, `Manager`, `Factory`, `Repository`, `Gateway`, `Queue`, `Cache`, or `Store` values created but never used beyond setup/export.
- Stub return values: a function whose only significant body line returns `0`, `null`, `undefined`, `None`, `nil`, `false`, `true`, `[]`, `{}`, `""`, empty collections, `Default::default()`, or `Optional.empty()`. Escalate attention when adjacent TODO/FIXME/STUB text exists, but keep auto-fix disabled.
4. **Phase 2 — LOW optional CLI scan.** Run only tools already available in the repo or PATH; never install. Record findings as LOW and `flag-only`:
- `jscpd` for duplication.
- `madge` for cycles.
- Existing `eslint`, `clippy`, `golangci-lint`, or language-native lint commands from package manifests / project config.
- If absent, write `missing: <tool>` in the report and continue.
5. **Prioritize.** Sort HIGH before MEDIUM before LOW; then severity; then scope proximity to changed files; then fix strategy. Keep a separate `fixes` list containing only HIGH findings with `remove-line`, `remove-block`, `replace-whitespace`, or `add-comment` strategies. Exclude every `flag-only` finding from automatic edits.
6. **Fix HIGH only.** Apply the smallest edit that removes the deterministic slop:
- `remove-line`: debug prints, trailing whitespace, isolated commented-out code blocks.
- `replace-whitespace`: convert mixed indentation to the file's dominant indentation style; strip trailing spaces.
- `add-comment`: empty catch/except blocks only when the correct behavior is intentionally swallowing the error and the surrounding code proves that intent. Otherwise flag; do not invent logging.
- `remove-block`: placeholder block only when it is unreachable/dead and removal cannot change API behavior. Stubs on live API surfaces are report-only.
- `flag-only`: hardcoded secrets, Rust unwrap/expect, placeholder implementations, dead code requiring control-flow judgment, architectural smells.
7. **Verify.** Run the repo's own test command after fixes. Derive it from manifests in this order: package script (`test`, then `check`, then `typecheck`), `cargo test`, `go test ./...`, `pytest`, `mvn test`, `gradle test`, or the project's documented command. If no command exists, run the narrowest parser/type check available and state the limitation.
8. **Rollback on regression.** If verification fails after applying fixes, immediately restore every changed file from the cleanup attempt with `git restore -- <file...>` and rerun the same verifier to confirm the baseline is back. Report the failed fix group as blocked, with file/line and failing command. Never suppress tests, rewrite expectations, or keep a partial cleanup after regression.
## Native Recipes
### Phase 1 search recipes
Use separate narrow searches so the match class is obvious:
```text
search pattern="console\\.(log|debug)\\(" paths=[source globs]
search pattern="\\b(print\\(|breakpoint\\(|import pdb|import ipdb)" paths=["**/*.py"]
search pattern="(println!|dbg!|eprintln!)\\(" paths=["**/*.rs"]
search pattern="throw\\s+new\\s+Error\\s*\\(\\s*['\"`].*(TODO|implement|not\\s+impl)" paths=["**/*.{js,jsx,ts,tsx,mjs,cjs}"]
search pattern="\\b(todo|unimplemented)!\\s*\\(|\\bpanic!\\s*\\(\\s*['\"].*(TODO|implement)" paths=["**/*.rs"]
search pattern="raise\\s+NotImplementedError|def\\s+\\w+\\s*\\([^)]*\\)\\s*:\\s*(pass|\\.\\.\\.)" paths=["**/*.py"]
search pattern="catch\\s*(\\([^)]*\\))?\\s*\\{\\s*\\}|except\\s*[^:]*:\\s*pass\\s*$|if\\s+err\\s*!=\\s*nil\\s*\\{\\s*\\}" paths=[source globs]
search pattern="sk-[A-Za-z0-9]{32,}|ghp_[A-Za-z0-9]{36}|github_pat_[A-Za-z0-9_]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.