Aislop
Catch AI-generated slop, lazy patterns, and quality regressions in your diff before commit or when CI score drops.
Overview
aislop is an agent skill most often used in Ship (also Build, Operate) that reviews your changes for AI slop, quality score failures, and sloppy patterns before you commit or merge.
Install
npx skills add https://github.com/scanaislop/aislop-skill --skill aislopWhat is this skill?
- Trigger-accuracy eval set distinguishes quality/slop queries from plain lint, format, or design-review asks
- Handles pre-commit review, CI failures when score drops below 70, and post-merge cleanup before opening a PR
- Supports security review in changes, deduplication of repeated fetch logic, and overly long multi-purpose functions
- Includes aislop doctor for tooling/env diagnostics when scanners are not found
- Addresses "green scan but sloppy" cases where linters pass but code quality still fails human/agent standards
- 10 should-trigger eval prompts
- 5 should-not-trigger contrast prompts
Adoption & trust: 1 installs on skills.sh; 4 GitHub stars; 2/3 security scanners passed (skills.sh audits); trending (+100% hot-view momentum).
What problem does it solve?
Your linter and CI are green but the PR still feels like lazy AI output, duplicated logic, or a failing internal quality score you cannot interpret.
Who is it for?
Solo builders shipping feature branches who use automated quality scoring or want a second pass beyond eslint on AI-assisted code.
Skip if: Teams that only need prettier/eslint runs, raw test coverage reports, or greenfield Salesforce security pattern lookup without a quality-scoring workflow.
When should I use this skill?
User asks to check a refactor before commit, review a PR for slop, fix CI score below threshold, dedupe logic, review security in changes, add score badge/trend, clean up after merges, or run aislop doctor.
What do I get? / Deliverables
You get a focused slop and quality pass on the diff or repo with actionable fixes, score context, and tooling checks so you can commit or open the PR with confidence.
- Review findings on diffs or project
- Recommended fixes for slop, dedupe, and length issues
- Score or trend context when badge or CI gate is requested
Recommended Skills
Journey fit
Spans multiple journey phases - primary shelf plus alternate fits below.
Canonical shelf is Ship/review because pre-commit PR checks, score gates, and whole-project cleanup are the primary invoke triggers in the eval set. Review subphase matches code-review, slop detection, dedupe, and security-in-diff workflows rather than greenfield build tasks.
Where it fits
After a billing refactor you ask the agent to dedupe repeated fetch logic before you wire the last endpoint.
You finish a PR and want slop and lazy-comment checks instead of only running the linter.
CI fails because the quality score fell below 70 and you need fixes aligned to what the scorer flags.
Scans fail locally because tools are missing and you invoke doctor to fix the environment.
How it compares
Use instead of asking the agent to "read all of src/" ad hoc when you need slop detection and score-aware cleanup, not a one-off linter invocation.
Common Questions / FAQ
Who is aislop for?
Indie and solo developers using Claude Code, Cursor, or similar agents who want pre-commit and PR-quality checks tuned to AI-generated code and project score gates.
When should I use aislop?
Before committing a refactor, when CI reports a score below your threshold, after merging branches before opening a PR, when you suspect duplicated fetch logic or oversized functions, or when linters pass but the change still feels sloppy. It also applies in Build when deduping p
Is aislop safe to install?
Review the Security Audits panel on this Prism page and your org policy before granting repository access; the skill is intended to read and critique project code like a review agent.
SKILL.md
READMESKILL.md - Aislop
{ "description": "aislop skill trigger evaluation set", "evals": [ { "id": "trigger-accuracy", "description": "Tests whether the skill triggers correctly on quality-related queries and does not trigger on adjacent but unrelated queries", "prompts": { "should_trigger": [ "ok i just finished this billing refactor, can you check it before i commit?", "any slop in this PR? i feel like i left some lazy comments", "weve got a CI fail saying score dropped below 70, fix whatever it finds", "review my changes for security issues, i think i might have a sql injection", "can you dedupe this? i keep writing the same fetch logic everywhere", "is this function too long? feels like it does too many things", "add a score badge to the readme and tell me our trend", "i just merged three branches and need the whole project cleaned up before i open the PR", "run aislop doctor, my env isnt finding the tools it needs", "the linter passes but theres still something wrong — green scan but sloppy" ], "should_not_trigger": [ "run the linter for me", "can you format this file with prettier", "is this auth system design secure?", "whats our test coverage percentage", "read the code in src/ and tell me whats wrong", "optimize this database query for me", "set up eslint for this project", "migrate from javascript to typescript", "can you explain what this function does", "deploy this to staging" ] } } ] } # Example 01 — before commit An agent implements a small feature, then runs aislop before handing control back. Commands below use the normal `npx aislop` quick-start path. In repos with strict supply-chain policy, use the project's pinned local script or binary instead. --- **User:** > Add a `formatBytes(n)` helper in `src/lib/format.ts` that returns "1.2 KB", "3.4 MB", etc. Export it from the barrel. **Agent (internal):** Implements `formatBytes`, updates `src/lib/index.ts` barrel, writes a unit test. Before replying, invokes the aislop skill because edits are finished and a commit is implicit. ```bash npx aislop scan --changes --json ``` Parses the JSON. Three findings: - `ai-slop/narrative-comment` · `src/lib/format.ts:3` · fixable - `ai-slop/unused-import` · `src/lib/format.ts:1` · fixable - `ai-slop/unsafe-type-assertion` · `src/lib/format.ts:18` · not fixable Runs auto-fix for the mechanical two: ```bash npx aislop fix ``` Re-reads the file. The `as any` cast is on `n as any` inside the magnitude branch. Replaces it with a proper numeric guard: ```ts if (typeof n !== "number" || !Number.isFinite(n)) { throw new TypeError("formatBytes expects a finite number"); } ``` Re-scans: ```bash npx aislop scan --changes ``` Score: 96 / 100. Zero errors, zero warnings. **Agent reply to user:** > Added `formatBytes` in `src/lib/format.ts` and re-exported it from `src/lib/index.ts`. Unit test covers bytes, KB, MB, GB, and the non-finite guard. > > Ran `aislop scan --changes`: 96 / 100, no findings. Ready to commit. --- Notes on what the agent did right: - Scoped the scan to `--changes` rather than the whole project. - Used `--json` when acting programmatically. - Ran `fix` for the mechanical findings before doing manual work. - Replaced `as any` with a real type guard, not a rule suppression. - Re-scanned after fixes before claiming done. - Reported the score and finding count in the reply. # Example 02 — agent handles the non-mechanical remainder `aislop fix` cleans up 8 of 12 findings. The agent addresses the remaining 4 by hand. Commands below use the normal `npx aislop` quick-start path. In repos with strict supply-chain policy, use the project's pinned local script or binary instead. --- **User:** > I just merged in a large refactor of the billing module. Can yo