FlintSH/delivery

Livraison

L'utilisateur donne l'objectif et les contraintes, puis attend un résultat finalisé et vérifié sans avoir à superviser. Les instructions actuelles et les règles du dépôt prévalent sur tout ce qui suit. Les instructions globales de l'utilisateur peuvent ajouter des spécificités personnelles (limites de la machine, produits, bots de relecture, ton) ; suivez-les.

Établir la tâche

1. Lisez le fichier AGENTS.md/CLAUDE.md du dépôt, l'architecture pertinente, les manifests de paquets et le fichier de verrouillage, ainsi que l'état Git actuel. Inspectez la branche, la base, le ticket et tout espace de travail existant de la tâche avant de modifier quoi que ce soit.
2. Identifiez les critères d'acceptation observables : comportement, configuration, compatibilité, finition UI, preuves de test et la méthode de livraison demandée. Prenez des décisions réversibles raisonnables ; ne posez de questions qu'en cas d'ambiguïté conséquente.
3. Les tâches substantielles et non liées nécessitent des espaces de travail Git isolés. Réutilisez un espace de travail déjà créé par l'infrastructure pour cette tâche. Ne basculez pas et ne réinitialisez pas un checkout partagé. Si plusieurs agents partagent intentionnellement un espace de travail, accordez-vous sur la propriété des fichiers et un seul rédacteur Git. Les demandes antérieures de pousser vers main n'autorisent pas de nouveaux pushes.

Implémenter et vérifier

• Préservez l'identité du produit. Peaufinez les surfaces existantes plutôt que de les reconcevoir, sauf si la tâche demande une refonte.
• Vérifiez les versions du framework et de l'API installés avant d'utiliser de nouvelles API. Consultez la documentation officielle actuelle, ou Context7 lorsqu'il est installé, pour tout comportement non familier ou sensible à la version.
• Pour les cibles de plateforme (serveurs de jeu, versions de système d'exploitation mobile, moteurs de navigateur, environnements d'exécution), vérifiez la compatibilité par rapport à la cible réelle de la compilation et à l'API officielle. Ne testez jamais contre la production en remplacement d'une instance de développement.
• Préférez les commandes de test et de compilation du dépôt. Ajoutez une couverture de tests de régression significative pour les changements de comportement, puis testez les intégrations affectées. Pour le travail UI, utilisez visual-qa sans qu'on vous le rappelle.
• Parallélisez les recherches et les modifications indépendantes lorsque c'est utile, avec une propriété claire. Adaptez la concurrence à la machine : vérifiez le CPU et la mémoire avant d'exécuter plus d'une compilation ou rendu lourd, ou plus de deux sessions de navigateur. N'accumulez pas de serveurs en arrière-plan et ne lancez pas d'essaims d'agents redondants.

Manuels d'ingénierie (pstack)

Cette compétence reste le routeur. Lorsque le plugin pstack de Lauren Tan est installé, utilisez ses manuels pour la méthode d'ingénierie au sein d'une tâche. La plupart des compétences pstack sont manuelles uniquement, lisez donc <pstack>/skills/<nom>/SKILL.md par chemin au lieu d'attendre leur chargement. Avant de suivre un fichier pstack, lisez l'adaptateur pour votre infrastructure une fois par session ; il mappe les noms d'outils, de modèles et de chemins de Cursor.

Résolvez <pstack> pour votre infrastructure :

• Claude Code : ls -d ~/.claude/plugins/cache/cursor-plugins/pstack/*/ | sort -V | tail -1. Adaptateur <pstack>/docs/harness/claude-code.md. Fiche modèle ~/.claude/rules/pstack-models.md, chargée automatiquement.
• Codex : ls -d ~/.codex/plugins/cache/tinderbox-pstack/pstack/*/ | sort -V | tail -1. Adaptateur <pstack>/docs/harness/codex.md. Fiche modèle ~/.codex/pstack-models.md ; lisez-la avant de lancer un modèle de rôle.

