CommunityRédaction et éditiongithub.com

Pit-Stop

Pit-stop F1 pour codebases : une seule instruction exécute lire, trouver, corriger, vérifier, rapporter.

Qu'est-ce que Pit-Stop ?

Pit-Stop est une compétence d'agent IA conçue pour nettoyer et améliorer rapidement une codebase en une seule passe automatisée. Elle fonctionne comme un arrêt au stand en F1 : l'utilisateur donne une instruction unique, et l'agent enchaîne les étapes **lire → trouver → proposer → corriger → rapporter** sans poser de questions intermédiaires. L'utilité principale est de réduire les allers-retours et de garantir une exécution fiable et reproductible. La compétence s'appuie sur des règles strictes (evidence avant toute affirmation, pas de push automatique, seuil de coût pour éviter les dépassements) et gère les cas flous en demandant une intervention humaine. Elle est conçue pour les agents comme Claude Code, Cursor ou Codex, et se configure via des fichiers de référence (`references/phases.md`, `references/guardrails.md`, `references/verification.md`).

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add Finn763/pit-stop

Installed? Explore more Rédaction et édition skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

Documentation

Que fait Pit-Stop ?

Pit-stop F1 pour codebases : entrez, faites réparer, ressortez plus rapide. Une seule instruction exécute lire → trouver → corriger → vérifier → rapporter sans questions en cours de route. L'utilisateur donne le feu vert ; vous revenez une fois avec un rapport.

Le déroulement (dans l'ordre, sans saut)

  1. Charger : lire README/AGENTS.md (ou équivalent) + git status + zones chaudes des commits récents. Écrire une ligne en premier : MODE = ce qui compte comme constat ici, ce qui est rejeté d'office. Il manque un fait clé ? Demander UNE FOIS, puis poursuivre avec les valeurs par défaut les plus strictes.
  2. Trouver : délimiter avant de scanner (cible nommée > zones chaudes git > arbre complet). Chaque constat nécessite une preuve chemin:ligne. Ignorer les décisions enregistrées sauf si une friction justifie leur réouverture. Étiqueter chaque élément : delete/stdlib/native/yagni/shrink/security/obs, force Strong/Worth/Speculative. Spéculatif = rapport uniquement, jamais de correction. Rien trouvé : dire Lean already. Ship. — jamais de remplissage.
  3. Proposer : uniquement les éléments forts. Chacun = symptôme + preuve + impact + correction minimale + coût. Plus une liste de ce qui N'EST PAS fait avec ses conditions de déclenchement.
  4. Corriger : boucle revue→correction avec un relecteur indépendant (angle différent bat les mêmes yeux) ; s'arrêter à un état propre ou --max-rounds (par défaut 3). Registre inter-tours, pas de corrections répétées. Deux tours stagnants → escalader vers « nécessite un humain », arrêter. Voir references/guardrails.md.
  5. Rapport : en-tête Généré entièrement automatiquement par pit-stop. Quatre blocs — modifié / vérifié (sortie d'outil) / non vérifié / restant. Aucune affirmation sans sortie fraîche d'outil. Suppression des secrets/tokens/PII dans tout ce qui est collé. Voir templates/report.md.

Lois de fer

  • Preuve avant affirmation, toujours. Pas d'exécution de vérification dans ce tour = pas d'affirmation de succès.
  • Le « fait » d'un sous-agent n'est pas fait. Lire son diff avant de rapporter.
  • Les zones floues sont rétrogradées, jamais devinées. Écrire « nécessite un humain », continuer.
  • Push/commit jamais automatique. Les modifications attendent dans le répertoire de travail un seul mot explicite.
  • Fusible de dépense unique : une phase brûlant plus de 20 $ → arrêter la phase, écrire le rapport.

Détails : references/phases.md, references/guardrails.md, references/verification.md.

Skills associés