Aller au contenu principal
PraktikPraktikLe guide IA utile
S'abonner
Intermédiaire12 min

Exemples de workflows complets

Ce que tu vas apprendre

Huit workflows concrets qui combinent orientation, fix, review, docs et handoff. Chacun avec son prompt copier-coller et sa checklist de verification.

Prerequis

  • Avoir lu les modules 01 a 07
  • Un repo avec des tests et une CI
  • Savoir utiliser codex exec et codex review

Le concept en 30 secondes

Un workflow complet va de l’entree (bug, ticket, commentaire) a la sortie (diff verifie, reponse postee). Chaque etape a un prompt type et une commande de verification.

Etapes

1. Bugfix : de l’orientation a la verification

Entree : Un bug report, tu ne connais pas les fichiers concernes.

@diagram:flow
Reproduire :: Confirmer le bug avec un check qui echoue.
Isoler :: Trouver le chemin exact qui diverge.
Fixer :: Le plus petit changement qui explique l'echec.
Verifier :: Regression + diff avant de conclure.

Prompt d’orientation :

Inspecte ce repo avant de proposer des changements.

Retourne :
1. Les fichiers et repertoires les plus pertinents
2. Une explication courte de la structure actuelle
3. La prochaine etape la plus sure
4. Les commandes ou checks pour verifier le resultat
5. Les risques ou inconnus qui pourraient changer le plan

Prompt de fix :

Reproduis le bug decrit dans l'issue #42.
Isolle le chemin qui echoue.
Ecris ou lance le plus petit check qui reproduit.
Fais le plus petit fix qui explique l'echec.
Lance un check de regression.
Resume ce qui a change et comment c'est verifie.

Verification :

npm test -- bug.test.ts
npm test

2. Reponse a une review PR

Entree : Des commentaires sur une PR a traiter sans suivre aveuglement.

Workflow :

  1. Lire les commentaires et les fichiers affectes
  2. Classer chaque point : fix, expliquer, reporter, rejeter
  3. Faire le plus petit change justifie
  4. Repondre avec ce qui a change et comment c’est verifie

Prompt :

Adresse les commentaires de review sur cette PR.

Pour chaque commentaire :
- Si c'est un bug reel : corrige avec le fichier et la ligne
- Si c'est une suggestion non justifiee : explique pourquoi tu la rejetes
- Si c'est hors perimetre : dis clairement que c'est reporte

Verification : relance les tests affectes.
Retour : reponse commentaire par commentaire + resultat des checks.

3. Mise a jour de docs avec validation

Entree : La doc doit changer sans laisser la structure pourrir.

Workflow :

# 1. Modifier les fichiers de contenu
# 2. Lancer les validations
codex exec -- "update the README to reflect the new API, then run npm test && npm run validate"

Verification :

npm test
npm run validate
# Chercher les placeholders non resolus

4. Linear vers local

Entree : Un ticket Linear a transformer en changement verifie.

Prompt de handoff :

Utilise le ticket Linear lie comme source d'intention produit.

Objectif : implementer le plus petit changement qui satisfait le ticket.
Perimetre : reste dans le sous-systeme affecte sauf preuve contraire.
Ne change pas le comportement non lie.
Verification : lance le test cible et rapporte tout check plus large pertinent.
Retour : fichiers changes, resultat de verification, questions non resolues.

Note de cloture :

Implemente avec un changement cible.

Modifie :
- fichier ou sous-systeme

Verifie :
- commande et resultat

Reste a faire :
- rien, ou suivi specifique

5. Commentaire GitHub vers tache cloud

Entree : Une PR ouverte, tu veux une review puis un fix.

Etape 1 : Review :

@codex review for workflow regressions and missing validation steps

Etape 2 : Fix :

@codex corrige la regression de validation sur cette PR.

Perimetre :
- reste dans le workflow change et la doc associee
- ne refactorise pas les fichiers non lies

Verification :
- lance la commande qui echoue d'abord
- relance la meme commande apres le fix

Retour :
- cause racine
- fichiers changes
- resultat de verification
- risques restants

Etape 3 : Verification locale :

# Inspecte le diff avant merge
# Verifie la commande que Codex dit avoir lancee
# Confirme que la tache est restee dans le perimetre

6. Review PR via GitHub Action

Entree : Automatiser la review assistee sur chaque PR.

Prompt contract :

Review cette PR pour les risques comportementaux.

Priorise :
- regressions comportementales
- tests manquants ou faibles
- hypotheses non sures
- risques deploiement ou compatibilite

Retourne les findings par severite avec references de fichiers.
Ne commente pas le style sauf si ca affecte la correction.
Inclus les checks que tu as lances ou que tu n'as pas pu lancer.

Regle d’or : Ne jamais merger automatiquement. Lire la sortie Codex, puis inspecter le diff toi-meme.

7. Automatisation securisee avec approbations

Entree : Un workflow codex exec repetitif mais sans normaliser l’acces total.

Phase 1 : Dry run en lecture seule :

codex exec \
  --sandbox read-only \
  --ask-for-approval never \
  "resumes le drift du contrat de docs et dis-moi le plus petit fix sur"

Phase 2 : Ecriture bornee :

codex exec \
  --sandbox workspace-write \
  --ask-for-approval untrusted \
  "repare le drift du contrat de docs et lance npm run test && npm run validate"

Verification finale :

  • Inspecte le diff toi-meme
  • Confirme que la config regle/hook n’a pas cache d’effets
  • Verifie la commande que l’automation dit avoir lancee
  • Publie seulement apres stabilisation du chemin d’ecriture

8. Contexte frontend via MCP

Entree : Un composant UI a modifier, le repo seul ne suffit pas.

Prompt :

Utilise MCP uniquement pour le contexte design ou documentation necessaire.

Resumes d'abord :
- Quelle source externe tu as consultee
- Ce qu'elle prouve
- Quels fichiers locaux sont impactes

Puis inspecte le repo et propose le plus petit chemin d'implementation.
Ne modifie pas les patterns UI non lies.
Verifie avec les checks locaux pertinents.

Pour le travail UI, prefere une preuve du rendu (screenshot, test visuel) a un build qui passe.

Verification

  • Chaque workflow a un prompt type copiable
  • La verification est nommee avant que le travail commence
  • Le diff est inspecte avant merge ou publication
  • Les reponses aux reviews citent fichiers et tests
  • L’automation reste en untrusted jusqu’a preuve de stabilite

Pieges courants

  • Sauter l’orientation pour aller plus vite → Perdre du temps a modifier le mauvais fichier
  • Accepter tous les commentaires de review → Certains sont des suggestions, pas des ordres
  • Merger le diff cloud sans relancer localement → L’environnement isole peut manquer des deps
  • Automatiser avant d’avoir un workflow stable → L’automation amplifie les bugs

Recapitulatif

Workflow Surface Prompt cle Verification
Bugfix CLI Orientation + fix Tests + diff
Reponse review CLI Classifier + fix Tests + reponse
Docs CLI Modifier + valider npm run validate
Linear CLI/Cloud Handoff structure Tests + note
GitHub comment GitHub @codex review puis fix Diff + CI
Action PR GitHub Action Prompt contract Output humain
Automation CLI Dry run puis write Diff + commande
MCP frontend CLI + MCP Source externe puis local Screenshot/test

Pour aller plus loin