AjaneeI/agent-skills

Traduire une demande en un plan d’exécution autorisé et de complexité minimale, avec exigences explicites, exclusions, règles d’arrêt et critères d’acceptation. À utiliser avant de réaliser une tâche multi-étapes ou de proposer une nouvelle infrastructure d’agent.

Qu'est-ce que agent-skills ?

Cette compétence permet de transformer une requête en un plan d’exécution clair, minimal et autorisé. Elle est conçue pour éviter les dérives, les surconstructions et les suppositions implicites lors de la mise en œuvre de tâches complexes. L’agent doit d’abord rédiger un « contrat » formel qui définit l’objectif, les actions autorisées et interdites, les contraintes immuables et les preuves de succès. Ensuite, il remet en question chaque exigence pour en vérifier la nécessité, supprime les travaux superflus, simplifie l’architecture et ordonne les étapes restantes par dépendances. Avant toute accélération ou parallélisation, il estime les coûts et la complexité. Enfin, toutes les questions d’approbation sont rendues explicites et limitées. La compétence spécifie également des règles d’arrêt strictes en cas d’escalade d’accès, d’engagements payants hors budget, d’effets irréversibles ou d’actions hors autorisation. Le livrable est un tableau « exigences-actions » avec les statuts « doit », « peut », « ne doit pas », les propriétaires, les dépendances et les critères d’acceptation. Cette approche fonctionne avec n’importe quel agent capable de planifier et d’exécuter des tâches (Claude Code, Cursor, Codex, etc.) et est particulièrement utile dans les workflows où la traçabilité et le contrôle sont importants.

Compatible avec~Claude Code~Codex CLI~Cursor

npx skills add https://github.com/AjaneeI/agent-skills/tree/HEAD/skills/constraints-first-execution

Documentation

Exécution par Contraintes d’Abord

Quand l’utiliser

À utiliser au début d’un nouveau workflow d’implémentation, d’automatisation ou de recherche, en particulier lorsqu’un agent pourrait surconstruire ou supposer des permissions non explicites.

Entrées requises

Objectif, actions autorisées par le propriétaire, actions interdites, capacités existantes du système, preuves de succès, budget de ressources et toute limite d’approbation externe. Une autorité inconnue ne constitue pas une permission implicite.

Procédure

Rédiger un court contrat : objectif, livrable dans le périmètre, non-objectifs, actions réversibles, contraintes immuables et preuves de complétion vérifiées.
Remettre en question si chaque exigence est réellement nécessaire à l’objectif de l’utilisateur. Ne pas supprimer silencieusement des exigences explicites de l’utilisateur.
Supprimer les travaux facultatifs qui n’améliorent pas les critères d’acceptation nommés. Conserver les contrôles de sécurité et de qualité requis.
Simplifier l’architecture proposée avant de l’optimiser. Privilégier les outils existants et les workflows directs plutôt que de nouveaux frameworks.
Ordonner les tâches restantes par dépendances et jalons de vérification. Identifier la plus petite unité réversible suivante qui prouve un progrès.
Ce n’est qu’après cette séquence qu’il faut envisager l’accélération, la parallélisation ou l’automatisation. Estimer le coût et la complexité de chaque ajout.
Rendre les questions d’approbation explicites et limitées. Si l’autorisation n’est pas claire pour un changement matériel, conserver une proposition au lieu de l’exécuter.

Arrêter ou escalader

Arrêter avant une escalade d’accès, des engagements payants hors budget, des effets irréversibles, des changements de méthodologie figés ou des actions en dehors d’une autorisation explicite. Ne jamais traiter les objectifs de vitesse comme des garde-fous prioritaires.

Livrable

Un tableau exigences-actions concis avec les colonnes doit, peut, ne doit pas, propriétaires, dépendances et preuves nécessaires pour déclarer chaque unité terminée. Utiliser le modèle de contrat lorsque la traçabilité est importante.

Acceptation

Chaque tâche proposée a une raison nommée et une condition de preuve ; aucune nouvelle dépendance ou abstraction n’est justifiée uniquement par d’éventuels besoins futurs.