Mode Planification
Utilisez cette compétence lorsque l'utilisateur souhaite un plan plutôt qu'une exécution.
Comportement de base
Pour ce tour, vous êtes en mode planification uniquement.
- N'implémentez pas de code.
- Ne modifiez pas les fichiers du projet, à l'exception du fichier de plan Markdown.
- N'exécutez pas de commandes terminal mutantes, de commit, de push, ou 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 enregistré dans l'espace de travail actif sous
.hermes/plans/.
Exigences de sortie
Rédigez un plan Markdown concret et actionnable.
Incluez, si 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
Enregistrez 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 garde le plan dans l'espace de travail sur les backends local, docker, ssh, modal et daytona.
Si l'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 vraiment sous-spécifiée, posez une brève question de clarification au lieu de deviner.
- Après avoir enregistré le plan, répondez brièvement avec ce que vous avez planifié et le chemin enregistré.
Rédiger un bon plan
Le reste de cette compétence porte sur l'art de rédiger un bon plan d'implémentation — le contenu qui va dans le fichier Markdown ci-dessus.
Aperçu
Rédigez des plans d'implémentation complets en supposant que l'implémenteur n'a aucun contexte sur la codebase et un goût douteux. Documentez tout ce dont il a besoin : quels fichiers toucher, code complet, commandes de test, documentation à consulter, comment vérifier. Donnez-lui des tâches atomiques. DRY. YAGNI. TDD. Commits fréquents.
Supposez que l'implémenteur est un développeur compétent mais qui ne connaît presque rien de la boîte à outils ou du domaine du problème. Supposez qu'il ne maîtrise pas très bien la conception de 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 multi-étapes
- Décomposer des exigences complexes
- Déléguer à des sous-agents via le développement piloté par sous-agent (subagent-driven-development)
À ne pas sauter quand :
- La fonctionnalité semble simple (les hypothèses provoquent 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 atomiques
Chaque tâche = 2 à 5 minutes de travail ciblé.
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 volumineux :
### Tâche 1 : Construire le système d'authentification
[50 lignes de code réparties sur 5 fichiers]
Taille appropriée :
### 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 du mot de passe à User
[8 lignes, 1 fichier]
### Tâche 3 : Créer l'utilitaire de hachage du mot de passe
[15 lignes, 1 fichier]
Structure du document du plan
En-tête (obligatoire)
Chaque plan DOIT commencer par :
# Plan d'implémentation de [Nom de la fonctionnalité]
> **Pour Hermes :** Utilisez la compétence de développement piloté par sous-agent (subagent-driven-development) pour implémenter ce plan tâche par tâche.
**Objectif :** [Une phrase décrivant ce que cela construit]
**Architecture :** [2-3 phrases sur l'approche]
**Pile technologique :** [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 le 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ÉUSSITE
**É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 de la fonctionnalité
- Les documents de conception ou la description utilisateur
- Les critères d'acceptation
- Les contraintes
Étape 2 : Explorer la codebase
Utilisez les outils Hermes pour comprendre le projet :
# Comprendre la structure du projet
search_files("*.py", target="files", path="src/")
# Rechercher 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 modèle 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 les détails complets
Pour chaque tâche, incluez :
- Les chemins exacts des fichiers (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 : Relire le plan
Vérifiez :
- Les tâches sont séquentielles et logiques
- Chaque tâche est atomique (2-5 min)
- Les chemins de fichiers sont exacts
- Les exemples de code sont complets (copiables-colisables)
- Les commandes sont exactes avec le résultat attendu
- Aucun contexte manquant
- Les principes DRY, YAGNI, TDD sont 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 : N'implémenter que 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)
Chaque tâche qui produit du code doit inclure le cycle TDD complet :
- Écrire le test qui échoue
- Exécuter pour vérifier l'échec
- Écrire le code minimal
- Exécuter pour vérifier la réussite
Voir la compétence test-driven-development 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_hash »
Code incomplet
Mauvais : « Étape 1 : Ajouter la fonction de validation » Bon : « Étape 1 : Ajouter la fonction de validation » suivi du code complet de la fonction
Vérification manquante
Mauvais : « Étape 3 : Tester que ça fonctionne »
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 »
Transfert d'exécution
Après avoir enregistré le plan, proposez l'approche d'exécution :
« Plan terminé et enregistré. Prêt à exécuter en utilisant le développement piloté par sous-agent — je vais envoyer un sous-agent frais par tâche avec une revue en deux étapes (conformité aux spécifications puis qualité du code). Dois-je commencer ? »
Lors de l'exécution, utilisez la compétence subagent-driven-development :
- Un
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 validation des spécifications
- Ne continuer que lorsque les deux revues sont approuvées
N'oubliez pas
Tâches atomiques (2-5 min chacune)
Chemins de fichiers exacts
Code complet (copiable-colisable)
Commandes exactes avec résultat attendu
Étapes de vérification
DRY, YAGNI, TDD
Commits fréquents
Un bon plan rend l'implémentation évidente.