Simplify Code: review paralel pentru cleanup de cod

Ce face

simplify-code este un skill pentru curățarea schimbărilor recente din cod prin review paralel cu trei agenți specializați: reuse, quality și efficiency.

Principiul lui este simplu: trei revieweri înguști bat un reviewer generalist. Fiecare caută adânc o clasă de probleme, cu diff-ul complet în față și cu acces la codebase, nu doar la bucata schimbată. Rulează în paralel, deci latența este apropiată de un singur review, nu de trei runde consecutive.

Rezultatul este o listă agregată de findings, cu duplicatele și sugestiile slabe eliminate. Skill-ul poate aplica fixuri, dar numai în limitele riscului: curățări sigure automat, schimbări atente cu verificare, schimbări riscante doar raportate pentru decizie umană.

All guides

Când îmi folosește

Îl folosești după ce ai modificat cod și vrei o curățare serioasă înainte de commit, PR sau handoff. Este potrivit când suspectezi duplicare, logică reimplementată, parametri adăugați peste funcții care trebuiau restructurate, state redundant, operații lente, citiri repetate, acces N+1, failure-uri înghițite tăcut sau slop generat de AI.

Nu se rulează automat după fiecare editare. Costă trei subagenți și are sens doar când ceri explicit review sau cleanup.

Este un pass de cleanup peste schimbările recente, nu o autorizație pentru refactorizarea întregului modul. Edits trebuie să rămână în zona atinsă de diff plus schimbarea minimă din jur necesară fixului.

Cum îl invoc / declanșez

Trigger-ele canonice sunt:

• simplify
• simplify my changes
• simplify these changes
• review my code
• review my recent changes
• clean up my changes
• /simplify

Poți adăuga modificatori:

• simplify focus on efficiency — rulează doar reviewerul de efficiency sau prioritizează findings-urile lui.
• simplify focus on reuse — rulează doar reviewerul de reuse sau prioritizează duplicarea și reutilizarea.
• simplify focus on quality — rulează doar reviewerul de quality sau prioritizează structura și mentenanța.
• simplify but don't change anything
• just report
• simplify staged
• simplify the last commit
• simplify this branch
• simplify src/foo.py

Scope-ul implicit este git diff. Dacă este gol, skill-ul verifică git diff HEAD, ca să includă și schimbările staged. Variantele explicite folosesc sursele cerute: git diff --staged, git diff HEAD~1, git diff main...HEAD sau git diff -- src/foo.py.

Dacă nu există diff, repo Git sau fișiere numite explicit, skill-ul trebuie să spună că nu are ce simplifica și să se oprească.

Exemplu practic

Ai lucrat pe un branch și scrii:

simplify my changes

Skill-ul identifică diff-ul relevant, notează dimensiunea lui și lansează reviewerii în paralel. Fiecare primește diff-ul complet și repo-ul, ca să poată căuta în codul existent.

Reviewerul de reuse caută funcții, helpers, constante sau pattern-uri deja existente care ar trebui folosite în locul logicii noi.

Reviewerul de quality caută state redundant, parameter sprawl, copy-paste cu variații, abstractions sparte, stringly-typed code, comentarii inutile, defensive checks fără rost și cast-uri care ocolesc type system-ul.

Reviewerul de efficiency caută muncă redundantă, citiri sau API calls repetate, operații independente rulate secvențial, hot-path bloat, TOCTOU, leaks, broad reads și failure-uri ignorate.

Fiecare finding trebuie să aibă formatul:

file:line → problem → suggested fix | confidence: high/medium/low | risk: SAFE/CAREFUL/RISKY

Output / unde aterizează

Output-ul este o listă deduplicată de findings, apoi un rezumat al fixurilor aplicate sau al celor lăsate pentru review.

SAFE se pot aplica automat când sunt dovedit fără impact de behavior: imports nefolosite, cod comentat, wrappers pasivi, type assertions redundante.

CAREFUL se aplică numai cu verificare: redenumiri locale, ternare aplatizate, helpers extrași, duplicări consolidate. Testele se rulează după schimbări, preferabil țintit pe fișierele atinse.

RISKY nu se aplică automat. Aici intră restructurări N+1, redenumiri de API public, schimbări de contract, concurrency sau lifecycle de memorie. Skill-ul le raportează cu motivul riscului și statusul test coverage.

Dacă ai cerut dry run prin just report sau don't change anything, skill-ul raportează toate tier-urile și nu modifică nimic.

Limite / gotchas

Dacă diff-ul este foarte mare, aproximativ peste 2000 de linii schimbate, skill-ul trebuie să avertizeze că review-ul va consuma mult context și să propună restrângerea scope-ului pe director, commit sau fișier.

Reviewerii trebuie să caute dovezi în codebase, nu să ghicească. Un finding de reuse fără pointer către utilitarul existent este zgomot și trebuie eliminat.

Pentru eliminări se aplică Chesterton’s Fence: înainte să fie șters ceva, trebuie verificat de ce există. Dacă scopul original nu este clar, confidence rămâne low.

Convențiile proiectului contează. Dacă repo-ul are fișiere de instrucțiuni sau configurări de lint/typecheck, acestea trebuie respectate.

Tool-urile de dead-code nu sunt probă finală. Exporturile pot fi folosite dinamic; înainte de ștergere trebuie căutat simbolul în codebase.

Contractele publice nu se redenumesc automat: exports, rute API, coloane de DB și chei de configurare sunt RISKY, chiar dacă numele pare prost.