imaginaerumai/field-tested-skills

Pilote principal (Principal autopilot)

Origine. Original de ce dépôt, construit sur le travail d'autres personnes. Les règles d'autonomie, le style de réponse, les principes et les playbooks sont adaptés du poteto-mode de Lauren Tan (MIT). Les étapes de grillade, de diagnostic et de rétrospective chargent les compétences de Matt Pocock depuis mattpocock/skills (MIT). Nouveau ici : formulation qui fonctionne dans n'importe quel agent, amorçage des compagnons, une barrière de taille, une barrière d'auto-examen avant le code, et les étapes de simplification et de nettoyage avec critères de sortie. Chaque partie empruntée et chaque changement est listé dans references/lineage.md.

0. Amorçage (une fois par session)

Dites principal-autopilot: on dans votre première réponse. Chargez unslop maintenant. Ses règles s'appliquent à chaque phrase que vous écrivez cette session, y compris les todos, les commentaires et les messages de commit. Écrivez proprement en rédigeant. Un passage de nettoyage après la rédaction ne supprime pas les motifs.

Vérifiez votre liste de compétences par rapport aux compagnons :

Compagnon	Nécessaire quand	Étape
grilling	toujours	3
unslop	toujours	0
retro	toujours	10
diagnosing-bugs	un bug, un échec ou une régression	2
handoff	le contexte s'épuise, ou la session se termine en cours de tâche	n'importe
writing-for-agents	modification d'une compétence, de AGENTS.md ou CLAUDE.md	4
humanizer	prose destinée aux humains plus longue qu'une réponse	4
agent-browser, purge-stress	la tâche utilise un navigateur	5, 8

Installez uniquement les manquantes, dans le projet actuel, épinglées sur une version :

npx skills add imaginaerumai/field-tested-skills#v1.0.0 -y -s <noms manquants, séparés par des espaces>

Ceci est une installation dans le projet que l'utilisateur peut supprimer. Signalez-la en une ligne. Installez globalement (-g) uniquement si l'utilisateur le demande. Si une nouvelle compétence n'apparaît pas dans votre liste de compétences, lisez son SKILL.md depuis le chemin d'installation pour cette session. Si l'installation échoue, dites-le en une ligne et continuez avec ce fichier seul.

1. La boucle

Évaluez d'abord la taille de la tâche. Un seul fichier, moins d'environ 30 lignes modifiées, et une vérification évidente : exécutez les étapes 2, 4, 5 et 9, et listez les autres comme skip: small. Tout le reste nécessite les dix étapes.

Ouvrez une liste de tâches avec les étapes ci-dessous copiées textuellement, avant tout élément spécifique à la tâche. Si votre agent n'a pas d'outil de liste de tâches, écrivez la liste dans votre première réponse. Une étape que vous sautez reste dans la liste comme skip: <reason>. Choisissez le playbook à l'étape 1. Il modifie la signification de certaines étapes.

1. Cadrer. Une phrase chacun : le résultat, qui le remarque, la vérification qui le prouve. Choisissez le playbook dans references/playbooks.md. Fait quand : vous pouvez nommer la vérification de preuve. Si vous ne le pouvez pas, lisez plus avant de demander quoi que ce soit.

2. Lire avant d'écrire. Trouvez le code, la configuration et les docs qui possèdent ce comportement. Nommez la forme de donnée que le changement touche avant toute logique. Pour un bug, chargez diagnosing-bugs et construisez une boucle qui devient rouge sur ce bug. Fait quand : vous pouvez dire où vit le comportement, quelle est la forme de donnée, et ce qui l'appelle.

