Yalla simplify
Skill iwo-szapar/yalla-autonomus-coding/skills/yalla-simplify
Review the current diff only for avoidable complexity and minimum-diff violations. Finds what to delete, replace with stdlib/native/existing code, or shrink. Use when the user says simplify, over-engineered, what can we delete, minimum diff, or /yalla-simplify.From its SKILL.md
npx -y skills add iwo-szapar/yalla-autonomus-coding --skill yalla-simplifyAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
2.6 KB, as published. Nobody here has run it
/yalla-simplify
Complexity-only review. Do not review correctness, security, product strategy, or test completeness except where they prove the diff cannot be simplified. The best finding deletes code.
Inputs
Default base is $BASE_BRANCH from .claude/YALLA.md or main.
Gather:
git diff "$BASE_BRANCH" --name-only
git diff "$BASE_BRANCH"
Read ${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/MINIMUM-DIFF.md and ${CLAUDE_PLUGIN_ROOT}/knowledge/yalla/REVIEW-CHECKS.md before judging.
If .pipeline/classification.json exists, inspect minimum_diff_decision and compare the diff to its selected rung, file budget, LOC budget, reuse targets, and skipped complexity.
Hunt
delete:dead code, unused flexibility, speculative feature, duplicate path, or wrapper that only delegates.existing:new code that should reuse an existing local function, component, command, route, template, or test helper.stdlib:hand-rolled behavior the standard library already ships.native:code or dependency doing what the platform, browser, database, shell, framework, or host already does.dependency:new dependency where stdlib/native/existing code is enough.yagni:abstraction with one implementation, config nobody sets, future-proofing without a second case, compatibility shim for unshipped behavior.shrink:same behavior in fewer lines without losing clarity or edge-case correctness.budget:diff exceeds the recorded minimum-diff budget without a documented reason.
Format
One line per finding:
path:Lx-Ly: <tag> <what to cut>. <replacement>.
Keep findings terse and mechanical. Do not include review prose, design commentary, or maybe-language. Rank the highest-confidence deletion first. If a finding cannot name what replaces the code, drop it.
End with:
net: -<N> lines, -<M> deps possible.
If there is nothing meaningful to cut:
Lean already. Ship.
Boundaries
- Do not apply fixes unless the user asks.
- Do not flag one focused behavior test as bloat.
- Do not ask for a simpler version that weakens the proof contract.
- Do not ask to remove security, validation, accessibility, or data-loss handling.
- If a simplification changes behavior, name the acceptance criterion it would drop. That is usually not a valid simplification.