Si aucun de ces chemins n'existe, pstack n'est pas installé : travaillez sans.

Forme de la tâche	Lire et suivre
Défaut signalé	skills/poteto-mode/playbooks/bug-fix.md
Lenteur mesurée, ou une métrique à améliorer	perf-issue.md, hillclimb.md
Fuite, boucle ou bug visuel ; profil capturé	runtime-forensics.md, trace-forensics.md
Nouveau comportement ; changement de structure uniquement	feature.md, refactoring.md
Fork de conception empirique	prototype.md au lieu de demander à l'utilisateur
"Comment/pourquoi/sommes-nous sûrs" en lecture seule	investigation.md, skills/how, skills/why
Changement dont la portée est floue	skills/blast-radius avant de modifier
Affirmation de benchmark ou d'accélération	skills/benchmark-checklist avant de la signaler
Un projet sans preuve d'application reproductible	skills/create-verification-skill (demander une fois)
Titre, corps, notes de version de PR	skills/unslop après la rédaction

Les chemins des manuels sont sous <pstack>/skills/poteto-mode/playbooks/. Lisez chaque feuille principle-* citée par un manuel avant de l'appliquer.

Ces règles prévalent là où pstack diffère :

• Livraison. La création de PR, l'IC et les relectures restent avec pr-follow-through et file-pr. Les manuels opening-a-pr, babysit et shipping de pstack sont uniquement du matériel de référence. Sa section sur l'autonomie n'autorise pas les commits, pushes, fusions, messages externes ou déploiements au-delà de la demande en cours.
• Ressources. Le fan-out de arena, swarm, interrogate et architect est limité à trois sous-agents, sauf si l'utilisateur en demande plus. Les voies d'écriture de code reçoivent leur propre espace de travail (isolation : "worktree" dans Claude Code, git worktree add dans Codex). Ignorez autopilot-full et orchestrate sauf si l'utilisateur les demande nommément.
• Modèles. Les fiches modèles mappent les rôles de pstack aux modèles accessibles par l'infrastructure. La relecture inter-fournisseurs reste avec council.
• Parties Cursor manquantes. cursor-team-kit n'est pas installé. Pour /deslop, utilisez pr-review-toolkit:code-simplifier lorsque disponible ; pour control-ui, utilisez visual-qa et playwright-cli ; pour control-cli, exécutez le CLI directement. Ignorez Bugbot, les automatisations Cursor et les étapes d'agent cloud en une ligne, comme le dit l'adaptateur.
• Ton. Les règles de réponse de pstack (phrases courtes, pas de tirets longs, étiquettes de preuve) peuvent être utilisées telles qu'elles sont écrites. Gardez sa reformulation de l'objectif du premier message à deux phrases.

Terminer

• Utilisez pr-follow-through lorsque la demande inclut une PR ou des corrections de relecture.
• Committez, poussez, créez des versions ou fusionnez uniquement lorsque la tâche en cours autorise cette action. Inspectez d'abord l'automatisation des versions du dépôt ; ne présumez pas de la façon dont les versions sont créées.
• Signalez les résultats réels : URLs, scénarios testés, liens vers les preuves, échecs, et tout ce qui nécessite réellement l'action de l'utilisateur. Ne dites pas qu'un aperçu, une compilation de plateforme, une version ou une relecture a réussi sans l'avoir vérifié.
• Avant une réinitialisation du contexte ou une longue attente, laissez un compte-rendu de transfert concis en dehors du code source suivi, par exemple le fichier .agent-artifacts/HANDOFF.md de la tâche. Incluez la branche/espace de travail, l'objectif, les modifications terminées, les commandes/résultats, le SHA de la PR/tête, les bloqueurs, les fichiers possédés, les noms des ressources/sessions, et l'action suivante exacte. N'incluez jamais de tokens.
• Arrêtez uniquement les serveurs et les sessions de navigateur que vous possédez. Conservez les preuves utiles et évitez de supprimer les espaces de travail, caches ou travaux d'utilisateur non liés.