improve

# improve — auditer avec un modèle puissant, exécuter avec des modèles économiques `improve` est une compétence d'agent (format Agent Skills) qui audite n'importe quel codebase et rédige des plans d'implémentation pour d'autres agents. Le principe : consacrer votre modèle le plus performant à la partie où l'intelligence se capitalise — comprendre le codebase, juger ce qui vaut la peine, rédiger la spécification — et confier l'exécution à des modèles moins chers. La compétence n'implémente jamais rien elle-même ; le plan est le produit. ``` vous → /improve (modèle coûteux, conseille) plans/ → 001-fix-n-plus-one.md (spécifications autonomes) autre agent → implémente, teste, livre (modèle économique, exécute) ``` ## Installation ```bash npx skills add shadcn/improve ``` Cela fonctionne avec tout agent prenant en charge le format Agent Skills. Les plans sont en Markdown simple, donc tout agent ou humain peut les reprendre. ## Commandes - `/improve` — audit complet → résultats priorisés → plans - `/improve quick` — passage économique : points chauds, résultats principaux uniquement - `/improve deep` — exhaustif : chaque paquet, chaque catégorie - `/improve security` — audit ciblé (aussi perf, tests, bugs, ...) - `/improve branch` — auditer uniquement ce que la branche actuelle modifie - `/improve next` — suggestions de fonctionnalités, où mener le projet - `/improve plan <description>` — sauter l'audit, spécifier une chose - `/improve review-plan <file>` — critiquer et affiner un plan existant - `/improve execute <plan>` — lancer un exécuteur économique, examiner son travail - `/improve reconcile` — rafraîchir le backlog : vérifier, débloquer, retirer - `--issues` — publier aussi les plans comme issues GitHub ## Premier lancement typique 1. Ouvrez votre agent dans le dépôt et lancez `/improve` (ou `/improve quick` pour rester économique). 2. Il cartographie le dépôt, l'audite et renvoie un tableau de résultats. Répondez avec ceux que vous voulez planifier, par ex. "plan 1, 3 et 5". 3. Les plans arrivent dans `plans/` — un fichier chacun, plus un index avec l'ordre recommandé. Ils sont destinés à être examinés. 4. Confiez un plan à n'importe quel agent ("implémente plans/001-*.md"), ou laissez la compétence l'exécuter : `/improve execute 001` lance un modèle moins cher dans un worktree isolé, examine le diff par rapport au plan et rend un verdict. La fusion reste votre décision. 5. À la session suivante, `/improve reconcile` nettoie le backlog : vérifier ce qui a été livré, rafraîchir ce qui a dérivé, débloquer ce qui est resté coincé. Avant une PR, `/improve branch` limite le même processus à ce que la branche modifie. ## Comment cela fonctionne - **Reconnaissance.** Cartographie le dépôt : pile, conventions et commandes exactes de build/test/lint, qui deviennent des portes de vérification dans chaque plan. Il ingère aussi les documents d'intention et de conception quand ils existent — ADR (`docs/adr/`), PRD, `CONTEXT.md`, `DESIGN.md`, `PRODUCT.md` — afin que les compromis décidés ne soient pas re-signalés, que les suggestions de direction restent ancrées dans l'intention produit déclarée et que les plans utilisent le vocabulaire propre du dépôt. - **Audit.** Déploie des sous-agents parallèles sur neuf catégories : exactitude, sécurité, performance, couverture de tests, dette technique, dépendances et migrations, DX, documentation et direction (les suggestions de fonctionnalités doivent citer des preuves du dépôt lui-même). Chaque résultat porte une preuve `fichier:ligne`, un impact, un effort et une confiance. - **Vérification.** Parce que les sous-agents sur-signalent, le conseiller relit chaque emplacement cité avant de montrer quoi que ce soit ; les faux positifs sont écartés, les attributions erronées corrigées, les rejets enregistrés. - **Priorisation.** Les résultats arrivent dans un tableau ordonné par effet de levier (impact ÷ effort, pondéré par la confiance). Vous choisissez ce qui devient des plans. - **Planification.** Un fichier par résultat sélectionné dans `plans/`, avec un index, un ordre de priorité et un graphe de dépendances. ## Ce qui rend les plans exécutables Les plans ciblent l'exécuteur plausible le plus faible — un modèle qui n'a jamais vu la session du conseiller et qui peut être beaucoup plus petit. Trois propriétés portent cela : - **Autonome.** Tout le contexte est intégré : chemins de fichiers exacts, extraits de code de l'état actuel, conventions du dépôt avec un fichier exemplaire, commandes vérifiées. Pas de "comme discuté ci-dessus". - **Portes de vérification.** Chaque étape se termine par une commande et sa sortie attendue ; les critères de fin sont vérifiables par machine, donc l'exécuteur n'a jamais à juger du succès. - **Limites strictes.** Listes explicites hors périmètre et conditions STOP ("si X, arrête et signale") au lieu de laisser un petit modèle improviser quand la réalité ne correspond pas au plan. Chaque plan estampille le commit git sur lequel il a été rédigé, afin que les exécuteurs puissent faire une vérification mécanique de dérive avant de toucher quoi que ce soit. ## Boucler la boucle - **`execute <plan>`** lance un sous-agent exécuteur moins cher dans un worktree git isolé, lui confie le plan, puis examine le résultat comme un lead technique — relance chaque critère de fin, vérifie la conformité au périmètre, lit le diff par rapport à l'intention. Verdict : approuver (la fusion reste votre décision), renvoyer pour révision (2 tours max), ou bloquer et affiner le plan. - **`reconcile`** traite ce qui s'est passé depuis : vérifie que les plans DONE tiennent toujours, enquête sur les BLOCKED et les réécrit autour de l'obstacle, rafraîchit les plans dérivés, retire les résultats corrigés indépendamment. - **`--issues`** publie les plans comme issues GitHub avec le même corps autonome, afin que tout agent ou humain puisse les reprendre là où le travail vit déjà. ## Règles strictes - Ne modifie jamais le code source lui-même. Les seules écritures vont dans `plans/` ; les exécuteurs ne modifient que dans des worktrees jetables, et la fusion est toujours votre décision. - N'exécute jamais de commandes qui modifient l'arbre de travail — lecture, recherche et analyse en lecture seule uniquement. - Ne reproduit jamais de valeurs secrètes ; uniquement les emplacements et types d'identifiants, la rotation est toujours recommandée. - Si on lui demande d'implémenter, il décline et pointe vers le plan (ou propose `execute`). ## Licence MIT © shadcn