code-review

Code Review

Objectif

Analyser du code modifie (commit, branche, fichiers, diff non-committe) et produire un rapport structure des problemes detectes en se basant sur les regles koulia.

Input parametrable

• Commit specifique : /code-review --commit abc123
• Plage de commits : /code-review --commits abc123..def456
• Branche entiere (diff vs main) : /code-review --branch feature/xxx
• Fichiers specifiques : /code-review src/components/MyComponent.tsx
• Sans parametre : analyse le diff non-committe (staged + unstaged)

Workflow

Etape 1 — Recuperer le diff

Selon le mode choisi, executer la commande git appropriee :

• Sans parametre : git diff (unstaged) + git diff --staged (staged)
• --commit abc123 : git show abc123
• --commits abc123..def456 : git log -p abc123..def456
• --branch feature/xxx : git diff main...feature/xxx
• Fichiers specifiques : git diff -- <fichiers> ou lire directement les fichiers

Etape 2 — Lister les fichiers modifies

Produire un resume des fichiers modifies avec :

• Nom du fichier
• Type de modification (ajout, modification, suppression)
• Resume court du changement

Etape 3 — Charger les regles koulia

Identifier le(s) stack(s) concerne(s) a partir des extensions de fichiers et de la structure du projet, puis charger :

• ~/koulia/common/naming-conventions.md
• ~/koulia/common/code-style-rules.md
• ~/koulia/technos/{stack}/code-style.md
• ~/koulia/technos/{stack}/patterns/*.md (seulement les patterns pertinents)

Etape 4 — Analyser chaque modification

Pour chaque fichier modifie, verifier :

• Respect des conventions de nommage
• Respect du code style du stack
• Respect des patterns koulia (structure, organisation, types)
• Absence de bugs evidents, failles de securite, regressions
• Coherence des types et des imports
• Qualite generale du code

Classer chaque probleme selon les niveaux de severite definis dans references/severity-levels.md.

Etape 5 — Produire le rapport

Generer le rapport au format defini dans references/report-template.md. Le rapport inclut :

• Resume global
• Problemes classes par severite (CRITIQUE, HAUTE, MOYENNE, BASSE)
• Points positifs
• Actions recommandees

Etape 6 — Proposer la correction

A la fin du rapport, proposer au user d'utiliser /fix-review-code pour corriger automatiquement les problemes detectes.

Principes

• Exhaustivite : ne pas ignorer de fichier modifie.
• Precision : chaque probleme doit citer le fichier, la ligne et la regle violee.
• Equilibre : mentionner aussi ce qui est bien fait (points positifs).
• Actionnable : chaque probleme doit avoir une suggestion de correction.
• Non-bloquant : les problemes de severite BASSE sont des suggestions, pas des blockers.