3. Auto-examen. Chargez grilling et appliquez son arbre de conception et sa frontière à votre propre plan. Vous êtes l'interviewé. Répondez à chaque question de fait avec des preuves : lisez, exécutez, mesurez. Lorsqu'une bifurcation concerne le comportement, la disposition ou la vitesse, construisez une esquisse jetable de chaque option et décidez d'après ce que vous observez. Écrivez ensuite l'objection la plus forte à la prémisse du plan et répondez-y avec des preuves, ou changez le plan. Ignorez les règles d'attente et de confirmation de grilling, sauf pour les appels de préférence qu'aucune expérience ne peut trancher. Ceux-ci vont à l'utilisateur en un seul lot, chacun avec votre réponse recommandée. Fait quand : la frontière est vide et l'objection à la prémisse est répondue.

4. Construire le plus petit changement. Supprimez le code mort et les références obsolètes que le changement touche, puis ajoutez le moins de code qui passe la vérification de l'étape 1. Un seul appelant signifie pas d'abstraction. Un cas non observé signifie pas de drapeau, paramètre ou garde. Fait quand : le diff fait le travail et rien d'autre.

5. Prouvez-le. Exécutez l'artefact réel sur la surface que l'utilisateur touche : le test, la CLI, la page, l'API. Préférez un script qui revérifie le résultat plutôt qu'un regard unique. Pour un bug, montrez la même vérification en rouge avant le correctif et en vert après. Fait quand : vous avez une sortie que vous pouvez coller. Compiler, "devrait fonctionner" et le rapport d'un sous-agent ne sont pas une preuve.

6. Défier. Relisez le diff complet en tant que son critique le plus sévère. Demandez ce que cela casse d'autre : appelants, configuration, données persistées, autres plateformes, concurrence. Listez ce que vous avez supposé et n'avez pas vérifié, puis vérifiez-le. Si votre agent peut engendrer des sous-agents, donnez à l'un d'eux uniquement l'objectif et le diff et demandez les objections les plus fortes. Corrigez ou réfutez chacune avec des preuves. Fait quand : chaque conclusion est corrigée ou réfutée par écrit.

7. Simplifier. Demandez ce que vous pouvez supprimer et toujours passer l'étape 5. Intégrez les fonctions d'assistance à un seul appelant, supprimez les branches mortes et les options spéculatives, fusionnez la logique dupliquée. Réexécutez l'étape 5. Fait quand : un passage de suppression n'a rien trouvé, ou a trouvé quelque chose et l'étape 5 est à nouveau verte.

8. Nettoyer. Supprimez les sorties de débogage, les fichiers temporaires, les esquisses de l'étape 3 et les processus que vous avez démarrés. Pour les navigateurs, exécutez agent-browser close, puis la simulation à sec de purge-stress. Gardez un commentaire uniquement pour un pourquoi non évident. Les scripts de test et de vérification n'ont pas de commentaires narrant les phases. Le message d'assertion nomme l'étape. Cela s'applique à chaque fichier que vous produisez, y compris le diff d'un sous-agent. Fait quand : vous avez listé chaque fichier, branche et processus que vous avez créé, et chacun est supprimé ou nommé dans la réponse comme intentionnellement laissé.

9. Rapporter. Écrivez la réponse conformément à Rédiger la réponse. Ne dites pas fait tant que chaque étape n'a pas son "fait quand" ou une raison skip:. Fait quand : chaque affirmation dans la réponse porte sa preuve ou son étiquette.

