check

Aperçu du skill check

Ce que fait le skill check

Le skill check est un workflow de revue et de validation pour les diffs de code, les PR, le triage d’issues, la préparation de release, les pushes et les audits de projet. Il convient particulièrement aux utilisateurs qui veulent une réponse rapide mais rigoureuse à la question : « Est-ce que je peux livrer ça sans risque, qu’est-ce qui est cassé, et que dois-je corriger avant de merger ? »

Quand ce skill est le plus adapté

Utilisez le skill check quand vous avez besoin d’une revue de code sur un ensemble de changements précis, notamment avant un merge, avant une release, ou pour valider des artefacts générés et les actions de suivi associées. Il est particulièrement utile quand vous voulez que l’agent examine d’abord le worktree, évite les modifications locales cachées et distingue les problèmes corrigibles de ceux qui nécessitent une confirmation humaine.

Ce qui différencie check

Le skill check n’est pas une simple requête générique du type « regarde ce code ». Il applique des garde-fous explicites pour les worktrees sales ou non suivis, suit un workflow clair centré sur la revue, et oriente vers une revue spécialisée lorsque des risques d’architecture ou de sécurité apparaissent. Cela le rend plus solide qu’une invite ponctuelle pour check for Code Review, car on sait mieux quand inspecter, quoi inspecter et quand s’arrêter.

Comment utiliser le skill check

Installer et déclencher check

Installez avec :

npx skills add tw93/Waza --skill check

Puis lancez-le quand vous avez une cible de revue concrète : un diff, une branche, une PR, un candidat à la release, une plage de commits ou une demande d’audit du dépôt. Pour check usage, donnez à l’agent un périmètre précis, par exemple : « examine les 3 derniers commits », « vérifie cette PR avant merge » ou « audite la préparation de release après les mises à jour de dépendances ».

Donner au skill la bonne entrée

La meilleure entrée pour check n’est pas « est-ce que c’est bien ? », mais une tâche bornée avec du contexte. Bons exemples :

• « Vérifie cette PR pour repérer des régressions de sécurité et d’architecture avant le merge. »
• « Passe en revue le worktree actuel et dis-moi ce qui bloque la release. »
• « Audite les fichiers générés et dis-moi s’ils correspondent aux changements source. »

Incluez la branche, la plage de commits, la release visée et toute contrainte du type « ne modifie pas les fichiers » ou « n’inspecte que le contexte public du repo ». Cela aide le skill à éviter un comportement de revue trop large et trop vague.

Lire d’abord ces fichiers

Commencez par SKILL.md, puis consultez references/project-context.md et references/persona-catalog.md pour comprendre la profondeur de revue, l’orientation vers les spécialistes et les attentes de release. Utilisez agents/reviewer-security.md et agents/reviewer-architecture.md quand le diff touche aux frontières de confiance, aux APIs, aux imports ou à la structure des modules. references/public-reply.md devient important quand le workflow inclut un suivi de la part des mainteneurs sur des issues ou des PR.

Conseils pratiques de workflow

Avant la revue, le skill attend une vérification de sécurité du worktree via git status --short --branch -uall. C’est important, car des changements sales ou non suivis peuvent modifier le sens de la revue. Si vous voulez un meilleur résultat avec check guide, précisez à l’agent s’il doit seulement signaler les constats, s’il peut corriger les problèmes sûrs, et quelle commande de vérification doit être utilisée après les modifications.

FAQ du skill check

check sert-il uniquement à la revue de code ?

Non. Le skill check couvre aussi la préparation de release, les pushes, les artefacts publiés, le triage d’issues et de PR, ainsi que les audits à l’échelle du projet. Il est plus adapté qu’une invite classique quand la tâche demande un jugement « prêt à livrer », et pas seulement une lecture de code.

Quand ne faut-il pas utiliser check ?

N’utilisez pas check pour explorer des idées sans cadre, déboguer une cause racine ou retoucher un texte. Le skill est conçu pour des diffs concrets et une revue opérationnelle, pas pour le brainstorming ni pour des retours narratifs.

check est-il adapté aux débutants ?

Oui, à condition de pouvoir nommer la cible et le résultat attendu. Les débutants obtiennent les meilleurs résultats quand ils disent exactement ce qui a changé, ce qu’ils veulent faire examiner, et s’ils veulent seulement des constats ou aussi des corrections sûres. Sans cela, check install peut être simple, mais check usage devient trop large pour être fiable.

En quoi est-il différent d’une invite simple ?

Une invite simple demande généralement une revue subjective. check ajoute un chemin disciplinaire : préflight de sécurité, contrôle du périmètre, attentes de vérification et orientation vers des spécialistes pour la sécurité ou l’architecture. Cela le rend plus fiable pour check for Code Review qu’une demande de revue improvisée.

Comment améliorer le skill check

Fournir un brief de revue plus précis

Les entrées les plus utiles sont : ce qui a changé, pourquoi cela a changé, ce qui ne doit surtout pas casser, et le type de revue attendu. Par exemple : « examine uniquement le chemin d’authentification », « concentre-toi sur les artefacts de release » ou « vérifie si ce refactor modifie les APIs publiques ». Cela resserre la recherche et améliore le signal.

Mettre en avant les contraintes fortes

Dites au skill quelles sont les règles de packaging, les fichiers générés, les chemins protégés et les commandes de vérification obligatoires. Si le repo a une source de vérité pour le build ou la release, mentionnez-la dès le départ. Cela réduit les faux positifs de confiance et aide le skill check à repérer les écarts, les artefacts manquants ou les actions de suivi risquées.

Itérer à partir des constats, pas des compliments

Après le premier passage, répondez avec les constats exacts que vous voulez faire revérifier ou avec le patch que vous avez appliqué. Le skill progresse quand vous demandez une seconde passe sur une seule zone de risque à la fois, comme la sécurité, l’architecture ou la préparation de release. Si la sortie semble trop large, resserrez le périmètre plutôt que de demander « plus de détails ».