Chisle Audit
SkillFiles & storageOne-shot efficiency audit of a file, diff, or whole repo across BOTH axes at once: over-engineered code (reinvented stdlib, needless abstractions, speculative config) AND bloated prose (verbose comments, padded docstrings, redundant doc sections). Neither a pure code-minimizer nor a pure prose compressor does both in one pass. That's the point. Ranked report, biggest saving first; changes nothing. Use when the user says "chisle audit", "/chisle-audit", "audit this for bloat", "what can I cut", "review this PR for over-engineering and verbosity".
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Chisle Audit skill
What this skill tells your AI
The instructions your AI receives, as published by jaypokale/chisle in skills/chisle-audit/SKILL.md and read by ahel’s review.
Scan the target (a diff, a file, or the repo tree) and report what to cut, on both axes. One-shot. Read-only: never edit, never write a flag, never apply fixes.
Scope
- No argument → audit the current
git diff(staged + unstaged). Empty diff → auditHEAD~1..HEAD. - A path → audit that file or directory.
- "repo" / "whole repo" → walk the tree (skip vendored/generated/
node_modules/dist/lockfiles).
What to flag
Code (the YAGNI axis):
- Reinvented stdlib (hand-rolled debounce, deep-clone, groupBy, retry loop, date math)
- Abstraction with one implementation (interface/factory/wrapper for a single case)
- New dependency for what a few lines or an installed dep already covers
- Config/option/flag that never varies
- Speculative "for later" scaffolding with no current caller
- Verbose code where a native platform feature (CSS, DB constraint,
<input type>) does it
Prose (the compression axis), the half a code-only auditor misses:
- Comments that restate the code (
i += 1 // increment i) - Docstrings/READMEs padded with filler, hedging, ceremony, or duplicated content
- Multi-paragraph explanations where one tight sentence carries the meaning
- Decorative tables/emoji/headings that add tokens, not information
- Dead prose: TODO graveyards, stale "see also" links, obsolete sections
What NOT to flag
Input validation at trust boundaries, error handling that prevents data loss,
security, accessibility, deliberate // chisle: / // ponytail: shortcuts already
documented, or domain comments that explain why (not what).
Output
One ranked list, biggest cut first. One finding per line. No preamble, no praise.
path:line [code|prose] <what's bloated> → <the lean replacement>. (~N lines/tokens)
End with a two-line summary:
N findings: X code, Y prose. Est. removable: ~A lines code, ~B lines prose.
Biggest win: <the single highest-impact cut>.
Be honest about uncertainty: mark a finding (check) if cutting it might lose
behavior you can't verify from the snippet. Lean toward fewer, high-confidence
findings over a long speculative list.
Signals
- GitHub stars
- 434
- Forks
- 28
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
chisle-audit- Source
- github.com/jaypokale/chisle