10. Rétrospective. Après une session substantielle (un retour en arrière, une correction de l'utilisateur, ou plus d'environ 40 appels d'outils), chargez retro. Transformez chaque erreur répétée en une vérification (lint, test, règle de validation, script) avant d'écrire une règle en prose. Fait quand : chaque constat est appliqué, classé ou abandonné avec une raison.

Revenir en arrière

Lorsqu'une étape échoue, revenez à l'étape la plus ancienne dont l'hypothèse a été brisée. Une preuve échouant à l'étape 5 causée par une forme de donnée erronée revient à l'étape 2, pas à l'étape 4.

Lorsque deux correctifs partageant une même prémisse échouent à la même vérification, arrêtez de corriger. Écrivez la prémisse en une phrase. Trouvez une observation qui serait différente si la prémisse était fausse, faites-la, et continuez à partir de ce qu'elle montre.

Lorsque le contexte s'épuise, chargez handoff avant qu'il ne soit trop tard.

2. Non-négociables

• Preuve ou étiquette. Chaque affirmation factuelle est étayée par quelque chose que vous avez lu ou exécuté cette session, ou porte measured, inferred ou guess dans la même phrase. N'inventez jamais de nombres, drapeaux, API ou comportement.
• Liens que vous avez ouverts. Liez uniquement à ce que vous avez lu ou produit cette session.
• Les faits sont votre travail. Ne demandez jamais à l'utilisateur quelque chose que vous pouvez lire, exécuter ou mesurer, et ne leur remettez jamais une vérification que vous pourriez exécuter. Les décisions leur appartiennent.
• Causes profondes. Chaque garde, relance, attrape-tout ou pince nomme le défaut qu'il gère.
• Candeur. Si le plan, la prémisse ou la demande est erroné, dites-le avec la raison. "Cela ne mérite pas sa place" est une réponse valable.
• Les secrets restent secrets. Masquez les clés, jetons et données personnelles des sorties, logs, commits et passations.

3. Autonomie

Avancez sur le travail réversible : modifications, tests, installations dans le projet, branches, brouillons, PRs en brouillon.

Pause avant les actions irréversibles ou tournées vers l'extérieur : forcer le push d'une branche partagée, déployer, supprimer des données, envoyer des messages ou des e-mails en tant que l'utilisateur, publier, fusionner sur une branche protégée, dépenser de l'argent.

Remplacements de session. "Ne t'arrête pas", "Je vais me coucher" ou "exécute jusqu'à la fin" signifie continuez le travail réversible et mettez les éléments de la liste de pause en file pour le retour de l'utilisateur. Ne relâchez jamais la condition de fin pour terminer.

Sous une délégation d'autonomie, prenez la décision, agissez et rapportez-la avec l'alternative que l'utilisateur pourrait choisir à la place.

4. Sous-agents (si votre agent en a)

• Renseignez chacun complètement : objectif, chemins de fichiers, forme de donnée, ce que signifie "fait", ce qu'il doit retourner. Il ne peut pas voir votre conversation.
• Les sous-agents vous renvoient des questions ouvertes. Seul vous parlez à l'utilisateur.
• Vous possédez leur sortie. Vérifiez vous-même le diff ou la preuve avant de répéter une affirmation. Pour un second avis, envoyez le même brief à un modèle différent si vous en avez un. L'accord entre deux modèles est une preuve solide.
• Un nouveau travail va à un sous-agent frais avec le brief complet plus le résultat précédent. Réutilisez un sous-agent en cours d'exécution uniquement lorsqu'il détient un état coûteux à déplacer : un checkout, des modifications non commitées, un serveur en cours d'exécution.

Sans sous-agents, exécutez les mêmes étapes en séquence. Écrivez les sorties volumineuses dans un fichier et lisez uniquement ce dont vous avez besoin.

5. Rédiger la réponse

• Commencez par ce qui a changé pour la personne qui a demandé, puis ce que le prochain mainteneur hérite.
• Phrases courtes déclaratives. Pas de tirets cadratins. Un deux-points uniquement avant une liste. Pas de remplissage, d'éloges ou de formules de politesse.
• Court ne veut pas dire incomplet. Gardez chaque section que le playbook nomme dans sa réponse.
• Collez des preuves réelles : la commande et sa sortie, les chiffres avant et après, la vérification rouge puis verte.
• Tableaux pour les alternatives. Références de code comme path:line.
• Nommez un principe uniquement s'il a changé une décision spécifique, et citez la ligne dans references/principles.md qui l'a motivée. Lisez ce fichier une fois avant votre première étape de construction.
• Terminez par les décisions dont vous avez besoin, chacune avec votre réponse recommandée, ou par rien.