Spielewoy/autoprompt-skill

Autoprompt

Autoprompt est une boucle d'orchestration « utile d'abord ». Elle stocke la mission une fois, produit un roadmap exécutable approuvé indépendamment, répartit directement les voies prêtes pour la mise en œuvre, et prouve le comportement livré avec des tests réels et une revue fraîche.

1. Contrat de lancement

L'invocation autorise la mission. Ne demandez pas à l'utilisateur de reformuler, restreindre ou approuver la mission.

Le chargement de la compétence ou son invocation sans mission ne démarre ni ne reprend jamais une exécution, indépendamment des artefacts résiduels. Une invocation nue effectue uniquement la vérification de frontière de la section 10, rapporte le résultat et s'arrête.

Avant le lancement, résolvez uniquement les paramètres opérateur non définis :

• Concurrence : tokensaver (par défaut, jusqu'à six vivants), wide/billionaire (tous les travaux disjoints prêts jusqu'au plafond global), ou custom max_subs=N.
• Sélection d'agent : off/héritage. Les sous-agents OMP héritent du modèle d'exécution, donc la capacité d'effort est exactement inherited-only ; ne revendiquez jamais un effort sélectionnable.

Dans une session avec assistance, posez tous les paramètres non définis en une seule question avant le travail sur le dépôt/outil. Dans une exécution superviseur non assistée, ne demandez pas : utilisez les valeurs par défaut tokensaver et agents=off et enregistrez les hypothèses. Un indicateur de dérogation d'autorisation n'est pas une non-assistance.

Après le sélecteur, répartissez le coordinateur de périmètre L1 ap-scope-coordinator ; il répartit l'auteur du roadmap « utile d'abord ». Il n'y a pas de cycle d'aller-retour d'admission séparé et aucun agent de pré-vérification obligatoire.

Une mission invoquée entre toujours en orchestration : la topologie de périmètre borné est la topologie minimale, et l'agent principal ne se trie jamais silencieusement lui-même une mission invoquée en exécution directe. Sauter ou restreindre la répartition est une décision explicite enregistrée dans GATELOG.md avec sa justification, jamais une décision silencieuse.

2. Voie rapide de capacité

Un superviseur peut fournir une attestation de capacité versionnée liée au fournisseur/environnement d'exécution, version CLI, profil d'autorisation, sélecteur d'agent, hachage de définition d'agent, hachage de casting, statut/source d'effort, et succès exact RUN/READ/WRITE. Utilisez-la uniquement lorsque chaque liaison correspond au lancement en direct. Les valeurs manquantes, malformées, obsolètes, inconnues ou contradictoires sont des échecs sûrs.

Sans attestation de confiance, le premier auteur du roadmap « utile d'abord » prouve RUN, READ et WRITE par rapport à un chemin de test jetable avant l'inspection du dépôt, puis continue immédiatement. Tout échec arrête définitivement avant la mise en œuvre. La personnalité de pré-vérification est uniquement diagnostique/récupération.

3. Topologie de périmètre adaptative

Le périmètre produit un seul ROADMAP.md canonique.

• borné : auteur du roadmap, puis réviseur indépendant et vérificateur aveugle frais simultanément - 3 agents, 2 rounds, objectif sous une minute ;
• multi-surface : exactement 5 agents, 3 rounds, objectif sous cinq minutes ; conservez le roadmap complet de l'auteur et les preuves, ajoutez exactement deux éclaireurs complémentaires, puis réviseur simultané plus vérificateur frais sans répartition de synthèse redondante ;
• exceptionnellement grand : peut dépasser le budget ordinaire de 6 agents uniquement avec une raison d'escalade concrète enregistrée.

La recherche externe s'exécute uniquement lorsque des faits externes actuels sont requis. En cas de rejet, conservez les preuves acceptées et réparez uniquement les éléments nommés. Les roadmaps vides, les DAG invalides, la propriété chevauchante, les frameworks/tests manquants et l'échec de capacité sont des échecs définitifs.

4. Roadmap exécutable

ROADMAP.md est la seule source de périmètre/décomposition/plan de la nouvelle exécution. Il inclut le pointeur/hachage de mission et le nonce ; le profil/périmètre/escalade ; l'intelligence du dépôt ; les décisions de framework/outil ; les identifiants d'élément stables ; la catégorie/tag/niveau/framework ; les limites de propriété ; les dépendances et groupes de lancement ; la voie d'intégration ; les étapes de mise en œuvre ; les critères d'acceptation positifs ; les chemins malheureux ; les tests d'abord ; la vérification réelle ; une couverture >=95 % des lignes modifiées et des modules touchés ; et requiresDetailedPlan uniquement lorsque nécessaire.

Les éléments prêts pour la mise en œuvre sont répartis directement pour la construction. Ajoutez G1 uniquement pour le travail de débogage/verrouillage en profondeur, une divergence de conception nommée non résolue, requiresDetailedPlan: true, ou un conflit de plan signalé par le travailleur.

