Aller au contenu principal
PraktikPraktikLe guide IA utile
S'abonner
Avancé12 min

Playbooks Codex

Ce que tu vas apprendre

Six playbooks pour choisir la bonne surface, gerer les handoffs local/cloud, travailler avec des screenshots, et boucler review-to-fix sans perdre le controle.

Prerequis

  • Avoir lu les modules 01 a 09
  • Avoir utilise au moins deux surfaces differentes (CLI, cloud, GitHub)
  • Comprendre les templates de task brief (module 08)

Le concept en 30 secondes

Un playbook choisit la surface et definit le contrat avant que le travail commence. Pas de “je vais voir”. Decision, brief, execution, verification.

Etapes

1. Choisir la bonne surface

Guide de decision :

@diagram:codex-playbooks

Template de brief :

Objectif :
Surface :
Etat du repo :
Contexte externe :
Modifications autorisees :
Ne pas modifier :
Verification :
Sortie attendue :

Verification : Confirme que la surface avait le contexte necessaire et que le resultat a ete review au bon endroit.

2. Handoff local vers cloud

Quand : L’exploration locale a clarifie la tache, Codex peut finir en arriere-plan.

Workflow :

@diagram:steps
Inspecter localement jusqu'a ce que la frontiere de la tache soit claire
Commit, stash, ou decrire l'etat local dont la tache cloud a besoin
Ecrire un brief avec fichiers, contraintes, verification
Lancer la tache cloud depuis la surface appropriee
Review le diff retourne localement avant publication

Template de brief :

Utilise ce repo et cette branche :
Implemente :
Contexte deja appris localement :
Fichiers probablement impliques :
Contraintes :
Commande de verification :
Retour attendu :

Modes de defaillance :

  • Changements locaux non stages supposes visibles dans le cloud
  • Diff cloud merge sans relancer les checks locaux
  • Raison d’une contrainte locale omise dans le brief
  • Tache trop large pour un run isole

3. Changement UI depuis un screenshot

Quand : Un screenshot, mockup, ou rapport visuel doit devenir un changement frontend.

Workflow :

  1. Attacher le screenshot ou la reference design
  2. Nommer l’ecran, la route, ou le composant exact
  3. Definir les tailles d’ecran qui doivent fonctionner
  4. Demander implementation + verification visuelle
  5. Review les screenshots avant d’accepter le diff

Template de brief :

Image de reference :
Route ou composant cible :
Comportement attendu :
Checks de viewport :
Fichiers autorises :
Ne pas modifier :
Verification :

Verification :

  • Tests automatises s’ils existent
  • Screenshots pour les viewports nommes
  • Pour UI interactive ou canvas : verifier que la zone visuelle principale est non vide et correctement cadree

Modes de defaillance :

  • Decrire l’image au lieu de l’attacher
  • Verifier uniquement en desktop
  • Texte qui rentre en desktop mais debord en mobile
  • Polish visuel accepte sans screenshot before/after

Quand : Le travail depend de faits qui ont pu changer (API, SDK, pricing, release notes).

Workflow :

  1. Formuler la question de fraicheur
  2. Chercher dans les sources officielles ou primaires d’abord
  3. Capturer les dates ou marqueurs de mise a jour
  4. Resumer l’evidence avant d’editer
  5. Garder les citations dans l’explication finale

Template de brief :

Question de fraicheur :
Sources preferees :
Faits a verifier :
Fichiers a mettre a jour :
Verification :
La sortie doit inclure :

Verification : Le changement final separe les faits sourcés des recommandations locales. Si la source est versionnee, confirme que la version correspond au code ou doc modifie.

Modes de defaillance :

  • Utiliser la memoire pour des APIs recemment changees
  • Melanger docs officielles et articles de blog non sourcés
  • Omettre les dates de source pour des guides dependants de version
  • Changer le comportement repo base sur la doc d’une autre version

5. Boucle review GitHub vers fix

Quand : Une review GitHub, commentaire PR, ou review automatisee doit devenir un fix local.

Workflow :

  1. Collecter les commentaires de review et fichiers affectes
  2. Classer chaque point : fix, expliquer, reporter, rejeter
  3. Implementer les fixes localement dans le plus petit perimetre
  4. Lancer les checks qui prouvent que les commentaires sont traites
  5. Repondre avec fichiers changes et evidence de verification

Template de brief :

Source PR ou review :
Commentaires a adresser :
Hors perimetre :
Fichiers probablement impliques :
Verification :
Format de reponse :

Verification : Un bon resultat inclut un diff local, des checks passants, et une reponse commentaire par commentaire. Si un finding est rejete, expliquer la raison avec fichier ou test.

Modes de defaillance :

  • Traiter chaque finding automatise comme correct
  • Faire des refactors larges en adressant des commentaires etroits
  • Repondre avant de relancer les checks
  • Perdre la trace des commentaires reportes intentionnellement

6. Tache longue en arriere-plan

Quand : Codex doit travailler de maniere asynchrone sur une tache qui prend du temps.

Workflow :

  1. Decouper le travail en une tache bornee par run
  2. Nommer les fichiers ou zone de responsabilite
  3. Inclure les commandes de setup et verification
  4. Exiger un resume concis de progres et resultat
  5. Review le diff final avant application ou merge

Template de brief :

Objectif :
Zone de responsabilite :
Entrees :
Modifications autorisees :
Ne pas modifier :
Setup :
Verification :
Reponse finale :

Verification : Verifie que la tache est restee dans sa zone et que la verification rapportee correspond a des commandes ou evidences que tu peux relancer.

Modes de defaillance :

  • Lancer des taches qui editent les memes fichiers en parallele
  • Donner un objectif large sans condition d’arret
  • Omettre les etapes de setup pour l’environnement d’arriere-plan
  • Accepter une PR generee sans review du diff

Verification

  • La surface est choisie avant le brief, pas au feeling
  • Chaque playbook a son template de brief copiable
  • La verification est nommee avant l’execution
  • Les handoffs local/cloud decrivent l’etat necessaire
  • Le diff est inspecte avant merge ou publication
  • Les taches d’arriere-plan ont une zone de responsabilite claire

Pieges courants

  • Envoyer une tache cloud dependant d’etat local non commit → Commit ou stash avant
  • Chercher sur le web avant de formuler la question → Definir la question de fraicheur d’abord
  • Demander du travail UI sans screenshot → Attacher la reference visuelle
  • Traiter une review comme un plan de fix complet → Verifier localement chaque point

Recapitulatif

Playbook Surface cle Input Output
Choisir la surface Decision Besoin Brief structure
Local → Cloud CLI puis Cloud Etat local clarifie Diff verifie localement
UI depuis screenshot CLI/IDE Screenshot + viewport Code + screenshots
Doc fraiche CLI + Web Question de fraicheur Fichiers mis a jour + citations
Review → Fix GitHub puis CLI Commentaires Fixes + reponse
Tache longue Cloud Objectif borne Resume + diff

Templates inclus

Task Brief

Objectif :
Surface :
Contexte :
Perimetre :
- Autorise :
- Exclu :
Verification :
Sortie attendue :

Brief de handoff local/cloud

Utilise ce repo et cette branche :
Implemente :
Contexte deja appris localement :
Fichiers probablement impliques :
Contraintes :
Commande de verification :
Retour attendu :

Brief UI visuel

Image de reference :
Route ou composant cible :
Comportement attendu :
Checks de viewport :
Fichiers autorises :
Ne pas modifier :
Verification :

Pour aller plus loin