Communitygithub.com

Gentleman-Programming/gentle-ai-rdd-defect-workflow

Déclencheur : RDD (développement piloté par les reçus), autorité de revue, reçu/linéage, correction/récupération, passerelle de livraison/interrupteur d'arrêt, défauts de revue bornés. Guide le travail.

Qu'est-ce que gentle-ai-rdd-defect-workflow ?

Ce skill implémente un workflow de correction de défauts piloté par les reçus (Reçu-Driven Development ou RDD) pour les agents IA. Il permet de guider la résolution de bugs en s'appuyant sur des preuves de revue, une cartographie d'impact via CodeGraph, et un respect strict des limites de modification. Le skill est conçu pour les plateformes d'agents comme Claude Code, Cursor ou Codex. Il fonctionne en définissant des invariants causaux, en isolant les corrections dans des worktrees dédiés, et en exigeant des preuves de test jour réel (bench journey ou E2E) avant toute validation. Il ne confère jamais d'autorité de livraison (commit, push, PR) : la politique du dépôt reste souveraine, même en mode RDD.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Gentleman-Programming/gentle-shell/tree/main/skills/rdd-defect-workflow

Demander à votre IA préférée

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

Documentation

Contrat d'activation

Charger lorsque les termes déclencheurs du frontmatter s'appliquent à un workflow de défaut.

Ce skill guide la collaboration publique. Il n'accorde aucune autorité d'approbation, d'étiquetage, de revue, d'exception ou de fusion d'issue.

Règles strictes

  • Les preuves de la revue et du Judgment Day sont réservées à la revue. Pi ne délivre jamais d'autorité de livraison : les commits, pushs, PR et mises en production ordinaires suivent toujours la politique du dépôt, quel que soit le mode RDD.
  • Exiger une issue approuvée (status:approved) et une reproduction nette sur main avant l'implémentation. Auditer les PR existantes pour détecter une supplantation ou un conflit ; arrêter ou restreindre les revendications obsolètes.
  • Grouper par invariant causal. Utiliser une issue et une PR (ou une chaîne explicite) par invariant indépendant et par frontière de rollback. Séparer les causes indépendantes ; ne jamais fusionner une ligne d'autorité supplantée ou conflictuelle.
  • Inventorier tous les flux d'opérateurs revendiqués par l'issue ou la PR, y compris l'entrée, le mode, l'environnement, l'attente et les contrôles négatifs. Exiger un parcours de bench "boîte noire" véridique par flux CLI ou cycle de vie, ou une preuve E2E d'exécution réelle lorsque le bench de base ne peut pas le représenter. La couverture proxy synthétique ne prouve jamais une autre exécution.
  • Utiliser une cartographie d'impact prioritaire via CodeGraph, un worktree dédié et des tests orientés comportement. Exécuter une normalisation mutante du code source avant le gel du candidat.
  • Prévoir les modifications avant les éditions. La limite stricte est de 400 ajouts + suppressions ; au-delà, ARRÊTER pour une chaîne ou une exception explicite approuvée par le mainteneur.
  • Lorsque RDD est activé, lier les reçus de revue, le linéage, la correction et les preuves de récupération au candidat exact. Conserver les défauts de revue bornés dans une seule transaction de correction ; ne jamais traiter cette preuve comme une autorité de livraison.
  • Exiger une validation indépendante en lecture seule avant la publication. La validation ne peut pas modifier le code source ou l'autorité ; les constatations nécessitent un nouveau candidat.
  • Garder la communication humaine et fondée sur les preuves. Les étiquettes de dépôt et les métadonnées de workflow appartiennent au mainteneur, elles ne sont jamais une preuve de faute du contributeur.

Portes de décision

ConditionAction
Tout mode RDDLes preuves de revue restent réservées à la revue ; les commits, pushs, PR et mises en production ordinaires suivent la politique du dépôt sans autorité de livraison de Pi.
Porte d'issue ou reproduction échoueAttendre, arrêter ou restreindre avec preuves.
Invariant ou rollback indépendantSéparer l'issue et la ligne de PR faisant autorité.
Le bench de base correspond / ne correspond pasParcours de bench / E2E réel ; jamais de proxy.
Prévision dépasse 400 lignesChaîne ou exception approuvée avant les éditions.

Étapes d'exécution

  1. Vérifier le mode, l'approbation, les conflits de PR et la reproduction sur main actuel.
  2. Nommer l'invariant et le rollback ; isoler le worktree ; cartographier avec CodeGraph le code, les tests, les preuves, la documentation, la distribution et l'enregistrement.
  3. Inventorier les flux et les contrôles ; ajouter les tests en échec et la plus petite correction.
  4. Normaliser, respecter le budget, exécuter les tests et enregistrer pour chaque flux le candidat exact, la commande, le scénario et le résultat.
  5. Geler, valider en lecture seule et fournir le verdict, les preuves et une prochaine action humaine.

Contrat de sortie

Retourner rdd_mode, issue_pr, causal_invariant, operator_flows, journey_runtime_evidence, changed_line_budget, tests, rollback et unresolved_authority_decisions.

Identifier les lignes d'autorité approuvées et supplantées/conflictuelles ; chaque flux, contrôle négatif et preuve liée au candidat ; les ajouts + suppressions et la chaîne/exception ; les résultats de test ; le rollback indépendant ; et les décisions non résolues du mainteneur.

Références

Aucun fichier d'accompagnement. La politique actuelle du dépôt reste souveraine.

Individual skills in this repo

This repo contains 7 individual skills — each has its own dedicated page.

Skills associés