Décomposez la mission en chaque voie véritablement disjointe. Ne réduisez jamais une mission multi-surface en une seule voie « bornée » pour réduire le roadmap ; les surfaces disjointes obtiennent des voies disjointes avec une propriété disjointe.

5. Gouvernance de nouvelle exécution

La gouvernance de nouvelle exécution est exactement :

1. PROMPTS.txt - blocs d'invite exacts en annexe uniquement ;
2. ROADMAP.md - roadmap exécutable canonique ;
3. GATELOG.md - transitions en annexe uniquement, personnalité/modèle/provenance d'effort, verdicts, hachages, temps écoulé et frontière de reprise.

Ne créez pas de fichiers de gouvernance dédiés à la nouvelle exécution comme BRIEF.md, PLAN.md, AGENTS.md, COVERAGE.md, BACKLOG.md, ANCHOR.md, bucketlist.md, intake.md, scope-map.md, ou des fichiers de périmètre par angle. Conservez les preuves substantielles de mise en œuvre/test/révision/vérification. Les registres hérités restent lisibles et les formats mixtes contradictoires échouent fermés.

La gouvernance réside à la racine de gouvernance de l'exécution en dehors du dépôt cible de la mission : PROMPTS.txt, ROADMAP.md et GATELOG.md ne sont jamais écrits dans l'arborescence de travail cible et ne doivent jamais apparaître dans son diff.

6. Mémos pointeurs compacts

Le premier auteur du roadmap stocke la mission exacte dans PROMPTS.txt. Les mémos ultérieurs portent :

POINTEUR DE MISSION : lisez le registre d'invite exact avant d'agir ; arrêtez si son hachage ou sa longueur en octets diffère.
chemin=<PROMPTS.txt> hachage=sha256:<64 hex> octets=<longueur en octets UTF-8> nonce=<NONCE-DE-L'EXÉCUTION>

Les travailleurs vérifient le chemin, le hachage, la longueur en octets et le nonce avant d'agir. Envoyez uniquement le rôle, l'objectif, la limite, les dépendances, les critères d'acceptation, les pointeurs de roadmap/preuves avec hachages, le schéma/chemin de sortie et le statut de modèle/effort. Ne collez pas la mission, la transcription, le roadmap complet, la doctrine ou le raisonnement contradictoire antérieur. Préservez la révision aveugle.

7. Hiérarchie et répartition

Chaque travailleur est une personnalité ap-* installée et enregistrée. Sa définition d'agent personnalisée plus le mémo de tâche réparti sont son contexte de fonctionnement complet. Un travailleur ne doit jamais charger, invoquer ou ré-invoquer la compétence Autoprompt ni démarrer une exécution Autoprompt imbriquée ; il exécute uniquement ses instructions de personnalité et le mémo assigné. Chaque répartition lie le nom enregistré de la personnalité prévue comme type d'agent : un agent anonyme, general-purpose ou inventé dynamiquement est une répartition invalide, et toute répartition enfant doit nommer une autre personnalité ap-* enregistrée.

• L0 chef d'orchestre : démarre l'exécution et rapporte le verdict final. Sur une nouvelle exécution, il répartit uniquement les coordinateurs L1 nommés - ap-scope-coordinator pour le périmètre, ap-feature-coordinator pour la construction, ap-sweep-coordinator pour la convergence - jamais un gestionnaire L2 ou un travailleur L3/L4 directement ; un lancement de travailleur direct est un effondrement de contournement du coordinateur. ap-preflight-probe et ap-intake restent des exceptions diagnostiques et de reprise héritée, jamais des lancements de routine.
• Coordinateurs L1 (ap-scope-coordinator, ap-feature-coordinator, ap-sweep-coordinator) : possèdent le périmètre, la flotte de fonctionnalités ou la convergence et répartissent uniquement. Chacun répartit ap-manager pour une tranche multi-fonctionnalité ou multi-piste, ou directement des travailleurs L3/L4 nommés sur une voie bornée unique.
• Gestionnaire L2 (ap-manager) : optionnel pour une tranche multi-fonctionnalité ou multi-piste ; répartit des travailleurs L3/L4 nommés et n'exécute jamais.
• Exécuteurs L3 (ap-scoper, ap-researcher, ap-synthesizer, ap-planner, ap-implementer, ap-reviewer, ap-verifier, ap-sweeper, ap-execharness-resolver, ap-framework-generator) : effectuent le travail de roadmap/éclairage/recherche/synthèse/planification/construction/révision/vérification/balayage.
• Feuilles terminales L4 (ap-fresh-verifier, ap-depth-prober, ap-framework-validator, ap-juror, ap-goal-checker, ap-arbiter, ap-re-anchor, ap-scribe, ap-janitor) : effectuent la vérification aveugle, le verrouillage en profondeur, la validation de framework, les jurys, la vérification d'objectif, l'arbitrage, le ré-ancrage, les enregistrements et le nettoyage.

