run-milestone

Files (2)

• SKILL.md
• calibration.md

SKILL.md (first lines)

# Mener une milestone

Adapté d'un projet voisin, où la procédure a été établie sur une milestone de
18 tâches traitées de bout en bout par une chaîne de sous-agents. Ce qui suit
est la mécanique qui a marché, plus les erreurs qui ont coûté le plus cher.
**Aucune table de coûts n'est portée** — ces chiffres appartenaient à un autre
domaine et induiraient en erreur ici. Ce projet repart avec un
`calibration.md` vide (à côté de ce fichier) ; le remplir fait partie de la
clôture de chaque milestone (phase 5).

La session principale **n'implémente jamais**. Elle résout l'ordre, fait
trancher les arbitrages par l'utilisateur, briefe un sous-agent par tâche et
consigne les résultats. Un agent à la fois — jamais en parallèle, ils se
battraient pour les mêmes fichiers.

Les phases 1 à 5 tournent **une fois par milestone**. Quand l'utilisateur en
demande plusieurs, la phase 0 monte la chaîne et la phase 6 franchit chaque
frontière pour revenir en phase 1 ; les phases intermédiaires ne chevauchent
jamais deux milestones.

## Runtime gate — Claude Code vs Kimi Code

Cette règle gouverne chaque décision de modèle de cette skill.

**Convention de labels, active dans ce dépôt** : chaque tâche backlog porte un
seul label reflétant sa complexité réelle —

- `model:secondaire` — **le défaut** : implémentations guidées par un plan,
  éditions localisées, scripts, docs. Tourne sur le modèle secondaire
  (`kimi-for-coding`).
- `model:primaire` — réservé à l'architecture difficile, la concurrence, les
  cas simultanés ou l'ordonnancement. Tourne sur le modèle primaire (`k3`).

Une tâche qui mêle une partie difficile et une partie standard se découpe en
sous-tâches (`backlog task create -p <ID> ...`) pour isoler la partie primaire
dans une sous-tâche dédiée. Le hook `post-task-create` rappelle cette règle
après chaque création de tâche.

- **Claude Code** : les sous-agents se lancent avec l'outil `Task`, et le
  label `model:primaire`/`model:secondaire` de la tâche choisit le modèle du
  sous-agent — voir phase 3.
- **Kimi Code** : les sous-agents se lancent avec l'outil **`Agent`** (pas
  `Task`), en avant-plan et un à la fois. **`AgentSwarm` est proscrit ici** :
  il parallélise, et la règle d'or est un agent à la fois. Le label choisit le
  modèle via le **paramètre `model` de l'outil `Agent`** :
  `model:secondaire` → `model="kimi-code/kimi-for-coding"`,
  `model:primaire` → `model="kimi-code/k3"` (ou `"primary"`). À défaut de
  paramètre explicite, un sous-agent tombe sur le `default_model` de la
  section `[secondary_model]` de `config.toml` — configurée ici avec
  `kimi-for-coding` en défaut et les deux modèles en pool — et rien dans sa
  sortie ne le dit. Les skills de travail de ce dépôt sont dans
  `.kimi-code/skills/`.

La règle de découpage du backlog (isoler une partie difficile dans sa propre
sous-tâche) vaut sous les deux runtimes ; seul le *forçage* du modèle dépend
du runtime.

## Phase 0 — Cadrer la chaîne

Passer directement en phase 1 quand l'utilisateur a nommé exactement une
milestone. Faire cette phase quand il en a nommé plusieurs, a dit « le reste »,
ou demandé quelque chose qu'une milestone active seule ne peut pas livrer.

1. **Voir l'ensemble actif**, milestones closes comprises quand une dépendance
   pointe en arrière.

   ```bash
   backlog milestone list --plain
   ```

2. **Ordonner les milestones.** Elles ne portent **pas de champ de
   dépendance** — `backlog milestone` ne fait que lister, ajouter, renommer,
   retirer, archiver. L'ordre vient de deux sources, dans cet ordre :

   - **Les dépendances de tâches qui franchissent une frontière de
     milestone.** Une tâche d'une milestone tardive dépendant d'une tâche
     d'une milestone plus tôt ordonne la paire. C'est la seule preuve dure.
   - **La description de chaque milestone.** Une milestone qui valide ou
     construit sur ce qu'une autre livre vient après elle, même sans
     dépendance enregistrée.

   La numérotation est un indice, jamais une preuve. Dire pour chaque paire
   laquelle des deux sources a servi.

3. **Annoncer le budget cumulé avant que quoi que ce soit commence.** Par
   milestone : le nombre de tâches restantes, leurs natures, et une
   fourchette — lire d'abord `calibration.md` (à côté de ce fichier) plutôt
   que citer de mémoire ; il démarre vide et se remplit à mesure que les
   milestones se closent. Tant qu'il est vide, les seuls repères sont les
   attentes générales de la section « À quoi s'attendre », et tout montant en
   USD n'y vaut qu'à titre d'exemple d'ordre de grandeur.

   Puis le total de la chaîne, en fourchette, et la phrase qui compte :
   **c'est un ordre de grandeur, pas un devis**, surtout avant que ce projet
   ait ses propres données de calibration. Énoncer séparément le coût de la
   première milestone : c'est elle l'engagement que l'utilisateur prend
   réellement maintenant.

4. **Proposer les points d'arrêt.** Le défaut est de rendre la main à chaque
   frontière : la milestone est close, ses chiffres rapportés, et l'utilisateur
   dit s'il faut franchir. Continuer sans arrêt est un choix que l'utilisateur
   fait explicitement, et il reste révocable — la phase 5 rapporte à chaque
   frontière quand même.

   ⚠️ **Une frontière de milestone est le seul arrêt prévu. Rien d'autre
   n'arrête la chaîne qu'un arbitrage qui revient genuinement à
   l'utilisateur.** L'heure, la fatigue présumée de l'utilisateur, le souhait
   qu'il soit réveillé pour lire un résultat, la longueur de la session — rien
   de tout cela n'est une raison. Ce sont des décisions prises à sa place, sur
   des choses qui ne regardent pas la chaîne, et elles transforment un run
   autonome en attente. Une tâche qui peut avancer sans l'utilisateur avance.

   Ce qui *arrête* la chaîne, et doit être nommé comme tel plutôt que déguisé
   en circonstance : une question de périmètre, un critère impossible à prouver
   sans lui (sa machine, ses yeux, son compte), un fork de conception, un coût
   qui a dépassé la fourchette annoncée. Pour ce dernier, la phase 6 étape 5
   dit déjà quoi faire — énoncer le chiffre et la fourchette promise, puis
   **continuer sauf objection**, plutôt qu'attendre un feu vert. Rapporter
   n'est pas s'arrêter.

From elpfries/bob-sideshow, MIT.

More from elpfries/bob-sideshow