r3xsean/see-it-through

Prenez une modification de code de la demande de l'utilisateur jusqu'à sa destination finale, avec un autre modèle comme réviseur. L'utilisateur décide deux fois : l'approche, au niveau de l'explicateur, et le résultat, au niveau du message de livraison. Tout le reste vous appartient.

L'autre modèle est le modèle le plus récent, dans orchestrator_capabilities, de la famille que l'utilisateur a nommée, avec l'effort qu'il a nommé. Le même modèle et le même effort exécutent chaque va-et-vient, boucle de code et revue ci-dessous, sauf pour un débat sur une décision clé. Si la famille ou l'effort est manquant, demandez-le et ne faites rien d'autre jusqu'à ce que l'utilisateur réponde.

Un runner défend l'approche à l'étape 3 à votre place (le runner du skill back-and-forth). Sauf si l'utilisateur nomme un runner : le modèle Fable le plus récent à effort moyen, débattant avec l'autre modèle ; pour une décision clé, le modèle Fable le plus récent à effort élevé, débattant avec le modèle Astra le plus récent à effort élevé à la place de l'autre modèle. Une décision clé est une décision où un déclencheur dans la question structurelle de design.md se déclenche et où vous pouvez énoncer une question dont la réponse pourrait changer l'approche. Lorsque le modèle d'un runner ou de son partenaire n'est pas disponible, dites-le et défendez l'approche vous-même avec l'autre modèle.

1. Destination et règles

Déterminez où aboutit la modification : une modification locale testée, une branche poussée, une PR ouverte, fusionnée ou déployée. Ne demandez que lorsque ce n'est pas clair et que la réponse change le travail. Dire « see it through » n'approuve aucune poussée, PR ou déploiement ; c'est l'approbation du message de livraison qui le fait.

Les règles du dépôt que vous modifiez, ainsi que tout fichier de processus que l'utilisateur vous indique, prévalent lorsqu'elles diffèrent de ce skill.

Une modification déjà construite. Lorsque l'utilisateur dit que la modification est déjà faite, ce qui est construit est l'approche, et le message de livraison est la première approbation : n'envoyez pas d'explicateur et n'exécutez pas de va-et-vient. À la place des étapes 2 et 3 :

• Épinglez la base : pour une branche non fusionnée, sa base de fusion avec la branche dans laquelle elle fusionne, prise après sa dernière fusion de cette branche ; une fois fusionnée, le commit précédant la modification. Demandez lorsque ce n'est pas clair. Lorsque la modification est déjà fusionnée, la destination est l'endroit où les commits de suivi de cette exécution vont ; demandez lorsque ce n'est pas clair.
• Rédigez la demande à partir des mots de l'utilisateur et de ce que la modification dit d'elle-même (messages de commit, texte de PR), en marquant ce que vous avez déduit.
• Trouvez les vérifications qui échouent sur un worktree de la base et réussissent sur la modification, en commençant par les tests que la modification a déjà (exécutez-les sur la base avec seulement les hunks de test et de harnais de la modification appliqués), et n'en écrivez un que pour un comportement promis qu'aucun d'eux ne prouve ; pour une modification sans échec à montrer, comme une accélération ou un refactoring, une vérification de ce qu'elle promet. Définissez le niveau comme à l'étape 2. Gardez comme base d'acceptation, comme l'étape 4 la garde, le plus petit nombre de ces vérifications qui prouvent chaque comportement promis par la modification, en notant lesquelles ont été écrites après la modification ; les autres tests de la modification restent ouverts pour simplify.md.
• Écrivez l'approche telle que construite dans un fichier : ce qui a changé, le grounding de design.md et sa question structurelle répondue pour ce qui est construit, et la vérification d'échec de l'étape 3.

Puis continuez à l'étape 4 en montrant la reproduction qui réussit, et donnez à cette base et à ce fichier la boucle de code comme son Approche. Le message de livraison indique qu'aucun explicateur n'a été approuvé, et porte toute alternative structurelle et tout résultat qui modifie ce que l'utilisateur obtient.

2. Reproduire