L1 n'exécute jamais. Une voie bornée unique saute L2. Répartissez le travail disjoint prêt ensemble lancez-tous-puis-collectez : émettez chaque lancement d'un groupe prêt avant de collecter un rapport - la répartition en arrière-plan parallèle est la forme par défaut, et la sérialisation est autorisée uniquement pour les dépendances réelles déclarées. Pas d'auto-révision. Réutilisez les preuves valides et évitez la propriété en double.

Les sous-agents étendent le travail de l'agent répartiteur ; ils ne le remplacent jamais. Le répartiteur conserve la synthèse, l'intégration et le jugement final. Les travailleurs ordinaires de mise en œuvre, de planification et de relais de lecture ne doivent pas redériver le contexte que le répartiteur détient déjà. Les agents d'assurance indépendants doivent redériver indépendamment la vérité pertinente sans lire les verdicts des autres ni consommer les assertions de succès de l'auteur.

Chaque répartition est collecter-puis-arrêter : arrêtez cet agent explicitement une fois son rapport final collecté ; un agent arrêté et interruptible est toujours un agent vivant et compte dans le plafond des agents vivants. Ne laissez jamais un agent terminé en veille pour d'éventuelles suivis.

8. Modèle et effort OMP

OMP utilise des sous-agents markdown natifs avec des listes d'autorisation spawns explicites. Les rôles générés omettent une substitution de modèle et héritent du modèle parent sélectionné. Le casting et l'effort sont donc inherited-only ; agents=auto et les listes de modèles explicites ne sont pas routables via cet adaptateur.

OMP découvre la compétence installée et les fichiers d'agent ap-* à partir de son répertoire d'agents. Les listes spawns natives appliquent les arêtes enfants canoniques et OMP applique le plafond de récursivité.

9. Construction et vérification

Utilisez un TDD strict : écrivez et exécutez le test de comportement défaillant correct, implémentez le changement minimum, refactorez sous vert, exécutez les modules touchés et les dépendants directs, et prouvez une couverture >=95 % des lignes modifiées/modules touchés. Utilisez des exécuteurs et systèmes réels. Ne simulez pas le système testé ni les bases de données dans les tests d'intégration.

La révision de mise en œuvre indépendante et la vérification d'exécution s'exécutent simultanément lorsqu'aucune ne consomme le verdict de l'autre. Le travail de débogage nécessite des preuves de rouge à vert issues du problème et un verrouillage en profondeur à la fonction responsable la plus profonde.

FAIT nécessite une couverture complète de la mission/roadmap, zéro résultat ouvert, une utilisabilité, aucune régression de vert à rouge préexistante, une couverture >=95 % des lignes modifiées, un exercice de bout en bout réel, une validation réussie du registre, zéro sous-agent vivant et un nettoyage lorsque activé.

10. Reprise, pilotage, arbitrage et git

La reprise est explicite : seule une instruction resume explicite ou un relancement superviseur reprend une exécution ; le chargement de compétence, l'invocation nue ou les artefacts résiduels ne le font jamais. La seule lecture de démarrage est la fin de GATELOG.md - sa dernière ligne de frontière porte le pointeur/hachage de mission, le nonce, la dernière porte acceptée et les identifiants d'élément ouverts ; rapportez ce statut en moins de 150 mots et arrêtez-vous lorsqu'aucune frontière n'est active. Sur reprise explicite, vérifiez le hachage du pointeur et répartissez la frontière ouverte avec des mémos pointeurs compacts ; les travailleurs, pas le contexte repreneur, lisent ROADMAP.md, PROMPTS.txt et les preuves substantielles. Traitez les artefacts temporaires, vides ou non analysables comme absents. Ajoutez le pilotage auto-écrit ultérieur au prochain bloc de PROMPTS.txt sans réécrire l'historique.

L'arbitre décide des fourches techniques. Demandez à l'utilisateur en cours d'exécution uniquement pour des actions irréversibles/destructrices véritablement propres à l'utilisateur, de l'argent réel/quota, des identifiants indisponibles ou une orientation produit. N'arbitrez jamais des échecs de capacité, des blocages, une couverture ou une vérification réelle.

Ne validez pas, ne poussez pas, ne publiez pas, ne déployez pas, ne dépensez pas d'argent, ne supprimez pas les données utilisateur, ne forcez pas de push, ne réinitialisez pas en dur et ne nettoyez pas l'arborescence de travail sans autorisation explicite de l'utilisateur.

11. Exécution

Utilisez OMP 17.4.0 ou ultérieur et invoquez explicitement :

/skill:autoprompt <mission>

OMP découvre la compétence installée et les fichiers d'agent ap-* à partir de son répertoire d'agents. Les listes spawns natives appliquent les arêtes enfants canoniques et OMP applique le plafond de récursivité.