3 workflows agentiques qui ont changé ma façon de coder

Après plusieurs mois d’usage quotidien d’un agent de coding en terminal, trois workflows se sont installés naturellement. Pas des patterns théoriques — des habitudes qui se sont imposées parce qu’elles résolvent des frictions réelles.

1. Le briefing matinal automatisé

Chaque matin à 7:57, un cron lance l’agent avec un skill /morning. L’agent scanne les projets Git, les MRs ouvertes, les issues assignées, les branches actives, et produit un briefing structuré dans une note Obsidian.

Le résultat : en ouvrant le terminal, je sais exactement où j’en suis. Quelles MRs attendent une review, quels tickets ont bougé depuis hier, quel travail est non commité. Pas besoin d’ouvrir GitLab, de parser mentalement l’état de 3 projets.

Le soir à 19:27, un autre cron fait le /evening : nettoyage des branches mergées, capture des prochaines actions, retro de la journée. Le JSON produit alimente le morning du lendemain.

Ce n’est pas un dashboard. C’est un handoff structuré entre moi-hier et moi-demain, avec l’agent comme intermédiaire.

2. Les custom commands versionnées

Les custom commands sont des fichiers Markdown dans .opencode/commands/ (ou .kilocode/commands/), versionnés dans Git. Chaque commande encode un workflow récurrent :

# .opencode/commands/new-endpoint.md
Crée un endpoint API Platform 3 complet pour l'entité $ARGUMENTS.
Respecte les conventions dans AGENTS.md.
Génère les tests PHPUnit correspondants.
Lance les tests jusqu'à ce qu'ils passent.

La mécanique est identique aujourd’hui avec les skills et custom commands de Claude Code — mêmes fichiers versionnés, même principe.

L’équipe a accumulé ~15 commandes. Un nouveau dev clone le repo, tape /new-endpoint Order, et obtient un endpoint complet avec tests en 5 minutes — sans connaître les conventions du projet par cœur.

La différence avec des scripts classiques : la commande custom s’adapte au contexte. Elle lit le code existant, les conventions du projet, et produit du code cohérent avec ce qui existe déjà.

3. Les sessions parallèles en split tmux

Un split vertical permanent : Neovim à gauche, agent à droite. Quand une tâche arrive, je la brief sans quitter l’éditeur.

Mais le vrai gain est dans le parallélisme. Deux splits tmux, deux sessions agent indépendantes : une sur le refactoring backend, l’autre sur les tests correspondants. Les sessions ne partagent pas de contexte — c’est voulu, ça évite la pollution croisée.

Sur les tâches mécaniques (fixtures, DTOs, tests boilerplate), les sessions parallèles sur un modèle économique — à l’époque un modèle gratuit via Kilo Gateway, aujourd’hui les sub-agents de Claude Code — permettent de traiter deux chantiers simultanément sans faire exploser le coût.

Ce qui relie les trois

Ces workflows ont un point commun : ils traitent l’agent comme une infrastructure, pas comme un outil ponctuel. Le cron tourne sans intervention. Les commandes custom persistent dans Git. Le split tmux est permanent.

L’agent n’est plus quelque chose qu’on “ouvre quand on en a besoin”. Il fait partie du workflow par défaut, comme le linter ou le test runner.

Ces trois patterns sont exactement ce qu’on transmet à un nouveau dev le premier jour — c’est de l’outillage d’équipe, pas des habitudes perso.

→ Guide : OpenCode + Neovim + tmux setup → Guide : Principes du workflow agentique