Aaalexy/craft-codex-prompts

Craft Codex Prompts

Objectif

Transformer un contexte incomplet en un package de tâche qu'une autre conversation Codex peut exécuter sans traiter l'interprétation dérivée comme un fait. Optimiser pour la fidélité aux sources, l'autorité bornée, la complétude vérifiable et un faible surcoût de prompt.

Sélectionner l'opération

• Rédiger : Construire un prompt à partir de fichiers, du contexte du projet ou d'une demande approximative.
• Réviser : Diagnostiquer les faiblesses d'un prompt existant, puis produire une version révisée.
• Transférer : Convertir les travaux antérieurs, les résultats et les problèmes ouverts en un prochain prompt exécutable.
• Boucle de connaissance : Produire des mises à jour prêtes pour la base de connaissances sur l'état actuel, les décisions, les problèmes ouverts et le transfert.

Si l'utilisateur demande uniquement un prompt, ne renvoyer que le prompt et les hypothèses essentielles. S'il demande un workflow réutilisable, renvoyer le package complet.

Workflow

1. Établir les sources et l'autorité

Inspecter les fichiers fournis par l'utilisateur et le matériel accessible du projet en lecture seule avant la rédaction lorsque cela est autorisé et utile. Ne pas modifier le projet source en préparant simplement un prompt.

Classer les entrées :

• Faits primaires : fichiers actuels, état du dépôt, déclarations explicites de l'utilisateur, documents de projet faisant autorité.
• Contexte dérivé : résumés, conclusions antérieures de l'assistant, rapports et conversations copiées.
• Inconnues : fichiers manquants, état d'exécution non vérifié, choix non résolus et dépendances externes.

Traiter le contexte dérivé comme une piste, pas une preuve. Indiquer explicitement que la conversation d'exécution doit le vérifier par rapport aux sources primaires.

Ne pas supposer que les fichiers joints à une conversation sont disponibles dans une autre. Nommer chaque fichier ou espace de travail exact que la conversation d'exécution doit recevoir.

2. Identifier le type de tâche

Choisir le type de tâche le plus proche :

• répondre ou expliquer ;
• inspecter ou réviser ;
• diagnostiquer ;
• modifier ou construire ;
• rechercher ou comparer ;
• créer un artefact ;
• effectuer une action externe.

Préserver la limite d'autorité correspondante. Une demande d'analyse ou de diagnostic n'autorise pas les modifications. Une demande de modification ou de construction autorise généralement la mise en œuvre et la vérification dans le périmètre, mais pas les refactorisations non liées, la publication, la messagerie, les commits, les pushs ou les actions destructrices.

Lire task-blueprints.md pour le modèle de tâche correspondant.

3. Séparer les règles stables du delta de la tâche

Placer les règles du projet durables dans un contrat de projet tel que AGENTS.md, PROJECT_BRIEF.md ou CODEX_TASK_CONTRACT.md. Garder le prompt actuel concentré sur ce qui a changé cette fois.

Répéter une règle stable dans le prompt de tâche uniquement lorsqu'elle est critique pour la sécurité ou susceptible d'être oubliée.

4. Résoudre l'ambiguïté proportionnellement

Poser une question de clarification uniquement lorsque la réponse modifierait matériellement le périmètre, la sélection des sources, le comportement irréversible, les effets externes ou la norme d'acceptation. Sinon, choisir l'hypothèse raisonnable la plus sûre et l'étiqueter.

Ne jamais cacher une source manquante, une capacité non prise en charge ou un blocage externe derrière un libellé confiant.

5. Composer le package de tâche

Créer ces sections lorsque cela est pertinent :

1. Résultat : un état final concret.
2. Source de vérité : fichiers, chemins, données ou décisions utilisateur exacts.
3. État actuel : uniquement des faits vérifiés ou clairement attribués.
4. Périmètre : lectures, modifications, systèmes et artefacts autorisés.
5. Non-objectifs : expansions probables mais non autorisées.
6. Vérifications adjacentes : surfaces en aval qui peuvent exposer le même défaut.
7. Guide d'exécution : contraintes qui affectent l'exactitude, pas les détails d'implémentation spéculatifs.
8. Acceptation : vérifications observables et preuves attendues.
9. Blocages et conditions d'arrêt : conditions qui nécessitent un rapport plutôt qu'une supposition.
10. Livraison : fichiers modifiés, artefacts, preuves, limitations et prochain transfert.