Pour un bug, reproduisez-le sur la base avant d'écrire un correctif : un test qui échoue, et, lorsqu'un utilisateur peut voir le bug, le produit en cours d'exécution le montrant, capturé comme le dit capture.md, manuellement lorsque le flux de vérification ne peut pas encore capturer. Pour une fonctionnalité, écrivez ce que l'utilisateur devrait voir ou pouvoir faire. Lorsque vous ne pouvez pas reproduire un bug, dites-le à l'utilisateur avant de construire un correctif, et écrivez tout ce que vous en dites comme « en lisant le code (non testé) ». Une vérification qui ne trouve rien ne compte qu'une fois que vous l'avez vue trouver la chose lorsqu'elle est présente.

Ne construisez aucune protection pour un chemin d'échec que vous n'avez pas reproduit ; listez-le dans l'explicateur comme un suivi à la place.

Reproduisez et prouvez via le skill de vérification du dépôt : .agents/skills/verify/ dans le dépôt, ou là où le AGENTS.md du dépôt le place. Lorsqu'il n'y en a pas, ou qu'il ne couvre pas le flux dont vous avez besoin, reproduisez manuellement pour l'instant et faites de la construction de cette couverture avec le skill make-verifiable une partie de l'approche.

Définissez ensuite le niveau. Complet lorsque le comportement modifié atteint la persistance, la concurrence, l'autorisation, les migrations, un contrat public, des effets destructeurs ou la propriété d'état partagé, ou lorsque vous ne pouvez pas encore dire comment le code modifié est atteint ou à quel point les tests le couvrent ; jugez par les appelants et les rédacteurs d'état que vous trouvez, pas par les noms de fichiers. Léger autrement. Une exécution légère qui révèle l'un de ces éléments devient complète.

3. Conception et l'explicateur

Lisez design.md et faites ce qu'il demande avant de choisir une approche. Dans une exécution complète, faites des va-et-vient avec le modèle sur l'approche (le skill back-and-forth), avec les estimations de proportion de design.md dans son Contexte comme prémisses à vérifier et une version plus petite et aucun changement parmi les options ; dans une exécution légère, ne le faites que lorsque les déclencheurs de design.md se déclenchent ou que les approches fortes diffèrent matériellement, et sinon écrivez l'approche vous-même. Donnez au runner, dans le Contexte, votre grounding avec ses références, ce que vous avez reproduit et ce que vous avez seulement lu, et un chemin pour son enregistrement dans le scratchpad ou le dossier temporaire de la session ; dans la Question, que vous écrivez à partir de la demande, demandez également où la modification atterrit, y compris les appelants et les cas frères, les cas d'acceptation, et ce qu'elle vous laisse. Lorsqu'une question de conception est un fait que vous pourriez observer en exécutant quelque chose, réglez-la avec une expérience jetable dans un checkout isolé ou des données de brouillon, pas en demandant à l'utilisateur ; l'expérience ne livre rien.

Écrivez ensuite la vérification d'échec : parcourez les Conditions dans l'en-tête bref du skill code-loop, plus ceux qui dépendaient du comportement que vous modifiez, et pour chacun qui s'applique, nommez le test qui le couvrira ou la limitation que vous acceptez.

Envoyez à l'utilisateur l'explicateur, en langage clair, sous ces titres, dans l'ordre. Dites chaque chose une fois.

