# Verify > Vérifie qu'une tranche marche vraiment — checks automatiques puis parcours réel dans l'app qui tourne, constaté par un tiers. Use when l'utilisateur demande si ça marche, avant de clore une tranche, ou avant un commit. - Skill: `oqiodev/verify` (Agent Skill) - Install (CLI): `npx skillmds@latest add oqiodev/verify` - Raw SKILL.md: https://api.skillmd.com/api/skills/oqiodev/verify/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: OQIODev (https://skillmd.com/u/oqiodev) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/oqiodev/verify --- Un build vert ne prouve pas qu'un outil marche. Les étapes 1 à 3 sont obligatoires ; la 4 l'est dès que la tranche a touché à l'écran. ## 1. Épingler le point fixe Avant de lancer quoi que ce soit, savoir exactement ce qu'on vérifie et contre quoi : - **La tranche.** Celle que l'utilisateur désigne ; sinon la première de la section « Tranches » de `BACKLOG.md`. Si le diff ne ressemble pas à cette tranche-là, ne pas deviner : le dire et demander laquelle. - **Le critère**, recopié **mot pour mot** depuis la tranche, plus le critère de réussite de `SPEC.md`. Pas reformulé — recopié. Une Vérif qui porte plusieurs points séparés par `·` se recopie **en entier** : chacun est un verdict, aucun ne se laisse tomber parce que la tranche n'y a pas touché. - **Le port de dev**, lu dans `package.json`. Il est fixe et propre à ce dépôt, et le sous-agent de l'étape 3 en a besoin : sans lui, il ne peut pas remplir l'obligation qu'on lui donne de vérifier quel serveur il pilote. - **Le diff**, depuis le dernier commit : `git diff HEAD --stat` **et** `git status --porcelain`. Les deux, jamais l'un seul — `git diff` ne voit pas les fichiers non suivis, et une tranche qui ne fait qu'ajouter des fichiers lui paraît vide alors qu'elle a tout écrit. C'est quand **les deux** ne rendent rien qu'il n'y a rien à vérifier : le dire et s'arrêter là. - **La ligne de direction visuelle** de `DECISIONS.md`, si la tranche a touché à l'écran. Un point fixe qui ne résout pas, un critère absent ou un diff vide doivent échouer **ici**, pas dans un sous-agent lancé pour rien. ## 2. Checks automatiques ```bash npm run verify ``` Lint, typecheck et tests unitaires. Si ça échoue, corriger avant de continuer — ne pas passer à l'étape 3 avec du rouge. ## 3. Parcours réel — constaté par quelqu'un d'autre Celui qui a écrit le code ne constate pas son propre critère. Il sait ce qu'il a voulu faire, et il reconnaît son intention au lieu de regarder l'écran. Le parcours est donc confié à un sous-agent en contexte frais. Préparer l'infrastructure, et rien de plus : - Postgres doit tourner : `docker compose up -d` - Migrations à jour : `npx prisma migrate dev` - **Ne pas lancer l'app soi-même** — c'est le sous-agent qui la lance, et Next refuse un second serveur de dev sur le même dossier. Puis lancer un sous-agent `general-purpose` dont le prompt contient : - le critère et le critère de réussite, tels qu'épinglés à l'étape 1 - la consigne de lancer l'app et de piloter le navigateur lui-même, screenshot inclus - **le port de dev épinglé à l'étape 1**, et l'obligation de s'assurer que le serveur qu'il pilote est bien **celui de ce dossier** avant de constater quoi que ce soit — un dev server d'un autre projet sur le même port donne un faux verdict dans les deux sens, et il est aveugle au code, donc rien ne le lui signalera - l'interdiction de lire le diff, le dernier commit, le plan ou le compte rendu — il constate ce qu'il voit à l'écran, pas ce que le code prétend faire - l'interdiction de corriger quoi que ce soit : il constate, il ne répare pas - l'obligation de regarder les logs serveur — une page qui s'affiche avec une erreur 500 derrière n'est pas verte - si le parcours touche l'authentification : le faire connecté **et** déconnecté, une route protégée qui répond sans session est un bug, pas un détail - **si la tranche a touché à l'écran** : la ligne de direction visuelle, et la question « ce qui est à l'écran tient-il à côté de cette référence, ou à distance de celle qui est refusée ? » Il répond par un constat et ce qui cloche, pas par une proposition de direction. S'il n'y a pas de référence, ou si la ligne dit `À TRANCHER`, sauter la comparaison — ne pas s'en inventer une. Il rend un verdict et ce qu'il a vu : `CONSTATÉ` · `INFIRMÉ` + ce qui s'est passé à la place · `PAS PU CONSTATER` + ce qui a bloqué. Sans verdict, l'étape n'est pas faite — ne jamais la remplacer par « ça devrait marcher ». Si le verdict est `INFIRMÉ` : corriger, puis relancer un sous-agent **neuf**. Jamais celui qui a vu la version cassée : il a déjà son opinion et il validera la correction sur parole. Trois tours au maximum sur le même échec, au-delà s'arrêter et rendre compte de ce qui bloque. Ne pas demander à l'utilisateur de vérifier à sa place. ## 4. Relecture de l'interface Seulement si la tranche a touché à l'écran — sinon passer directement à l'étape 5. La barre est [`.claude/rules/web-interface-guidelines.md`](../../rules/web-interface-guidelines.md) : 17 catégories, une centaine de règles, figées dans le dépôt. La lire, l'appliquer aux fichiers modifiés par la tranche, et rendre les constats en `fichier:ligne` selon le format de sortie qu'elle décrit. Elle est **locale et figée exprès** : la barre ne doit pas changer entre deux tranches sans qu'on l'ait voulu. Ne pas aller chercher une version fraîche en ligne pendant une vérification — le fichier porte sa commande de rafraîchissement, qui se lance sur intention et se relit en `git diff`. Les deux règles qui bordent son usage (le projet l'emporte, c'est un jugement jamais une violation dure) sont dans son en-tête. Corriger ce qui est constaté et dans le périmètre de la tranche ; écrire le reste dans `BACKLOG.md`, section « Capté en passant ». Ne rien passer en silence. Ce n'est pas une relecture de goût : la direction est déjà tranchée dans `DECISIONS.md`, cette étape la contrôle, elle ne la rediscute pas. ## 5. Rendre compte Trois constats, **côte à côte et non fusionnés** : - **Parcours** — le verdict du sous-agent, tel qu'il l'a rendu. - **Utilisabilité** — ce que la relecture a trouvé, en `fichier:ligne`, **et ce qu'il en reste** : corrigé, ou reporté dans « Capté en passant ». Rapporter les constats après correction ferait disparaître le travail de l'étape 4. - **Tenue** — la comparaison à la référence nommée. S'il n'y a pas de référence, ou si la ligne dit `À TRANCHER`, ce constat est **sans objet** et s'écrit tel quel — ne jamais s'inventer une référence pour remplir la case, ne jamais faire disparaître la ligne non plus. Ne pas les mélanger, ne pas les reclasser, ne pas en tirer un verdict unique. C'est le but de la séparation : un parcours qui aboutit ne prouve pas que ce soit utilisable, et une interface utilisable ne prouve pas qu'elle tienne. Un verdict global laisserait l'un des trois masquer les autres. Dire ce qui a été constaté, pas ce qui devrait marcher. Si une partie n'a pas pu être vérifiée, le dire explicitement plutôt que de la présenter comme validée. Le récit du constat va dans `JOURNAL.md` et dans le corps du commit — **jamais dans `BACKLOG.md`**, qui ne dit que ce qui reste à faire. Ce qui n'a pas pu être vérifié se pose en **une ligne** dans « Réserves », avec le fait qui la lèverait.