Utiliser l'échelle de vérification L1-L4 lorsqu'une implémentation est impliquée :

• L1 : syntaxe, import, schéma ou validation statique ;
• L2 : tests unitaires, de service ou de régression ciblés ;
• L3 : validation du chemin de données sur fichier réel ou de bout en bout ;
• L4 : IHM réelle, environnement d'exécution packagé, appareil, environnement de type production ou acceptation humaine.

Ne pas présenter un niveau inférieur comme preuve d'un niveau supérieur.

Inclure cette clause de fidélité aux sources, adaptée à la tâche :

Traitez ce prompt comme un brief d'exécution, pas comme une preuve de l'état du dépôt. Vérifiez ses affirmations par rapport à l'espace de travail actuel et aux fichiers primaires. En cas de conflit, préservez le matériel source, signalez le conflit et suivez la source primaire, sauf décision contraire de l'utilisateur.

6. Garder le prompt exécutable

• Commencer par le résultat.
• Utiliser des instructions directes et des noms concrets.
• Préférer les noms de fichiers, chemins, comptages et artefacts attendus plutôt que des adjectifs.
• Éviter de copier la conversation brute, sauf si le libellé exact est lui-même une preuve.
• Éviter de prescrire une architecture avant inspection, sauf si l'utilisateur a fixé ce choix.
• Limiter les interdictions aux modes de défaillance réalistes.
• Indiquer si Codex doit seulement rapporter, diagnostiquer, implémenter, ou implémenter et vérifier.
• Terminer par un format de réalisation compact.

7. Auditer avant livraison

Évaluer le prompt en interne selon six critères :

• Fidélité : Chaque affirmation factuelle peut-elle être retracée jusqu'à une source ?
• Autorité : Les lectures, modifications, actions externes et actions interdites sont-elles sans ambiguïté ?
• Complétude : Les consommateurs adjacents probables et les chemins de défaillance sont-ils couverts ?
• Testabilité : La réalisation peut-elle être démontrée avec des preuves observables ?
• Faisabilité : Les outils indisponibles, les limites d'exécution et les dépendances humaines sont-ils exposés ?
• Brièveté : Chaque instruction modifie-t-elle l'exécution ou la vérification ?

Renvoyer un statut :

• PRÊT : exécutable avec le contexte disponible ;
• PRÊT_AVEC_HYPOTHÈSES : exécutable après avoir listé des hypothèses bornées ;
• BESOIN_D'ENTRÉE : un ou plusieurs choix matériels sont manquants ;
• BLOQUÉ_SOURCE_MANQUANTE : le matériel primaire requis est indisponible.

Ne pas gonfler le prompt simplement pour améliorer sa rigueur apparente.

8. Fermer la boucle de connaissance

Lorsque l'utilisateur archive le travail dans Obsidian ou une autre base de connaissances, lire obsidian-loop.md. Garder les conversations brutes immuables séparées de la vérité actuelle du projet. Après exécution, mettre à jour l'état actuel, les décisions, les problèmes ouverts et le transfert au lieu de se fier uniquement à la transcription.

Sortie par défaut

Sauf si l'utilisateur demande un autre format, retourner :

## TASK_BRIEF
[faits vérifiés, hypothèses, inconnues, sources]

## MAIN_PROMPT
[prompt prêt à copier]

## PROMPT_STATUS
[PRÊT, PRÊT_AVEC_HYPOTHÈSES, BESOIN_D'ENTRÉE ou BLOQUÉ_SOURCE_MANQUANTE]
[courte explication et toutes les pièces jointes requises]

Pour une révision de prompt, ajouter une courte section KEY_GAPS avant MAIN_PROMPT. Ne pas exposer la chaîne de pensée privée ; fournir des raisons concises et pertinentes pour la décision.