• Le problème : ce qu'un utilisateur voit aujourd'hui, qui le rencontre et à quelle fréquence (observé ou estimé ; aucun rapport signifie inconnu, pas rare), pourquoi c'est important, et votre reproduction, avec sa capture quand elle en a une ; pour une fonctionnalité, ce qui manque aujourd'hui. Lorsque l'utilisateur a demandé la modification, commencez par ses mots.
• Pourquoi cela se produit : la cause, en termes simples ; pour une fonctionnalité, ce qui fait obstacle aujourd'hui. Laissez ce titre de côté pour une fonctionnalité lorsque rien ne fait obstacle.
• Ce qui change : ce que l'utilisateur verra ou pourra vérifier une fois terminé, et ce qui est hors de portée. Là où quelque chose qui changerait le travail manque, demandez-le ici.
• L'approche : ce qui change dans le code et où, comment vous allez le prouver, y compris tout travail de make-verifiable et quelles vérifications sont livrées avec la modification ou restent comme preuve, ce qu'il coûte à livrer et à maintenir et pourquoi cela vaut la portée et le préjudice sous Le problème, et les entrées de vérification d'échec qu'un réviseur jugerait pertinentes.
• Alternatives pesées : chaque alternative forte, l'option structurelle de design.md parmi elles chaque fois qu'une option crédible existe, chacune avec pourquoi elle a perdu.
• Ce qu'un réviseur pourrait demander : chaque question probable, avec sa réponse.

Puis arrêtez-vous : ne construisez rien tant que l'utilisateur n'a pas approuvé. Une approbation simple, quelle que soit sa formulation, vous permet de construire. Tout le reste va mot pour mot dans le même va-et-vient en tant qu'échange supplémentaire, au-delà de sa limite d'échange, et revient sous forme d'explicateur révisé ; arrêtez-vous à nouveau. Dans une exécution légère sans va-et-vient, révisez l'explicateur vous-même et arrêtez-vous à nouveau.

L'approbation couvre l'explicateur tel qu'écrit. Lorsqu'un test, une démo ou une revue modifie ce que l'utilisateur obtient, son comportement visible, sa compatibilité, sa portée, l'action que vous entreprendrez pour le livrer, ou un compromis que l'explicateur a accepté, citez la phrase qu'il falsifie, travaillez-la avec le modèle, envoyez un explicateur révisé qui dit ce qui a changé, et arrêtez-vous à nouveau. Les découvertes plus petites, comme l'utilisation d'un assistant interne différent, vont dans le message de livraison « ce qui a changé depuis ».

4. Construire et prouver

Avant de modifier le comportement, conservez la reproduction et chaque vérification d'acceptation qui peut s'exécuter avant l'existence de la modification : commitez celles que l'explicateur livre, et sauvegardez le reste, ou toutes lorsqu'aucune ne sera commise, sous forme de correctif en dehors du dépôt. Ensemble, ils constituent la base d'acceptation, et tout s'exécute à nouveau sur le candidat final : toute modification ultérieure va à la boucle de code et au message de livraison avec son diff et si elle modifie le comportement promis.

Construisez l'approche approuvée, dans l'ordre fixé par design.md. Lorsque la modification altère un flux que le skill de vérification couvre, mettez à jour ce flux dans la même modification. Montrez la reproduction de l'étape 2 qui réussit, via le skill de vérification et dans le produit en cours d'exécution lorsque l'utilisateur peut le voir. Simplifiez ensuite le diff comme le dit simplify.md. Exécutez ensuite une boucle de code avec le modèle sur le diff complet (le skill code-loop), en lui donnant la demande de l'utilisateur, ou le bref qui en tient lieu, comme Demande, l'explicateur comme Approche, avec l'enregistrement du runner lorsqu'il y en a un, la base d'acceptation comme Acceptation, et le niveau.

Sur le candidat final, lorsqu'un utilisateur peut voir ou faire ce qui a changé, capturez-le via le flux de vérification, en étendant le flux avec make-verifiable lorsqu'il ne le peut pas, et pour un bug, capturez le même scénario sur la base via le même flux, afin que l'avant et l'après correspondent. Choisissez, faites et révisez la capture comme le dit capture.md, et vérifiez qu'elle montre ce que vous direz qu'elle montre. Une capture montre la modification et les vérifications la prouvent, donc une capture de la base ou d'une exécution échouée ne vaut jamais comme une réussite. Une modification sans rien à voir n'obtient pas de capture.

5. Rédaction

