Mode Planification
Utilisez ce skill lorsque l’utilisateur souhaite un plan plutôt qu’une exécution.
Comportement principal
Pour ce tour, vous êtes en mode planification uniquement.
- N’implémentez pas de code.
- Ne modifiez pas les fichiers du projet, sauf le fichier Markdown du plan.
- N’exécutez pas de commandes terminal mutantes, ne faites pas de commit, de push, ni d’actions externes.
- Vous pouvez inspecter le dépôt ou tout autre contexte avec des commandes/outils en lecture seule si nécessaire.
- Votre livrable est un plan Markdown sauvegardé dans l’espace de travail actif, sous
.hermes/plans/.
Exigences de sortie
Rédigez un plan Markdown concret et actionnable.
Incluez, lorsque pertinent :
- Objectif
- Contexte actuel / hypothèses
- Approche proposée
- Plan étape par étape
- Fichiers susceptibles d’être modifiés
- Tests / validation
- Risques, compromis et questions ouvertes
Si la tâche est liée au code, incluez les chemins exacts des fichiers, les cibles de test probables et les étapes de vérification.
Emplacement de sauvegarde
Sauvegardez le plan avec write_file sous :
.hermes/plans/YYYY-MM-DD_HHMMSS-<slug>.md
Considérez cela comme relatif au répertoire de travail actif / espace de travail backend. Les outils de fichiers Hermes sont conscients du backend, donc l’utilisation de ce chemin relatif conserve le plan dans l’espace de travail sur les backends local, Docker, SSH, Modal et Daytona.
Si l’environnement d’exécution fournit un chemin cible spécifique, utilisez ce chemin exact.
Sinon, créez vous‑même un nom de fichier horodaté pertinent sous .hermes/plans/.
Style d’interaction
- Si la demande est suffisamment claire, rédigez le plan directement.
- Si aucune instruction explicite n’accompagne
/plan, déduisez la tâche du contexte actuel de la conversation. - Si elle est véritablement sous‑spécifiée, posez une brève question de clarification au lieu de deviner.
- Après avoir sauvegardé le plan, répondez brièvement avec ce que vous avez planifié et le chemin sauvegardé.
Bien rédiger le plan
Le reste de ce skill est l’art d’écrire un bon plan d’implémentation — le contenu qui va à l’intérieur du fichier Markdown ci‑dessus.
Vue d’ensemble
Rédigez des plans d’implémentation complets en supposant que l’implémenteur n’a aucun contexte sur la base de code et un goût douteux. Documentez tout ce dont il a besoin : quels fichiers modifier, code complet, commandes de test, documentation à consulter, comment vérifier. Donnez‑lui des tâches de petite taille. DRY. YAGNI. TDD. Commits fréquents.
Supposez que l’implémenteur est un développeur compétent mais qu’il ne sait presque rien de l’outillage ou du domaine du problème. Supposez qu’il ne connaît pas très bien la conception de bons tests.
Principe fondamental : Un bon plan rend l’implémentation évidente. Si quelqu’un doit deviner, le plan est incomplet.
Quand un plan d’implémentation complet est utile
À utiliser toujours avant :
- Implémenter des fonctionnalités en plusieurs étapes
- Décomposer des exigences complexes
- Déléguer à des sous‑agents via le développement piloté par sous‑agent
Ne pas sauter quand :
- La fonctionnalité semble simple (les hypothèses causent des bugs)
- Vous prévoyez de l’implémenter vous‑même (le vous futur a besoin de conseils)
- Vous travaillez seul (la documentation compte)
Granularité des tâches de petite taille
Chaque tâche = 2 à 5 minutes de travail concentré.
Chaque étape est une action :
- « Écrire le test qui échoue » — étape
- « L’exécuter pour vérifier qu’il échoue » — étape
- « Implémenter le code minimal pour faire passer le test » — étape
- « Exécuter les tests et vérifier qu’ils passent » — étape
- « Commiter » — étape
Trop gros :
### Tâche 1 : Construire le système d’authentification
[50 lignes de code dans 5 fichiers]
Bonne taille :
### Tâche 1 : Créer le modèle User avec le champ email
[10 lignes, 1 fichier]
### Tâche 2 : Ajouter le champ de hachage de mot de passe à User
[8 lignes, 1 fichier]
### Tâche 3 : Créer l’utilitaire de hachage de mot de passe
[15 lignes, 1 fichier]
Structure du document de plan
En‑tête (obligatoire)
Chaque plan DOIT commencer par :
# Plan d’implémentation : [Nom de la fonctionnalité]
> **Pour Hermes :** Utilisez le skill développement piloté par sous‑agent pour implémenter ce plan tâche par tâche.
**Objectif :** [Une phrase décrivant ce qui est construit]
**Architecture :** [2 à 3 phrases sur l’approche]
**Stack technique :** [Technologies / bibliothèques clés]
---
Structure des tâches
Chaque tâche suit ce format :
### Tâche N : [Nom descriptif]
**Objectif :** Ce que cette tâche accomplit (une phrase)
**Fichiers :**
- Créer : `chemin/exact/vers/nouveau_fichier.py`
- Modifier : `chemin/exact/vers/fichier_existant.py:45-67` (numéros de ligne si connus)
- Test : `tests/chemin/vers/fichier_test.py`
**Étape 1 : Écrire un test qui échoue**
```python
def test_comportement_specifique():
resultat = fonction(entree)
assert resultat == attendu
```
**Étape 2 : Exécuter le test pour vérifier l’échec**
Exécuter : `pytest tests/chemin/test.py::test_comportement_specifique -v`
Attendu : ÉCHEC — « fonction non définie »
**Étape 3 : Écrire l’implémentation minimale**
```python
def fonction(entree):
return attendu
```
**Étape 4 : Exécuter le test pour vérifier la réussite**
Exécuter : `pytest tests/chemin/test.py::test_comportement_specifique -v`
Attendu : RÉUSSI
**Étape 5 : Commiter**
```bash
git add tests/chemin/test.py src/chemin/fichier.py
git commit -m "feat: ajouter la fonctionnalité spécifique"
```
Processus de rédaction
Étape 1 : Comprendre les exigences
Lisez et comprenez :
- Les exigences fonctionnelles
- Les documents de conception ou la description utilisateur
- Les critères d’acceptation
- Les contraintes
Étape 2 : Explorer la base de code
Utilisez les outils Hermes pour comprendre le projet :
# Comprendre la structure du projet
search_files("*.py", target="files", path="src/")
# Chercher des fonctionnalités similaires
search_files("motif_similaire", path="src/", file_glob="*.py")
# Vérifier les tests existants
search_files("*.py", target="files", path="tests/")
# Lire les fichiers clés
read_file("src/app.py")
Étape 3 : Concevoir l’approche
Décidez :
- Le motif d’architecture
- L’organisation des fichiers
- Les dépendances nécessaires
- La stratégie de test
Étape 4 : Rédiger les tâches
Créez les tâches dans l’ordre :
- Configuration / infrastructure
- Fonctionnalité principale (TDD pour chacune)
- Cas limites
- Intégration
- Nettoyage / documentation
Étape 5 : Ajouter des détails complets
Pour chaque tâche, incluez :
- Les chemins de fichiers exacts (pas « le fichier de configuration » mais
src/config/settings.py) - Des exemples de code complets (pas « ajouter la validation » mais le code réel)
- Les commandes exactes avec le résultat attendu
- Les étapes de vérification qui prouvent que la tâche fonctionne
Étape 6 : Réviser le plan
Vérifiez :
- Les tâches sont séquentielles et logiques
- Chaque tâche est de petite taille (2 à 5 min)
- Les chemins de fichiers sont exacts
- Les exemples de code sont complets (copier‑coller)
- Les commandes sont exactes avec le résultat attendu
- Aucun contexte manquant
- Principes DRY, YAGNI, TDD appliqués
Principes
DRY (Ne vous répétez pas)
Mauvais : Copier‑coller la validation à 3 endroits Bon : Extraire la fonction de validation, l’utiliser partout
YAGNI (Vous n’en aurez pas besoin)
Mauvais : Ajouter de la « flexibilité » pour des exigences futures Bon : Implémenter uniquement ce qui est nécessaire maintenant
# Mauvais — violation YAGNI
class Utilisateur:
def __init__(self, nom, email):
self.nom = nom
self.email = email
self.preferences = {} # Pas encore nécessaire !
self.metadonnees = {} # Pas encore nécessaire !
# Bon — YAGNI
class Utilisateur:
def __init__(self, nom, email):
self.nom = nom
self.email = email
TDD (Développement piloté par les tests)
Toute tâche qui produit du code doit inclure le cycle complet TDD :
- Écrire un test qui échoue
- L’exécuter pour vérifier l’échec
- Écrire le code minimal
- L’exécuter pour vérifier la réussite
Voir le skill developpement-pilote-par-les-tests pour plus de détails.
Commits fréquents
Commitez après chaque tâche :
git add [fichiers]
git commit -m "type: description"
Erreurs courantes
Tâches vagues
Mauvais : « Ajouter l’authentification » Bon : « Créer le modèle Utilisateur avec les champs email et mot_de_passe_hache »
Code incomplet
Mauvais : « Étape 1 : Ajouter une fonction de validation » Bon : « Étape 1 : Ajouter une fonction de validation » suivi du code complet de la fonction
Vérification manquante
Mauvais : « Étape 3 : Tester que ça marche »
Bon : « Étape 3 : Exécuter pytest tests/test_auth.py -v, attendu : 3 réussis »
Chemins de fichiers manquants
Mauvais : « Créer le fichier modèle »
Bon : « Créer : src/models/user.py »
Relais d’exécution
Après avoir sauvegardé le plan, proposez l’approche d’exécution :
« Plan terminé et sauvegardé. Prêt à exécuter en utilisant le développement piloté par sous‑agent — j’enverrai un sous‑agent frais par tâche avec une revue en deux étapes (conformité aux spécifications puis qualité du code). Dois‑je continuer ? »
Lors de l’exécution, utilisez le skill developpement-pilote-par-sous-agent :
delegate_taskfrais par tâche avec le contexte complet- Revue de conformité aux spécifications après chaque tâche
- Revue de qualité du code après la conformité
- Passez à la tâche suivante uniquement lorsque les deux revues approuvent
À retenir
Tâches de petite taille (2 à 5 min chacune)
Chemins de fichiers exacts
Code complet (copier‑coller)
Commandes exactes avec résultat attendu
Étapes de vérification
DRY, YAGNI, TDD
Commits fréquents
Un bon plan rend l’implémentation évidente.