ritamgh/claude-skills

Contrat de preuve

Créez des plans qui sont testables et fondés sur le dépôt réel plutôt que sur des suppositions plausibles.

Activation

Appliquez cette compétence automatiquement lorsque la tâche nécessite un plan d'implémentation non trivial ou une révision de plan. N'attendez pas que l'utilisateur l'invoque explicitement.

Ignorez le contrat complet pour les modifications triviales où la cible, le comportement et la vérification sont déjà évidents. Indiquez plutôt la vérification simple.

Cette compétence est réservée à la planification. Ne modifiez pas les fichiers d'implémentation sauf si l'utilisateur vous a également demandé d'exécuter le plan.

Flux de travail

1. Établir l'intention et le succès

Résumez le résultat souhaité en une phrase. Extrayez le comportement d'acceptation concret de la demande. Si le libellé est ambigu, enquêtez dans le dépôt avant de demander à l'utilisateur. Ne demandez que lorsque des résultats sensiblement différents restent possibles après enquête.

2. Rassembler le minimum de preuves suffisant

Avant de proposer une architecture ou de nommer les fichiers affectés :

1. Lisez PROJECT_CONTEXT.md s'il est présent.
2. Localisez les points d'entrée des fonctionnalités avec une recherche ciblée.
3. Lisez le plus petit ensemble de fichiers d'implémentation, de configuration et de test pertinents.
4. Tracez les appelants importants, les dépendances, les limites de persistance et les interfaces publiques.
5. Enregistrez les contradictions entre la documentation et le code. Traitez le code et le comportement exécutable comme des preuves plus fortes.

Évitez les analyses larges du dépôt lorsque des preuves ciblées suffisent.

3. Classifier chaque affirmation matérielle

Utilisez ces étiquettes en interne et exposez-les lorsque c'est utile :

• Observé : directement soutenu par un fichier, un symbole, un résultat de commande, un test ou une observation d'exécution.
• Inféré : fortement impliqué par des preuves observées mais non démontré directement.
• Inconnu : information matérielle qui n'a pas été établie.

Ne présentez jamais une affirmation inférée ou inconnue comme un fait. Incluez un emplacement de code ou une observation d'outil pour les affirmations observées importantes. N'inventez pas de chemins de fichiers, d'API, de dépendances ou de comportements existants.

4. Résoudre les inconnues bloquantes

Enquêtez sur les inconnues qui pourraient modifier l'architecture, la portée, le flux de données, la compatibilité ou le comportement d'acceptation. Si une inconnue ne peut pas être résolue localement :

• énoncez-la explicitement,
• expliquez pourquoi elle est importante,
• proposez l'hypothèse bornée la plus sûre, et
• demandez à l'utilisateur uniquement si procéder pourrait produire le mauvais résultat.

5. Produire un plan avec preuve

Chaque élément de plan non trivial doit inclure :

1. Modification : la plus petite étape d'implémentation cohérente.
2. Preuve : faits observés du dépôt qui justifient l'étape, avec les chemins ou symboles pertinents.
3. Surface affectée : fichiers, interfaces, données, appelants, dépendances ou workflows susceptibles de changer.
4. Vérification : un test exécutable, une construction, un lint, une exécution ou une observation d'acceptation.
5. Risque ou hypothèse : uniquement lorsque c'est matériel, étiqueté inféré ou inconnu.

Préférez les plans qui font correspondre une exigence à une vérification observable. Incluez une couverture de régression pour les corrections de bugs et les modifications sensibles à la compatibilité.

6. Exécuter la porte de planification

Avant de présenter le plan, vérifiez :

• Chaque résultat demandé correspond à au moins un élément du plan.
• Chaque élément du plan a une preuve et une vérification concrète.
• Les fichiers et symboles nommés ont été observés, non devinés.
• Les hypothèses matérielles sont visibles et classifiées.
• Les dépendances et les limites d'intégration sont couvertes.
• Le plan utilise la plus petite modification qui satisfait la demande.
• Aucune fonctionnalité spéculative ou refactorisation non liée n'a été ajoutée.

Si la porte échoue, enquêtez ou révisez le plan avant de le renvoyer.

Format de sortie

Gardez le résultat concis sauf si la tâche est complexe.

## Contrat de preuve
- Observé : `chemin/vers/fichier` établit ...
- Inféré : ... parce que ...
- Inconnu : ... ; hypothèse bornée ou décision requise ...

## Plan
1. **Modification** ...
   - Preuve : ...
   - Affecté : ...
   - Vérifier : ...
   - Risque/hypothèse : ...

## Porte d'achèvement
- [ ] La correspondance exigence-vérification est complète
- [ ] Aucune hypothèse non étiquetée ne subsiste
- [ ] Les vérifications d'acceptation sont exécutables

Omettez les sections inférées ou inconnues vides. Pour les petits plans, compressez chaque élément en une seule ligne tout en conservant la preuve et la vérification.

Anti-patrons

Ne faites pas :

• produire un plan à partir des seuls noms de fichiers,
• utiliser "probablement", "vraisemblablement" ou "devrait" sans marquer une inférence,
• prétendre que les tests passent sans les exécuter,
• substituer une vérification simulée à un chemin d'acceptation réel disponible,
• accabler l'utilisateur de questions auxquelles le dépôt permet de répondre,
• transformer le contrat en paperasse pour des modifications triviales,
• commencer l'implémentation simplement parce que le plan est complet.