Rédigez le texte de la PR, du problème ou de la version à partir des modèles du projet, avec les captures là où le modèle a de la place pour elles, ou sous un titre qui leur est propre. Sur GitHub, attachez-les lorsque vous publiez avec gh pr create --attach (ou gh pr edit) sauf si le dépôt a son propre outil ; lorsqu'il se termine avec un code non nul, cherchez la PR avant de réessayer, car elle peut déjà exister. Avant que tout texte public énonçant un fait ne soit diffusé (une description, une réponse, une mise à jour de statut), un nouveau réviseur du modèle le vérifie par rapport aux preuves, aux captures (un enregistrement avec ses images et son rapport de rythme) et au diff : chaque affirmation vraie et étayée, chaque case cochée vraie. Supprimez une affirmation que la preuve ne soutient pas ; ne la nuancez pas.

Avant chaque poussée, réexécutez la vérification derrière chaque case cochée et chaque affirmation, et refaites chaque capture, que la modification depuis pourrait affecter.

6. Message de livraison

Envoyez à l'utilisateur : un résumé de deux ou trois phrases de l'explicateur, ce qui a changé depuis, les preuves, les captures, la rédaction, le diff, et l'action exacte que vous entreprendrez sur approbation. Lorsque la boucle de code s'est terminée avec des différends non résolus, commencez par eux : chaque affirmation, ce que chaque partie a montré, et ce que l'approbation livre avec elle. Avant de l'envoyer, refaitez la vérification de chevauchement de design.md. Arrêtez-vous jusqu'à ce que l'utilisateur l'approuve.

7. Jusqu'à la destination

Prenez l'action approuvée, puis amenez la modification à sa destination :

• Avant chaque poussée et avant d'agir sur une notification, récupérez la tête distante et vérifiez le statut actuel de la modification. Construisez sur les poussées des autres, en comparant les arbres plutôt que les hachages de commit ; ne remplacez pas leur travail par une version locale obsolète. Lorsque la modification atterrit, se ferme ou est remplacée par la version de quelqu'un d'autre, comparez ce qui a atteint la destination avec votre dernière tête vérifiée et les résultats ouverts. Signalez ce qui diffère ou n'a pas abouti, sans rajouter ce qu'ils ont supprimé intentionnellement.
• Chaque constat de revue, en ligne ou dans le corps d'une revue, lu en entier, obtient un correctif ou une raison d'une ligne ; celui qui se produit également sur la base est jugé comme code-loop juge un constat préexistant. Un correctif qui modifie le comportement obtient une boucle de code.
• Lorsqu'un fait prouve qu'un texte publié est erroné, corrigez le texte.
• Une demande qui modifie la portée ou l'approche retourne à l'étape 3 et, une fois construite, à un nouveau message de livraison ; une demande qui s'applique au-delà de cette modification va à l'utilisateur lorsqu'elle arrive, avec son lien : le faire ici ne le fait pas ailleurs.
• Pour un déploiement, exécutez le flux de vérification contre ce qui est déployé.

8. Leçons

Lorsque l'utilisateur, un réviseur de PR ou quoi que ce soit après la livraison a attrapé un problème que la boucle de code a manqué, ou que la boucle de code a trouvé un bloqueur ou aurait dû, ajoutez une entrée à .agents/lessons/log.md dans le dépôt que vous avez modifié ; pour un dépôt que l'utilisateur ne possède pas, dans le dossier qui contient son processus pour celui-ci. Chaque entrée : la date, la modification, ce qui a été attrapé et par qui, le module, la classe de bug, et la cause.

Lisez ensuite le journal. Une leçon qu'une vérification pourrait attraper, vue deux fois, devient une vérification de lint, de type, de test ou de vérification ; une qui nécessite du jugement, vue deux fois, devient une ligne dans le AGENTS.md du dépôt ; deux entrées dans un module, ou deux d'une classe de bug dans n'importe quels modules (comme un état qu'une autre opération modifie pendant une attente), deviennent une question structurelle, nommant la cause qu'elles partagent avant que tout refactoring soit proposé. Listez chacune comme un suivi dans votre message final ; un refactoring s'exécute comme son propre see-it-through.

Terminé lorsque la modification est à sa destination, ou lorsque vous avez signalé le bloqueur exact et ce qui reste, et que l'entrée de leçon, si elle est due, est écrite.