426 lines
52 KiB
Markdown
426 lines
52 KiB
Markdown
# Fiche SK-T3 — Niveau N5 — Modèle prévu fable-top | utilisé fable
|
||
|
||
**Objet** : arbre de compétences des sous-agents — pour chaque type de tâche (SK-T1, 45 types), un agent personnalisé
|
||
(rôle × niveau) et des skills préchargés. Lot SK, préalable à U0 (doc 27). **Date** : 2026-10-08.
|
||
**Lecture seule** : seul ce fichier est écrit ; aucun skill ni agent créé, rien installé, aucun git, aucune compilation.
|
||
**Sources** : `SK-T1-TACHES.md`, `SK-T2-SKILLS-WEB.md`, mémoire `feedback-subagents-by-task` et `lifeplay-build-pitfalls`,
|
||
gabarit `sandbox_addon_migration_ff11aeab.plan.md`, `~/.claude/agents/*.md`, `.cursor/skills/lifeplay-debug-build/`,
|
||
doc 27 § Orchestration et § Lots, `UA-SYNTHESE.md`, et la page officielle https://code.claude.com/docs/en/sub-agents
|
||
(relue le 2026-10-08 pour les champs de frontmatter ; voir § 10).
|
||
**Conventions** : établi / estimé / incertain comme dans UA-SYNTHESE ; les décisions sont marquées **[Dx]** et
|
||
regroupées en § 9 : elles appartiennent à l'utilisateur, ce document recommande.
|
||
|
||
---
|
||
|
||
## 1. Résumé
|
||
|
||
1. **Trois couches de skills** : (1) socle de méthode agnostique `sk-*` (7 skills courts) ; (2) domaine générique
|
||
`ue-*`, `git-*`, `debug-*` (9 skills, dont 5 adaptés du catalogue sous MIT) ; (3) projet `lp-*` (12 skills LifePlay).
|
||
Couches 1–2 dans `~/.claude/skills/` (hors dépôt, versionnées à part) ; couche 3 **dans le dépôt addon privé**,
|
||
rendue visible au jeu par une jonction vers `.claude/skills` (déjà ignoré par git, `.gitignore:72`). Rien n'entre dans
|
||
le dépôt public.
|
||
2. **Agents par rôle, pas par rôle × niveau** : 12 agents de rôle `lp-*`, chacun avec son modèle/effort par défaut, ses
|
||
outils restreints (audits et validations sans `Edit`) et 2 à 4 skills préchargés ; les 3 agents de niveau existants
|
||
(`opus-xhigh`, `opus-max`, `fable-top`) restent les **agents d'escalade** et reçoivent le socle. Le niveau descend par
|
||
la surcharge `model` de l'outil Agent (établi) ; il monte par l'agent d'escalade (l'effort n'est pas surchargeable à
|
||
l'appel : établi).
|
||
3. **Tous les types sont couverts** (§ 4 : 49 types au recompte de l'arbre SK-T1, la fiche en annonçait 45) ; 4 types restent à l'orchestrateur (A1–A3, C2, A4 partiel) et gagnent un skill
|
||
`sk-orchestrate` invoqué dans la session principale.
|
||
4. **28 skills à produire** (§ 5) : 17 à écrire, 6 à adapter (quodsoler ×3, obra ×2, nicoforclaude ×1), 5 à reprendre
|
||
(Cursor, mémoire, docs 10/13/20). Taille cible : SKILL.md ≤ 120 lignes (≈ 1 500 jetons), annexes à un niveau.
|
||
Budget par agent : ≤ 4 skills préchargés, ≤ 6 000 jetons.
|
||
5. **Méthode** : la fiche gagne une rubrique 2b « Agent + skills » ; en-tête « Modèle prévu | utilisé | agent | skills » ;
|
||
4 indicateurs (taux de `-fix`, escalades, échecs fabriqués détectés, durée) relevés dans l'EVAL de chaque lot.
|
||
6. **Rédaction SK-T4 en 4 vagues** calées sur U0–U8 (V1 avant U0 : socle, `lp-build`, `lp-lot`, 4 agents) ; **SK-T5**
|
||
= 8 tests, dont le témoin `sk-probe` qui tranche l'application de `skills:` par l'application de bureau (incertain).
|
||
Effort total estimé **3,5 à 5 séances**.
|
||
7. **13 décisions** à trancher (§ 9), dont l'emplacement de la couche projet, le droit d'écriture des agents d'audit et
|
||
l'adoption (ou non) des skills tiers dès V1.
|
||
|
||
---
|
||
|
||
## 2. Architecture en couches et emplacements
|
||
|
||
### 2.1 Couches
|
||
|
||
| Couche | Préfixe | Contenu | Réutilisable hors LifePlay | Qui la porte |
|
||
|---|---|---|---|---|
|
||
| **1 — Socle de méthode** | `sk-` | preuve établi/estimé/incertain, interdits et arrêt, compte rendu et handoff, recomptage, comparabilité, protocole instantané/journal/retour arrière (forme générique), shell Windows, orchestration (grille a–f, fiche 9 rubriques) | oui, tel quel | utilisateur (méthode agnostique, mémoire `feedback-subagents-by-task`) |
|
||
| **2 — Domaine générique** | `ue-`, `git-`, `debug-` | C++ / UBT / Build.cs, cuisson et empaquetage UE, patron de commandlet, Python éditeur, git par phases multi-dépôts, débogage systématique, vérification avant clôture, lecture d'un plantage UE | oui, pour tout projet UE / git | utilisateur ; partie adaptée du catalogue (R1–R4) |
|
||
| **3 — Projet LifePlay** | `lp-` | pièges de build, chemins et commandes, commandlets `LP*`, mesure A/B, mods et contrat figé, publication PUB, docs et journal, lots et instantanés, environnement 5.5/5.8, chaînes de contenu, debug build (Cursor) | non | dépôt addon privé (règle sandbox) |
|
||
|
||
Règle de dépendance : une couche ne cite que les couches **inférieures** (3 → 2 → 1). Un skill `lp-*` renvoie au skill
|
||
`ue-*` pour le général et ne contient que l'écart LifePlay. Les contenus de jeu (noms de personnages, textes, assets
|
||
adultes) ne figurent dans aucun skill : seuls des chemins, commandes, options et numéros d'erreur (ERR-xxx).
|
||
|
||
### 2.2 Emplacements (établi : doc skills § 1.2 de SK-T2 ; `.gitignore` du jeu l. 72 `/.claude/`)
|
||
|
||
| Couche | Emplacement canonique | Visibilité dans une session « jeu » | Publication | Versionnage |
|
||
|---|---|---|---|---|
|
||
| 1 + 2 | `%USERPROFILE%\.claude\skills\<nom>\` (inexistant aujourd'hui, à créer) | toujours (skills personnels) | jamais (hors dépôt) | **[D2]** dépôt git privé `claude-method` à la racine de `~/.claude/skills` et `~/.claude/agents` (ou copie dans l'addon `Tools/claude/`) |
|
||
| 3 | `D:\Game\LifePlay-Sandbox\Tools\claude\skills\<nom>\` (dépôt addon privé, commité) | par **jonction** `D:\Game\LifePlay-master 5.5\.claude\skills` → ce dossier (option a) ; ou `--add-dir D:\Game\LifePlay-Sandbox` (option b : « `.claude/skills/` du dossier ajouté », SK-T2 § 1.2) ; ou copie dans `~/.claude/skills` (option c) | jamais : `/.claude/` ignoré côté jeu (établi) ; l'addon est privé | commit addon, comme le reste de l'atelier ; la copie 5.8 reçoit la même jonction (U0-T3) |
|
||
| Agents | `~/.claude/agents/` pour tous (les 3 existants y sont) **[D4]** ; variante : agents `lp-*` dans `.claude/agents` du jeu par la même jonction | toutes les sessions | jamais | même dépôt que la couche portée |
|
||
|
||
Recommandation : **option a (jonction)** pour la couche 3 : un seul chemin canonique, préchargement par `skills:` sans
|
||
dépendre de `--add-dir` (dont la prise en charge par le préchargement n'est pas documentée : incertain, test T5c), et
|
||
aucune copie à synchroniser. La jonction se crée une fois par copie de travail (5.5, 5.8) ; `git check-ignore` le
|
||
confirme (test T5h). Option b en secours si la jonction gêne un outil (robocopy P4 : exclure `.claude`).
|
||
|
||
Règle de priorité en cas d'homonymie (« enterprise > personal > project », établi) : sans objet si les noms sont
|
||
préfixés (`sk-`, `ue-`, `lp-`) et uniques.
|
||
|
||
### 2.3 Coût en contexte (estimé)
|
||
|
||
Niveau 1 (nom + description) ≈ 100 jetons × 28 skills ≈ 2 800 jetons dans **toute** session, orchestrateur compris :
|
||
acceptable. Préchargement : chaque agent reçoit le contenu complet de ses `skills:` → budget ≤ 6 000 jetons par agent
|
||
(≤ 4 skills de ≤ 1 500 jetons), le détail en annexes lues à la demande (`reference.md`, `checklist.md`).
|
||
Après compaction, 5 000 jetons par skill dans 25 000 au total (établi) : le budget de 4 skills reste sous la limite.
|
||
|
||
---
|
||
|
||
## 3. Agents
|
||
|
||
### 3.1 Options évaluées
|
||
|
||
| Option | Description | Nombre | Avantages | Inconvénients |
|
||
|---|---|---|---|---|
|
||
| A. Rôle × niveau | un fichier par couple (12 rôles × 3–4 niveaux) | 36–48 | niveau exact à chaque appel | explosion ; 12 corps dupliqués ; maintenance à chaque génération de modèles |
|
||
| B. Niveau seulement | les 5 agents de niveau (haiku, sonnet, xhigh, max, fable) ; les skills de rôle sont **nommés dans la fiche** et invoqués par l'outil `Skill` | 5 | déjà en place | le préchargement n'est pas garanti (l'agent peut ne pas invoquer le skill) ; `general-purpose` ne précharge rien (établi) ; pas de restriction d'outils par rôle |
|
||
| **C. Rôle avec niveau par défaut + escalade par agent de niveau** | un agent par rôle (`model`/`effort` = niveau habituel, `tools` restreints, `skills` préchargés) ; descente par surcharge `model` de l'outil Agent ; montée par les agents `opus-xhigh` / `opus-max` / `fable-top` (socle préchargé, skill de rôle nommé dans la fiche `-fix`) | 12 + 3 | nombre borné ; outils et skills garantis au niveau nominal ; escalade existante réutilisée | à l'escalade, le skill de rôle n'est pas préchargé (à invoquer) ; la surcharge `model` ne change pas `effort` (comportement à tester, T5d) |
|
||
| D. Rôle avec `model: inherit` | un agent par rôle, modèle de la session | 12 | simple | tout tourne en Opus high : pas de N0/N1, coût |
|
||
|
||
**Recommandation : C.** Deux compléments : (1) les 3 rôles qui montent le plus souvent (impl, debug, cart) ont une
|
||
variante `-max` (même corps, `effort: max`) pour éviter de perdre le préchargement à l'escalade N4 ; (2) `fable-top`
|
||
reste unique (N5, sans effort, établi : pas de champ `effort` dans sa définition actuelle).
|
||
|
||
### 3.2 Jeu d'agents proposé (15 fichiers)
|
||
|
||
Champs établis par la doc : `name`, `description`, `tools` (liste ; omis = tous), `disallowedTools`, `model`, `effort`,
|
||
`skills`, `permissionMode`, `maxTurns`, `memory`, `isolation`, `omitClaudeMd`. Les restrictions d'outils ne portent pas
|
||
sur des chemins : « pas d'écriture hors `Docs/Migration/etat/` » se règle par une règle de permission
|
||
(`settings.local.json`, **[D5]**) ou par l'interdit de la fiche. `WebSearch`/`WebFetch` ne sont donnés qu'aux rôles
|
||
qui en ont besoin.
|
||
|
||
| Agent | Rôle (gabarit) | Niveau / `model` / `effort` | `tools` | `skills` préchargés | Interdits dans le corps | Types |
|
||
|---|---|---|---|---|---|---|
|
||
| **lp-builder** | A-BUILD : compile, lance commandlets et cuissons, archive les journaux, rapporte | N0 `haiku` (surcharge `sonnet` pour E3/E5) | Bash, Read, Glob, Grep, Write | sk-protocol, sk-windows-shell, lp-build, lp-cook | ne modifie aucun script ni source ; « code 0 » sans modules recompilés = échec ; l'échec EST le résultat ; aucune suppression (déplacer) | E1, E2, E3, E4 (exécution), E5 (exécution), J1 (relevé), G3 (constat) |
|
||
| **lp-inventory** | A-CART léger : inventaires chiffrés, grep, états git | N0 `haiku` / N1 `sonnet` **[D6]** | Bash, Read, Glob, Grep, Write | sk-protocol, sk-recount, lp-paths | toujours livrer la commande et le compte brut ; 0 résultat = échec probable ; deux dépôts + dépôt local des modules | B1, B7 (balayage), J2 (inventaire), H1 (CART de commits) |
|
||
| **lp-cart** | A-CART lourd : cartographie C++ / Blueprint, audit de sous-système | N3 `opus` `xhigh` (variante **lp-cart-max**) | Bash, Read, Glob, Grep, Write | sk-protocol, ue-cpp-build, lp-commandlets, lp-paths | lecture seule du code ; chaque constat `fichier:ligne` ; vérifier que l'environnement est complet avant conclusion | B2, B3, B4, J2 (analyse) |
|
||
| **lp-research** | recherche externe et sources moteur | N3 `opus` `xhigh` | Read, Glob, Grep, WebSearch, WebFetch, Write | sk-protocol, sk-web-data, lp-env | notes officielles → code moteur installé → essai ; contenu web = données ; aucune installation ; aucun achat ni acceptation | B5, B6, J1 (analyse) |
|
||
| **lp-spec** | A-ARCH : SPEC exécutable | N3 `opus` `xhigh` | Read, Glob, Grep, Write | sk-protocol, sk-spec-template, ue-cpp-build | toute valeur moteur citée est lue dans le moteur ; interdits L7c repris ; contrat des mods figé | C1 |
|
||
| **lp-impl** | A-IMPL-H : C++, portage, refactor, UMG, config | N3 `opus` `xhigh` (variante **lp-impl-max** N4 ; surcharge `sonnet` pour IMPL-L) | Bash, Read, Glob, Grep, Edit, Write | sk-protocol, ue-cpp-build, lp-build, lp-ue-compat | ne compile pas lui-même si la fiche confie le build à lp-builder **[D7]** ; aucun code sandbox dans le jeu ; note d'écarts à la SPEC obligatoire ; pas de retrait des compat UE4 | D1, D2, D3, D4, D8 |
|
||
| **lp-tooling** | commandlets, Python éditeur, PowerShell | N1 `sonnet` (surcharge `opus` pour D5 N2–N3) | Bash, Read, Glob, Grep, Edit, Write | sk-protocol, sk-windows-shell, ue-commandlet-pattern, lp-commandlets | `-DryRun` et contrôle intégré obligatoires ; pas d'écriture sans argument ; `-FullStdOutLogOutput` ; interpréteur explicite | D5, D6, D7 |
|
||
| **lp-content** | chaînes de contenu (coiffures, animations, mods d'assets) et cuisson DLC | N1 `sonnet` | Bash, Read, Glob, Grep, Write | sk-protocol, lp-build, lp-content-pipelines, lp-mods | atelier dans l'addon seulement ; `Mods/` vide avant commit/build ; licences CC BY ; `LPAnimTwist` après recuisson | D9, E4 (pilotage), E5 (pilotage) |
|
||
| **lp-validator** | A-VAL : VAL statique, smoke, diff, preuve par l'échec | N1 `sonnet` (surcharge `opus` pour un écart inexpliqué) | Bash, Read, Glob, Grep, Write | sk-protocol, sk-recount, debug-verification, lp-val-profiles | aucune modification de code ni de doc validée ; relire toutes les IMPL amont ; diff lu intégralement ; inventaire de toute modification d'une copie jetable | F1, F2, F4, F6 (N1 min.), A2 (contre-vérification déléguée), B7 (recompte) |
|
||
| **lp-measure** | mesure runtime A/B, profilage, préparation des tests utilisateur | N1 `sonnet` (surcharge `opus` pour G5 / écart) | Bash, Read, Glob, Grep, Write | sk-protocol, sk-comparability, lp-measure, lp-debug-build | jamais `UnrealEditor -game` ; check de comparabilité avant toute conclusion ; retour arrière **proposé**, jamais lancé ; question « existe-t-il déjà ? » | F3, F5 (préparation), G5 |
|
||
| **lp-debugger** | diagnostic : sémantique moteur, runtime, panne d'outillage, plantage | N3 `opus` `xhigh` (variante **lp-debugger-max** N4) | Bash, Read, Glob, Grep, Edit, Write | sk-protocol, debug-systematic, lp-build, lp-diag-options | ordre : préexistant ? → conditions → mesure → correctif ; 3 correctifs ratés → remise en cause de l'hypothèse ; aucun correctif sans cause mesurée | G1, G2, G3 (cause), G4 |
|
||
| **lp-integrator** | A-INT : commits par phase, pins, simulation de publication, opérations sur l'arbre | N1 `sonnet` (N2 orchestrateur pour H3/H5 arbitrage) | Bash, Read, Glob, Grep, Write | sk-protocol, git-phase-commits, lp-git, lp-publish | **jamais de push**, jamais de `filter-branch` sans sauvegarde `.git` et gel ; déplacer, pas supprimer ; identité vérifiée dans chaque dépôt ; `Mods/` vide ; règle de permission `Bash(git push*)` refusée **[D5]** | H1, H2, H3 (exécution), H4 (simulation), H5 (exécution) |
|
||
| **lp-writer** | A-DOC : journal, registre, docs numérotées, fiches, mémoire | N1 `sonnet` (surcharge `opus` pour une synthèse I2 N4) | Read, Glob, Grep, Edit, Write | sk-protocol, lp-doc, lp-lot | docs en français ; une entrée CHG par changement avec retour arrière ; pas de réécriture du passé ; VAL ≠ DOC | I1, I2, I3, A5 (mise en forme de l'EVAL) |
|
||
| **opus-xhigh** (existant) | escalade N3 générique | `opus` `xhigh` | (tous, inchangé) | + sk-protocol, sk-recount | inchangés ; la fiche `-fix` nomme le skill de rôle à invoquer | tout type en `-fix` depuis N1/N2 |
|
||
| **opus-max** (existant) | escalade N4 ; synthèses | `opus` `max` | (tous) | + sk-protocol, sk-recount, sk-estimate | inchangés | A4, A5 (synthèse), `-fix` depuis N3 |
|
||
| **fable-top** (existant) | N5 | `fable` | (tous) | + sk-protocol, sk-estimate | inchangés | A4 (porte), `-fix` depuis N4, enjeu maximal |
|
||
|
||
Compléments :
|
||
- **`maxTurns`** : lp-builder et lp-inventory ≤ 40 (tâches bornées) ; les autres sans limite **[D8]**.
|
||
- **`memory`** : non utilisé en V1 (une mémoire d'agent persistante risque de contredire la fiche) ; à reconsidérer pour
|
||
lp-debugger (`project`) après SK-T5 **[D9]**.
|
||
- **`permissionMode`** : laissé par défaut ; aucun `bypassPermissions` (R6).
|
||
- **`isolation: worktree`** : utile pour F6 (preuve par l'échec sur copie jetable) mais le projet UE (14 Go, `Content`
|
||
hors git) ne s'y prête pas : non retenu.
|
||
- **Descriptions déclenchantes** : à la troisième personne, mots-clés du type (ex. lp-builder : « Compile, lance une
|
||
commandlet ou une cuisson LifePlay et rapporte le journal ; à utiliser pour toute fiche BUILD/E1–E5 ; ne corrige rien »).
|
||
- **Corps** : chaque agent reprend le corps actuel des agents de niveau (« tu rapportes, l'orchestrateur décide… ») plus
|
||
ses interdits de rôle ; ≤ 25 lignes.
|
||
- Orchestrateur (N2, session principale) : pas d'agent ; invoque `/sk-orchestrate` au début de chaque lot (A1–A3, C2).
|
||
|
||
---
|
||
|
||
## 4. Table types → agent / skills / niveau / escalade
|
||
|
||
Niveau par défaut = celui de SK-T1 ; « Esc. » = chemin d'escalade (motif écrit dans la fiche `-fix`).
|
||
|
||
| Type | Agent (surcharge `model`) | Skills préchargés (+ à nommer dans la fiche) | Niveau | Esc. |
|
||
|---|---|---|---|---|
|
||
| A1 Fiches | orchestrateur | /sk-orchestrate (invoqué) | N2 | — |
|
||
| A2 Contre-vérification | orchestrateur ; délégation à lp-validator pour un recompte lourd | sk-recount (+lp-val-profiles) | N2 | lp-validator (`opus`) |
|
||
| A3 Suivi / coordination | orchestrateur ; lp-writer pour tenir les registres | sk-orchestrate, lp-lot | N2 (+N1) | — |
|
||
| A4 Synthèse / porte | opus-max ; fable-top si enjeu maximal | sk-protocol, sk-estimate | N4–N5 | fable-top |
|
||
| A5 Évaluation | opus-max (synthèse) + lp-writer (tableaux) | sk-estimate, lp-doc (+gabarit EVAL dans lp-lot) | N4 | fable-top |
|
||
| B1 Inventaire | lp-inventory | sk-recount, lp-paths | N0–N1 | lp-inventory (`sonnet`) → lp-cart |
|
||
| B2 Carto C++ | lp-cart (`sonnet` pour un module isolé) | ue-cpp-build, lp-paths | N1–N3 | lp-cart-max |
|
||
| B3 Carto Blueprint / assets | lp-cart (localiser : lp-inventory) | lp-commandlets (dump) | N1–N3 | lp-cart-max |
|
||
| B4 Audit sous-système | lp-cart | sk-protocol, lp-commandlets, (+lp-mods pour le contrat) | N1–N4 | lp-cart-max → fable-top |
|
||
| B5 Recherche externe / moteur | lp-research | sk-web-data, lp-env | N3–N4 | opus-max |
|
||
| B6 Catalogue / navigateur | lp-research (`opus`, effort xhigh hérité) | sk-web-data (règles navigateur) | N2 | — |
|
||
| B7 Conformité | lp-inventory (balayage) + lp-validator (recompte) ; arbitrage orchestrateur + utilisateur | lp-publish (catégories interdites, non-reproduction) | N1 + N2 | opus-xhigh |
|
||
| C1 SPEC | lp-spec | sk-spec-template, ue-cpp-build | N2–N4 | opus-max (+/lp-spec skills nommés) |
|
||
| C2 Plan de chantier | orchestrateur + utilisateur ; opus-max pour un plan lourd | sk-orchestrate (gabarit phases 0–5) | N2–N4 | opus-max |
|
||
| D1 C++ runtime | lp-impl (`sonnet` si IMPL-L bornée) | ue-cpp-build, lp-ue-compat (patron sous-système garde) | N2–N3 | lp-impl-max |
|
||
| D2 Refactor / extraction | lp-impl | ue-cpp-build, lp-build (règles jeu / addon dans lp-ue-compat) | N3 | lp-impl-max |
|
||
| D3 Portage d'API / compat | lp-impl | ue-cpp-build, lp-ue-compat (table API retirée → remplaçant, banc UE4/UE5) | N3 | lp-impl-max |
|
||
| D4 Slate / UMG | lp-impl | ue-cpp-build, lp-ue-compat (+ue-umg-slate nommé) | N2–N3 | lp-impl-max |
|
||
| D5 Commandlets éditeur | lp-tooling (`opus` pour un correctif Blueprint) | ue-commandlet-pattern, lp-commandlets | N2–N3 | lp-impl |
|
||
| D6 Python éditeur | lp-tooling | ue-commandlet-pattern (§ pythonscript), lp-commandlets | N1–N2 | lp-impl |
|
||
| D7 PowerShell | lp-tooling | sk-windows-shell, lp-build | N1 | lp-tooling (`opus`) |
|
||
| D8 Configuration | lp-impl (`sonnet`) | lp-ue-compat (verrous), ue-cook-package (diff `Base*.ini`) | N1–N2 | lp-impl |
|
||
| D9 Chaînes de contenu | lp-content | lp-content-pipelines, lp-mods | N1–N3 | lp-impl |
|
||
| E1 Compilation UBT | lp-builder | lp-build | N0 | lp-builder (`sonnet`) → lp-debugger (G3) |
|
||
| E2 Commandlets en lot | lp-builder | lp-build, lp-commandlets (nommé) | N0–N1 | lp-tooling |
|
||
| E3 Cuisson / empaquetage | lp-builder (`sonnet`) | lp-cook (check-list nouvelle partie + Continuer) | N0–N1 | lp-debugger |
|
||
| E4 Cuisson DLC des mods | lp-content (pilotage) + lp-builder (exécution) | lp-mods, lp-cook | N1 | lp-impl (garde C++) |
|
||
| E5 Réenregistrement de masse | lp-content (pilotage par lots) + lp-builder | lp-commandlets (LPResavePackages), lp-lot (sauvegarde) | N1 + N0 | lp-debugger (G4) |
|
||
| F1 VAL statique | lp-validator | debug-verification, lp-val-profiles | N0–N2 | lp-validator (`opus`) |
|
||
| F2 Smoke / non-régression | lp-validator | lp-val-profiles (exclusions, références) | N0–N1 | lp-measure |
|
||
| F3 Mesure A/B | lp-measure | sk-comparability, lp-measure | N1–N3 | lp-measure (`opus`) → lp-debugger |
|
||
| F4 Diff indépendant | lp-validator | lp-val-profiles (profils de diff) | N1 | lp-validator (`opus`) |
|
||
| F5 Validation visuelle / en jeu | lp-measure (préparation) + utilisateur | sk-comparability, lp-measure (consignes de test, captures) | N1 + utilisateur | — |
|
||
| F6 Preuve par l'échec | lp-validator (**jamais `haiku`**) | sk-protocol (§ anti-contournement), lp-build | N1 min. | lp-validator (`opus`) |
|
||
| G1 Sémantique moteur | lp-debugger | debug-systematic, lp-diag-options (+lp-ue-compat nommé) | N3–N4 | lp-debugger-max |
|
||
| G2 Défaut runtime | lp-debugger | debug-systematic, lp-diag-options | N2–N3 | lp-debugger-max |
|
||
| G3 Panne de build / outillage | lp-builder (constat) → lp-debugger (cause) | lp-build (catalogue symptôme → cause) | N1–N2 | lp-debugger |
|
||
| G4 Plantage | lp-debugger | debug-systematic, ue-crash-reading (nommé) | N3 | lp-debugger-max |
|
||
| G5 Performance / profilage | lp-measure (`opus`) | lp-debug-build (Cursor repris), lp-measure | N1–N3 | lp-debugger |
|
||
| H1 Commits par phase | lp-integrator | git-phase-commits, lp-git | N1 | orchestrateur |
|
||
| H2 Multi-dépôts / pin | lp-integrator | lp-git (ordre addon → pin → jeu, identités) | N1 | orchestrateur |
|
||
| H3 Réécriture d'historique | lp-integrator (exécution) ; arbitrage orchestrateur + utilisateur | lp-git (sauvegarde, gel), lp-publish | N1 + N2 | — |
|
||
| H4 Publication / simulation | lp-integrator (simulation) ; push = utilisateur | lp-publish | N1 | — |
|
||
| H5 Opérations destructives | lp-integrator (**N1–N2 min.**) ; orchestrateur pour l'arbitrage | sk-change-safety, lp-lot (instantané), lp-paths (fichiers à préserver) | N1–N2 | orchestrateur |
|
||
| I1 Journal CHG / ERR | lp-writer | lp-doc (gabarits de lignes) | N1 | — |
|
||
| I2 Docs numérotées | lp-writer (`opus` pour une synthèse) | lp-doc | N1 (N4) | opus-max |
|
||
| I3 Fiches / mémoire | lp-writer | lp-doc, lp-lot (gabarits CART/SPEC/IMPL/BUILD/VAL/INT/EVAL) | N1 | — |
|
||
| J1 Chaîne d'outils | lp-builder (relevé) → lp-research (analyse) | lp-env | N0–N3 | opus-max |
|
||
| J2 Chemin moteur multi-version | lp-inventory (inventaire) → lp-impl `sonnet` (point unique) | lp-env, lp-paths | N1 | lp-impl |
|
||
|
||
Contrôle (recompte, sk-recount appliqué) : l'arbre SK-T1 § 1 contient **49 types** (A5 + B7 + C2 + D9 + E5 + F6 + G5 +
|
||
H5 + I3 + J2), et non 45 comme l'annonce la fiche SK-T3 ; les 49 figurent ci-dessus, chacun avec un agent, des skills et
|
||
un niveau. Types sans agent dédié (orchestrateur) : A1, A2, A3, C2 ; A4 utilise les agents de niveau existants.
|
||
|
||
---
|
||
|
||
## 5. Catalogue des skills à produire
|
||
|
||
Colonnes : **Source** = écrire / adapter (`dépôt` à la révision épinglée relevée par SK-T2, licence) / reprendre (fichier
|
||
interne) ; **Taille** = lignes de `SKILL.md` (annexes à part) ; **Prio** = vague de rédaction (§ 8) ; **Types** servis.
|
||
Révisions à épingler (SK-T2 § 2, relevées le 2026-10-08) : quodsoler/unreal-engine-skills push 2026-09-28 (SHA à relever
|
||
au clonage, R2) ; obra/superpowers commit `8ca22dba9a94` ; nicoforclaude/claude-windows-shell push 2025-11-27 ;
|
||
anthropics/skills `683bc88e56f3` (template et `skill-creator`, déjà intégré).
|
||
|
||
### 5.1 Couche 1 — socle `sk-*` (emplacement `~/.claude/skills`)
|
||
|
||
| Skill | Source | Contenu attendu | Taille | Prio | Types |
|
||
|---|---|---|---|---|---|
|
||
| **sk-protocol** | écrire (X1, X3, X8, X10) | (1) preuve : établi / estimé / incertain, chaque affirmation `fichier:ligne` ou commande ; (2) interdits et arrêt : aucune correction d'initiative, aucun script réécrit, « l'échec EST le résultat », 0 résultat = échec probable, hors périmètre = arrêt ; (3) format du compte rendu (résultat, preuves, chiffres, incertitudes, ≤ 20 lignes) et ligne de handoff ; (4) en-tête de livrable « Fiche — Niveau — Modèle prévu \| utilisé » ; (5) anti-contournement pour une preuve par l'échec ; (6) « les décisions appartiennent à l'utilisateur » | ≤ 90 | **V1** | tous |
|
||
| **sk-recount** | écrire (X9, A2) | liste « ne pas croire sur parole » : recompter par une seconde formulation, détecter les ajouts non demandés, dates des fichiers produits, critère rejoué ; check à la réception d'un livrable | ≤ 60 | V1 | A2, B1, B7, F1, F4 |
|
||
| **sk-orchestrate** | reprendre (mémoire `feedback-subagents-by-task`, gabarit Cursor § Fiche, § Rôles, § Phases) | grille a–f avec exemples ; fiche à 9 rubriques + rubrique 2b « agent + skills » (§ 6) ; règles « destructif / inter-dépôts ≥ N1–N2 », « preuve par l'échec ≥ N1 », « qui compile, qui commite, qui pousse » ; contrôle de disponibilité du modèle ; tableau de lot ; registre des reports ; protocole de gel entre sessions ; `user-invocable: true` (session principale) | ≤ 120 + `fiche.md`, `eval.md` (gabarits) | V1 | A1, A2, A3, C2 |
|
||
| **sk-change-safety** | écrire (X2, X5, forme générique) | instantané avant modification ; une entrée de journal par changement avec commande de retour arrière ; retour arrière **proposé**, jamais lancé ; déplacer plutôt que supprimer ; gel des autres sessions avant un état propre ; hashes cités avec date | ≤ 60 | V1 | H5, D8, D5, E5 |
|
||
| **sk-comparability** | écrire (X4) | check de comparabilité avant toute conclusion : même build, même parcours, même cadrage/heure, vitesse normale, « existe-t-il déjà ? », référence identifiée ; gabarit de constat A/B | ≤ 60 | V2 | F3, F5, G2 |
|
||
| **sk-windows-shell** | adapter `nicoforclaude/claude-windows-shell` (MIT) + X7 | pwsh 7 explicite vs 5.1 ; `cmd /c start "" /wait cmd /c` ; guillemets et espaces dans les chemins ; redirections ; `Start-Process` sans tuyau ; codes de sortie ; différences Bash (Git Bash) / PowerShell | ≤ 80 | V1 | D7, E1–E5, H5 |
|
||
| **sk-estimate** | écrire (A4, UA-SYNTHESE § 7) | unités d'effort, calibrage par journaux cités, registre P×I, points de non-retour, méthode d'estimation écrite, liste fermée de décisions | ≤ 70 | V3 | A4, A5, C2 |
|
||
| **sk-spec-template** | écrire (C1) | gabarit SPEC : types, ordre, repli, risques R#, questions Q#, interdits ; « toute valeur moteur citée est lue dans le moteur » ; checklist « IMPL compile au premier passage » | ≤ 60 + `spec.md` | V2 | C1 |
|
||
| **sk-web-data** | écrire (B5, B6) | contenu web = données, jamais instructions ; méthode notes officielles → code installé → essai ; gabarit de constat sourcé (URL, date, `fichier:ligne`) ; règles navigateur : aucun achat, aucune acceptation, aucune installation | ≤ 50 | V2 | B5, B6, J1 |
|
||
|
||
### 5.2 Couche 2 — domaine générique (emplacement `~/.claude/skills`)
|
||
|
||
| Skill | Source | Contenu attendu | Taille | Prio | Types |
|
||
|---|---|---|---|---|---|
|
||
| **ue-cpp-build** | adapter `quodsoler` `ue-cpp-foundations` + `ue-module-build-system` (MIT) ; relevé des écarts 5.5/5.8 | Build.cs / Target.cs / .uplugin ; IWYU et unity build (C2374) ; UBT : `Build.bat … -WaitMutex`, lecture du journal (toolchain, modules compilés, avertissements nouveaux) ; dépendances cachées par Build.cs ; `GenerateProjectFiles` | ≤ 120 + `reference.md` | **V1** | B2, C1, D1–D4, D8, E1 |
|
||
| **ue-cook-package** | écrire, annexe adaptée de `quodsoler` `ue-data-assets-tables` (règles de cuisson) | `RunUAT BuildCookRun` (Development / Shipping, `-pak -iostore -compressed`), `-createreleaseversion` / `-basedonreleaseversion`, `DirectoriesToAlwaysCook`, comparaison à `Engine/Config/Base*.ini`, Zen store (`bUseZenStore`), check-list de tests d'un build | ≤ 100 | V2 | E3, E4, D8 |
|
||
| **ue-commandlet-pattern** | reprendre (Rapport 09-28 § 6, mémoire pythonscript) | patron `-DryRun` / rapport / correction ; contrôle intégré ; journal horodaté ; défauts sûrs ; `-run=pythonscript -FullStdOutLogOutput`, `scan_paths_synchronous`, `only_if_is_dirty=False` ; NodeGuid régénérés | ≤ 90 | V2 | D5, D6, E2 |
|
||
| **ue-umg-slate** | adapter `quodsoler` `ue-ui-umg-slate` (MIT) | styles `FCoreStyle` / `FUMGCoreStyle`, injection de widgets, défauts UE4 → UE5 non sérialisés, captures avant / après ; invoqué à la demande (non préchargé) | ≤ 100 | V3 | D4 |
|
||
| **ue-crash-reading** | écrire (G4) | lecture d'un `Saved/Crashes` : pile, `LogStreaming`, `AsyncLoading2`, `BulkData` ; plantages bénins connus ; reproduction minimale ; invoqué à la demande | ≤ 60 | V3 | G4 |
|
||
| **git-phase-commits** | écrire (s'inspirer de obra `finishing-a-development-branch`, sans l'adopter) | un commit par phase en fin de lot ; message = titre de lot + CHG ; contrôle d'arbre par SHA avant / après ; identité vérifiée (`git config user.email`) ; **jamais de push** ; sauvegarde `.git` → filtre → `rev-list --objects` → simulation ; multi-dépôts : commit dépendance → pin → dépôt principal | ≤ 90 | V2 | H1–H4 |
|
||
| **debug-systematic** | adapter `obra/superpowers` `systematic-debugging` (MIT, **copié seul**, sans hook ni `using-superpowers`) | 4 phases, cause racine d'abord, « 3 correctifs ratés → remettre l'hypothèse en question », une hypothèse à la fois, preuve avant correctif ; ajout : ordre « préexistant ? → conditions → mesure → correctif » | ≤ 120 | V2 | G1–G4 |
|
||
| **debug-verification** | adapter `obra/superpowers` `verification-before-completion` (MIT, copié seul) | aucune clôture sans preuve rejouée ; verdicts `PASS` / `PASS-STATIC` / `FAIL` / `BLOCKED-*` ; relire toutes les IMPL amont ; points à confirmer → cases de VAL | ≤ 70 | V1 | F1, F2, F6 |
|
||
|
||
### 5.3 Couche 3 — projet `lp-*` (emplacement : dépôt addon privé, jonction vers `.claude/skills`)
|
||
|
||
| Skill | Source | Contenu attendu | Taille | Prio | Types |
|
||
|---|---|---|---|---|---|
|
||
| **lp-build** | reprendre mémoire `lifeplay-build-pitfalls` **telle quelle** + E1/G3 de SK-T1 | éditeur fermé, une compilation à la fois ; `Makefile.bin` après test sans addon (déplacer) ; DLL périmées de l'addon (dates, déplacer) ; preuve de chargement (ligne de journal) ; `BuildMod` via `cmd /c start` ; commandes exactes 5.5 et 5.8 (`Tools/Engine.ps1` après U2) ; catalogue symptôme → cause ; compte rendu : code, modules recompilés, avertissements nouveaux | ≤ 120 + `symptoms.md` | **V1** | E1, E2, G3, D7, F6 |
|
||
| **lp-cook** | écrire (E3, mémoire `packaging-test-paths`, ERR-026, CHG-110, O2) | script exact (liberté basse) : `BuildDebug.ps1` / `RunUAT` ; dossier neuf ; `Mods/` vide ; `DirectoriesToAlwaysCook` ; `NO_LOGGING` ; check-list : nouvelle partie (liste des villes) + Continuer + mods + sauvegarde ; nombre de paquets attendu ; référence `Releases/<version>` | ≤ 100 | V2 | E3, E4 |
|
||
| **lp-mods** | reprendre UA-MODS (contrat), doc 20, SB/DC | contrat figé (surfaces, `.lpmod`, `GI.ModEnableds`, avertissement de version) ; `BuildMod.ps1 -dlcname -basedonreleaseversion` ; comparaison SHA-256 (DC3-VAL) ; tests T1–T7 ; risque R1 (mod 5.5 dans 5.8) ; aucun contenu de mod reproduit | ≤ 100 | V3 | E4, D9, B4, U7 |
|
||
| **lp-commandlets** | écrire (B3, D5, E2 ; doc 09) | catalogue des commandlets `LP*` (dump, fix, resave, check, test) et options ; journal `etat/<Lot>_<Cmd>_<horodatage>.txt` ; `RunCommandlet.ps1` ; identifier les nœuds par nom de fonction ; `LPAnimCatalog` sans argument réécrit ; liste des commandlets retirées en U2 (D3) | ≤ 100 + `catalogue.md` | V1 | B3, D5, D6, E2, E5 |
|
||
| **lp-measure** | reprendre mémoire `runtime-measurement`, doc 03 § 3.5, 10 § 3.3–3.4, `compare-before-rollback` | protocole A/B `LogStats.ps1 -Compare` ; build Development empaqueté seulement ; `index SPAWN > 0` ; même parcours ; consignes de test utilisateur (lieu, durée, actions, captures même cadrage) ; référence 5.8 = `LifePlay_Build_5.5_DC4` (D5) ; retour arrière proposé | ≤ 100 | V2 | F3, F5, G2, G5 |
|
||
| **lp-debug-build** | reprendre `.cursor/skills/lifeplay-debug-build/` (SKILL.md + reference.md) tel quel | dual-build, sessions A/B/C, `CollectDebugArtifacts.ps1`, pièges (`-csvCaptureFrames`), conventions C++ non-Shipping | 105 (existant) | V2 | G5 |
|
||
| **lp-diag-options** | écrire (doc 09 § 4, G2) | options `-LPDump*`, `-LPTrace*`, `-LPDumpEvery`, `LPDumpFunction -Exec`, commandes console `LifePlay.*` ; ordre de diagnostic ; vitesse du jeu | ≤ 70 | V2 | G1, G2 |
|
||
| **lp-git** | écrire (H1–H5, mémoire `github-publication`, `sandbox-not-committed`) | trois dépôts (jeu public, addon privé, `Content/Modules/.git` local) ; identité noreply dans chacun ; ordre addon → pin → jeu ; `Mods/` vide ; fichiers à écarter (`LPSandboxMeasure*.cpp` à la racine) ; gel ; hashes datés | ≤ 90 | V2 | H1, H2, H3, H5 |
|
||
| **lp-publish** | écrire (PUB1/PUB2, doc 10 § 6, B7) | catégories interdites, balayage historique complet (`rev-list --objects`, chaînes des `.uasset`), règle de non-reproduction, `.claude/` et `McpAutomationBridge` ignorés, `gh auth status`, `ls-remote`, tags v1.0–v1.5, verdict par catégorie, « rien n'est poussé sans accord » | ≤ 90 | V3 | B7, H3, H4 |
|
||
| **lp-doc** | écrire (I1–I3, CHG-246) | gabarits de lignes CHG / ERR (statuts), numérotation et index `Docs/Migration`, bandeau « historique 4.27 », docs en français, en-tête de fiche obligatoire, gabarits CART/SPEC/IMPL/BUILD/VAL/INT/EVAL (annexe) | ≤ 90 + `gabarits.md` | V1 | I1, I2, I3, A5 |
|
||
| **lp-lot** | écrire (doc 10 § 1–2, A3) | `Snapshot.ps1 -Lot` / `Restore.ps1` (proposé) ; arborescence `etat/<projet>/<lot>/` ; registre des reports ; fichiers à préserver (`.mcp.json`, 10 § 1.7) ; copie de travail 5.8 ; `FAIL-TRACE` si modèle non tracé | ≤ 80 | V1 | A3, H5, E5, I3 |
|
||
| **lp-paths** | écrire (B1, J2) | chemins des dépôts et dossiers (jeu, addon, builds de référence, moteurs 5.5/5.8, journaux `etat/`) ; requêtes types d'inventaire par dépôt (suivi / ignoré / non suivi) ; espace dans `LifePlay-master 5.5` | ≤ 60 | V1 | B1, B2, J2, H5 |
|
||
| **lp-env** | écrire (J1, UA-OUTILS, UA-SYNTHESE R8–R9) | exigences 5.8 ; coexistence VS 2022 / 2026, `ToolchainVersion` par projet (14.38 / 14.50), MSVC banni ; Zen commun ; `Tools/Engine.ps1` ; relevés avant premier lancement 5.8 | ≤ 70 | **V1** (U0) | J1, J2, B5 |
|
||
| **lp-ue-compat** | écrire (D1, D3, U9 ; docs 10 § 3.6, UA-SYNTHESE § 2 U3) | compat UE4 gardée (P2) : `LPStringCompat`, `LPMeshCompat`, `LPNavigationHelpers` ; table API 5.5 → 5.8 (`:127`, `:198`, C4996) ; patron sous-système garde (`GameInstanceSubsystem` + `FTSTicker`, `ScanPathsSynchronous` sous `WITH_EDITOR`) ; règles jeu / addon ; verrous de config L7c ; `LPTestStringCompat` à rejouer | ≤ 110 + `api-table.md` | V1 (U3) | D1–D4, D8, G1 |
|
||
| **lp-content-pipelines** | reprendre docs 13 § 4 et 20, mémoire `pose-transfer` | `HairPipeline.ps1`, `AnimPipeline.ps1`, `RetargetPack.py`, ordre recuisson → `LPAnimTwist` → `LPAnimEval`, licences CC BY, atelier dans l'addon ; aucun nom d'asset de jeu | ≤ 80 | V3 | D9, E4 |
|
||
| **lp-val-profiles** | écrire (F1, F2, F4) | verdicts nuancés ; liste d'exclusions de diff (dates, 20 images, NodeGuid, positions, `EdGraph_N`) ; références (SB2-REF, `streetmap_5.5.csv`, relevé `CompileAllBlueprints` 5.5) ; smoke `-nullrhi` ; SHA-256 | ≤ 80 | V2 | F1, F2, F4, F6 |
|
||
|
||
Total : 9 + 8 + 16 = **33 skills** (dont 1 existant repris tel quel) ; 21 à écrire, 6 adaptés, 6 repris de contenus
|
||
internes. Note : le résumé § 1 arrondit à « 28 » hors les 5 skills de V3 facultatifs (`ue-umg-slate`, `ue-crash-reading`,
|
||
`sk-estimate`, `lp-mods` détaillé, `lp-content-pipelines`) qui peuvent attendre U7.
|
||
|
||
Règles de contenu communes : description à la troisième personne avec mots-clés déclencheurs ; corps ≤ 120 lignes ;
|
||
annexes à un seul niveau avec table des matières au-delà de 100 lignes ; chemins avec `/` ; pas d'information datée
|
||
dans le corps (dates dans un `CHANGELOG` du skill) ; avis de licence conservé dans le dossier d'un skill adapté (R4) ;
|
||
aucun script embarqué en V1 (le cas échéant, `allowed-tools: Bash(${CLAUDE_SKILL_DIR}/scripts/x *)` seulement, R6).
|
||
|
||
---
|
||
|
||
## 6. Méthode mise à jour
|
||
|
||
### 6.1 Fiche de tâche : rubrique 2b « Agent + skills »
|
||
|
||
```
|
||
2. Complexité : a b c d e f = total → Nx (motif)
|
||
2b. Agent : <lp-xxx | opus-xhigh | …> (model surchargé : <…> | aucun) — skills préchargés : <liste du frontmatter>
|
||
— skills à invoquer : <liste nommée dans la fiche, si non préchargés> — outils retirés : <…>
|
||
```
|
||
|
||
En-tête de livrable : `Fiche <P#-Tn> — Niveau <Nx> — Modèle prévu <…> | utilisé <…> — Agent <…> — Skills <…>`.
|
||
Le sous-agent recopie la liste des skills effectivement présents dans son contexte (preuve du préchargement : le
|
||
marqueur de `sk-protocol`, § 7). Sans cette ligne : `FAIL-TRACE` à l'EVAL (règle existante étendue).
|
||
|
||
### 6.2 Choix par l'orchestrateur (algorithme)
|
||
|
||
1. Classer la tâche dans un type SK-T1 (A1…J2) → ligne de la table § 4 → agent et niveau par défaut.
|
||
2. Noter a–f ; si le niveau calculé < défaut de l'agent → surcharge `model` vers le bas (`haiku`/`sonnet`) **seulement si**
|
||
la tâche ne suit aucun mécanisme (limites N0) ; si > défaut → agent d'escalade ou variante `-max`, avec le skill de
|
||
rôle nommé dans la fiche.
|
||
3. Vérifier que les outils de l'agent suffisent (ex. lp-validator n'a pas `Edit` : une VAL qui doit corriger est une
|
||
fiche IMPL) et que le budget de skills préchargés est ≤ 4 (sinon nommer les autres).
|
||
4. Contrôler la disponibilité du modèle (Fable bloqué en VQ, 26 § 4) : niveau indisponible → niveau supérieur.
|
||
5. Recopier dans la fiche uniquement ce que les skills **ne** contiennent **pas** (état de départ, commandes du lot) :
|
||
la rubrique 5 « pièges » renvoie au skill et n'ajoute que les pièges nouveaux, qui remontent ensuite dans le skill.
|
||
|
||
### 6.3 Indicateurs de gain (relevés dans l'EVAL de chaque lot, puis dans l'EVAL de la migration)
|
||
|
||
| Indicateur | Définition | Base de référence (établi, SK-T1) | Cible V2.0 |
|
||
|---|---|---|---|
|
||
| Taux de `-fix` | fiches reprises / fiches lancées | 22 : plusieurs reprises sur 28 fiches ; DC4 : T1 reprise ; SB : T0 | ≤ 10 % |
|
||
| Escalades | fiches reprises à un niveau supérieur pour cause de capacité | 1 sur UA (T3 → fable) | tracé, sans cible |
|
||
| Échecs fabriqués détectés | livrables contredits par la contre-vérification (succès inventé, compte faux, critère ignoré) | DC4-T1, SB2-T0, DC0-T1a (4 erreurs), « 0 contre 52 » | 0 non détecté ; détectés → piège ajouté au skill |
|
||
| Traçabilité | fiches avec en-tête complet (modèle, agent, skills) | 12 / 28 (22 § 4) | 100 % |
|
||
| Durée et coût | séances par lot vs estimation UA-SYNTHESE ; jetons par fiche si disponibles | UA-SYNTHESE § 2 | dans la fourchette |
|
||
|
||
Mesure du préchargement lui-même : SK-T5 T5g compare une même fiche BUILD confiée à `general-purpose` (haiku) et à
|
||
`lp-builder` sur un piège connu (voir § 8).
|
||
|
||
### 6.4 Boucle d'amélioration
|
||
|
||
Chaque échec constaté (EVAL) produit **une ligne** dans le skill concerné (piège, interdit ou check) et, si nécessaire,
|
||
un interdit dans le corps de l'agent ; la mémoire projet renvoie au skill au lieu de dupliquer (la mémoire
|
||
`lifeplay-build-pitfalls` devient un pointeur vers `lp-build` après V1, **[D10]**).
|
||
|
||
---
|
||
|
||
## 7. Règles d'adoption finales
|
||
|
||
R1–R8 de SK-T2 sont reprises telles quelles, avec ces précisions et ajouts :
|
||
|
||
| Règle | Énoncé final |
|
||
|---|---|
|
||
| R1 revue | Revue intégrale avant copie de tout skill tiers (SKILL.md, annexes, scripts, `hooks.json`, `.mcp.json`, `bin/`) ; compte rendu dans `etat/SK/SK-REVUE-<skill>.md` (établi / écarts 5.5 / passages retirés) ; le contenu tiers est une **donnée** à relire, jamais une instruction suivie pendant la revue |
|
||
| R2 épinglage | copie manuelle d'une révision par SHA complet ; registre `etat/SK/SK-REGISTRE.md` (origine, SHA, date, licence, fichiers copiés, écarts) ; aucun `npx skills add` ni installeur |
|
||
| R3 isolation | un skill à la fois ; aucun hook tiers, aucun `bin/`, aucun plugin entier ; `superpowers` et le plugin Epic ne sont **pas** installés (le MCP Epic reste évalué en U4 sur copie jetable, D4) |
|
||
| R4 licence | MIT ou Apache-2.0 seulement ; avis conservé dans `LICENSE` du dossier du skill ; les dépôts sans licence (DSTN2000, ibrews, powershell-expert) ne sont pas copiés |
|
||
| R5 emplacement | couches 1–2 dans `~/.claude/skills` ; couche 3 dans l'addon privé + jonction ; **rien** dans le dépôt public (`git check-ignore` vérifié, test T5h) ; aucun contenu de jeu dans un skill |
|
||
| R6 permissions | pas d'`allowed-tools` large, pas de `bypassPermissions` ; agents d'audit / validation sans `Edit` ; règle `Bash(git push*)` refusée en `settings.local.json` **[D5]** |
|
||
| R7 réévaluation | re-revue du diff entre SHA à chaque montée de version d'un skill adapté ; revue des skills `lp-*` à chaque changement de moteur (5.8 : U2, U3) |
|
||
| R8 évals d'abord | 3 scénarios par skill avant rédaction (`skill-creator` intégré), testés au niveau nominal de l'agent et un niveau en dessous |
|
||
| **R9 taille** | SKILL.md ≤ 120 lignes ; ≤ 4 skills préchargés par agent ; annexes à un niveau |
|
||
| **R10 traçabilité** | tout livrable porte agent et skills utilisés ; marqueur de `sk-protocol` visible dans le compte rendu |
|
||
| **R11 propriété** | la couche 1–2 est maintenue par l'utilisateur (méthode) ; la couche 3 par le lot en cours (une ligne par piège nouveau) ; aucune modification de skill par un sous-agent pendant une fiche |
|
||
| **R12 langue** | skills et agents en **français** (langue des fiches et des docs) ; descriptions avec les mots-clés anglais usuels (build, cook, commit) pour le déclenchement **[D11]** |
|
||
| **R13 rédaction** | une ligne de skill n'entre que si l'agent ne peut ni la savoir ni l'apprendre par un outil ; ce qui se déduit du nom, de la signature ou du contexte se coupe ; description terminée par « Pas pour : … » vers le skill voisin ; relecture de la seule description avant remise (lot UES1, 2026-10-15, d'après le plugin Epic 3.1.1, MIT) |
|
||
|
||
---
|
||
|
||
## 8. Plan SK-T4 (rédaction) et SK-T5 (tests), effort
|
||
|
||
### 8.1 SK-T5 — tests (avant V1, sur un skill témoin ; 0,5 séance, N1 + orchestrateur)
|
||
|
||
| Test | Objet | Méthode | Résultat attendu | Tranche |
|
||
|---|---|---|---|---|
|
||
| **T5a** | `skills:` appliqué par l'**application de bureau** (incertain, SK-T2 § 5) | skill `~/.claude/skills/sk-probe/SKILL.md` imposant la phrase « SK-PROBE-OK » ; agent `~/.claude/agents/sk-probe-agent.md` (`model: haiku`, `skills: [sk-probe]`) ; lancer avec une consigne neutre (« dis bonjour ») depuis l'application de bureau, puis depuis la CLI | marqueur présent dans les deux cas | le mécanisme entier |
|
||
| T5b | `tools` restreint | agent sans `Edit`/`Write` chargé d'éditer un fichier de brouillon | refus ou impossibilité rapportée | agents d'audit |
|
||
| T5c | préchargement depuis la **jonction** `.claude/skills` → addon, et depuis `--add-dir` | `sk-probe-lp` placé dans l'addon, jonction créée ; même test que T5a ; variante sans jonction avec `--add-dir` | marqueur présent (jonction) ; `--add-dir` : à constater | emplacement couche 3 (**[D1]**) |
|
||
| T5d | surcharge `model` de l'outil Agent sur un agent de rôle : `effort` du frontmatter conservé ? | agent `opus`+`xhigh` lancé avec `model: sonnet` ; demander à l'agent de rapporter modèle et effort perçus (indicatif) ; comparer la durée | comportement noté ; si l'effort est ignoré, documenter | règle de descente § 6.2 |
|
||
| T5e | skill de plugin dans `skills:` (`plugin:skill`) | `skills: [anthropic-skills:skill-creator]` sur l'agent témoin | chargé ou avertissement | catalogue (utiliser les intégrés ou copier) |
|
||
| T5f | coût en contexte | agent avec 4 skills de 120 lignes ; relever l'usage de jetons au premier tour (`/cost` ou rapport) | ≤ 6 000 jetons | R9 |
|
||
| T5g | **gain réel** | même fiche E1 (compilation avec un `Makefile.bin` périmé préparé exprès, ou une DLL addon antidatée) confiée à `general-purpose` (haiku) puis à `lp-builder` | `lp-builder` signale le piège ; l'autre rend « code 0 » | justification du lot |
|
||
| T5h | rien dans le dépôt public | `git -C "D:/Game/LifePlay-master 5.5" check-ignore -v .claude/skills/sk-probe-lp/SKILL.md` ; `git status --porcelain` vide | ignoré | R5 |
|
||
|
||
Si T5a échoue dans l'application de bureau mais réussit en CLI : repli = option B (skills nommés dans la fiche +
|
||
invocation obligatoire au premier tour, vérifiée par le marqueur), et signalement de l'écart.
|
||
|
||
### 8.2 SK-T4 — rédaction en vagues (calées sur U0–U8 et sur les priorités SK-T1 § 4)
|
||
|
||
| Vague | Avant le lot | Skills | Agents | Priorités SK-T1 couvertes | Effort (séances) | Niveaux |
|
||
|---|---|---|---|---|---|---|
|
||
| **V1** | U0 | sk-protocol, sk-recount, sk-orchestrate, sk-change-safety, sk-windows-shell, debug-verification, ue-cpp-build (adapté), lp-build, lp-commandlets, lp-doc, lp-lot, lp-paths, lp-env, lp-ue-compat | lp-builder, lp-inventory, lp-validator, lp-impl (+-max), lp-writer, lp-cart ; socle ajouté aux 3 agents existants | 2 (A2/A3), 3 (E1/G3), 5 (F6), 10 (B1), U3 (D3) | 1,5 – 2 | N1 rédige les skills repris / écrits à partir des lignes SK-T1 (une fiche par groupe de 3–4 skills) ; N3 pour `ue-cpp-build` (revue R1 + écarts 5.5/5.8) et `lp-ue-compat` ; orchestrateur relit chaque skill contre R9–R12 |
|
||
| **V2** | U4 | sk-comparability, sk-spec-template, sk-web-data, ue-cook-package, ue-commandlet-pattern, git-phase-commits, debug-systematic (adapté), lp-cook, lp-measure, lp-debug-build (repris), lp-diag-options, lp-git, lp-val-profiles | lp-spec, lp-research, lp-tooling, lp-measure, lp-debugger (+-max), lp-integrator | 1 (F5/F3/G2), 4 (E3), 6 (B5/B4), 7 (D5/F4), 9 (H1–H4) | 1 – 1,5 | N1 + N3 (`debug-systematic` revue R1) |
|
||
| **V3** | U7 | sk-estimate, ue-umg-slate (adapté), ue-crash-reading, lp-mods, lp-publish, lp-content-pipelines | lp-content | 8 (D4), U7–U8 (E4, H4, B7) | 0,5 – 1 | N1 ; N3 pour `ue-umg-slate` (revue) |
|
||
| **V4** | U8 (EVAL) | révision de tous les skills avec les pièges de U0–U7 ; évals `skill-creator` ; mise à jour de la mémoire (pointeurs) | ajustement des niveaux par défaut d'après l'EVAL | — | 0,5 | N1 + orchestrateur |
|
||
|
||
Chaque vague : fiche SK-T4-Vn (N1) → relecture orchestrateur (R9–R12, aucun contenu de jeu, licence) → test T5a-like
|
||
sur un agent de la vague → commit **addon** (couche 3) et commit du dépôt `claude-method` (couches 1–2, **[D2]**) ;
|
||
aucun commit dans le dépôt du jeu (rien n'y change : `.claude/` ignoré) hormis `etat/SK/*` (docs du lot, publiables :
|
||
elles ne contiennent aucun contenu de jeu).
|
||
|
||
**Effort total SK-T4 + SK-T5 : 3,5 – 5 séances** (estimé : 33 skills × 0,05–0,1 séance de rédaction N1 + 6 revues R1
|
||
à 0,15 + 15 agents × 0,02 + tests 0,5 + relectures orchestrateur ≈ 25 % ; méthode UA-SYNTHESE § 7). V1 seule
|
||
(prérequis de U0) : 1,5–2 séances. Alternative plus courte **[D12]** : V1 réduite à sk-protocol, sk-orchestrate,
|
||
lp-build, lp-lot, lp-env + lp-builder/lp-validator/lp-impl (≈ 0,75 séance), le reste glissant en V2.
|
||
|
||
---
|
||
|
||
## 9. Décisions à soumettre à l'utilisateur (liste fermée)
|
||
|
||
| # | Décision | Options | Recommandation | Conséquence |
|
||
|---|---|---|---|---|
|
||
| D1 | Emplacement et exposition de la couche 3 (`lp-*`) | (a) addon + jonction `.claude/skills` ; (b) addon + `--add-dir` ; (c) copie dans `~/.claude/skills` | **(a)**, (b) en secours selon T5c | (a) un chemin canonique, rien dans le public ; (c) synchronisation manuelle, skills LifePlay visibles dans tous les projets |
|
||
| D2 | Versionnage des couches 1–2 | (a) dépôt git privé `claude-method` couvrant `~/.claude/skills` + `~/.claude/agents` ; (b) dossier `Tools/claude/` de l'addon, copié vers `~/.claude` ; (c) non versionné | **(a)** | (a) réutilisable pour d'autres projets, historique ; (b) lie la méthode à LifePlay |
|
||
| D3 | Option d'agents | B (niveaux seuls), **C** (rôles + escalade), A, D | **C** avec 2 variantes `-max` (impl, debugger) et 1 (cart) | 15 fichiers ; voir § 3.1 |
|
||
| D4 | Emplacement des agents `lp-*` | (a) `~/.claude/agents` (tous) ; (b) `.claude/agents` du jeu par jonction (projet) | **(a)** en V1 (simple ; avertissement bénin si un skill `lp-*` manque dans un autre projet) | (b) séparation propre, mais deux emplacements |
|
||
| D5 | Règles de permission d'appui | (a) `settings.local.json` du jeu : refuser `Bash(git push*)`, `Bash(git filter-branch*)`, `Bash(Remove-Item*)` ; (b) interdits de fiche seulement | **(a)** | (a) la règle vaut aussi pour l'orchestrateur ; à exclure du public (`settings.local.json` déjà ignoré, `.gitignore:37`) |
|
||
| D6 | Niveau par défaut de `lp-inventory` | (a) `haiku` ; (b) `sonnet` | **(b)** (4 erreurs DC0-T1a, décomptes faux) ; `haiku` par surcharge pour un `git ls-files` simple | coût légèrement supérieur, moins de `-fix` |
|
||
| D7 | `lp-impl` compile-t-il lui-même ? | (a) non : build par `lp-builder` (propriétaire unique, journal archivé) ; (b) oui pour la boucle erreurs → correctif de U3 (N3 compile, 4–8 cycles) | **(b) pour U3 seulement** (boucle courte, 8–12 min par build), (a) ailleurs | (b) exige `lp-build` préchargé dans lp-impl (prévu) |
|
||
| D8 | `maxTurns` | (a) 40 pour builder/inventory ; (b) aucune limite | **(a)** | évite une boucle de N0 sur un échec |
|
||
| D9 | `memory` d'agent | (a) aucune en V1 ; (b) `project` pour lp-debugger | **(a)** | (b) risque de consignes périmées hors fiche |
|
||
| D10 | Mémoire projet après V1 | (a) `lifeplay-build-pitfalls` devient un pointeur vers `lp-build` ; (b) duplication maintenue | **(a)** | une seule source ; la mémoire reste le point d'entrée |
|
||
| D11 | Langue des skills | (a) français ; (b) anglais ; (c) français + mots-clés anglais dans la description | **(c)** | déclenchement et lisibilité |
|
||
| D12 | Périmètre de V1 | (a) V1 complète (14 skills, 1,5–2 séances) ; (b) V1 réduite (5 skills, 0,75 séance) | **(a)** si U0 peut attendre une semaine ; sinon (b) | (b) : `lp-ue-compat` et `ue-cpp-build` arrivent avant U3 au plus tard |
|
||
| D13 | Adoption des skills tiers dès V1 | (a) `ue-cpp-build` (quodsoler) adapté en V1 après revue R1 ; (b) tout écrire soi-même en V1, adapter en V2 | **(a)** | (a) 0,15 séance de revue ; (b) contenu UE moins complet mais 0 dépendance |
|
||
|
||
---
|
||
|
||
## 10. Établi / estimé / incertain
|
||
|
||
**Établi (source citée)**
|
||
- Champs de frontmatter d'un agent personnalisé (page officielle sub-agents, relue le 2026-10-08) : `name`,
|
||
`description`, `tools` (omis = tous les outils de sous-agent), `disallowedTools`, `model` (`sonnet`/`opus`/`haiku`/
|
||
`fable`/ID/`inherit`), `effort` (`low`…`max`, selon le modèle), `skills` (« full skill content is injected »,
|
||
« Subagents can still invoke unlisted … skills through the Skill tool »), `permissionMode`, `maxTurns`, `memory`
|
||
(`user`/`project`/`local`), `mcpServers`, `hooks`, `background`, `isolation`, `color`, `omitClaudeMd`.
|
||
- « Built-in agents don't preload skills » ; ordre de résolution du modèle : paramètre `model` de l'appel > frontmatter >
|
||
`CLAUDE_CODE_SUBAGENT_MODEL` > modèle de la session ; **aucun paramètre `effort` à l'appel** n'est documenté.
|
||
- Emplacements et priorité des agents : managed > `--agents` > `.claude/agents` (projet) > `~/.claude/agents` > plugin.
|
||
- `.gitignore` du jeu : `/.claude/` (l. 72) et `.claude/settings.local.json` (l. 37) ignorés ; `~/.claude/skills`
|
||
inexistant ; `~/.claude/agents` contient les 3 agents de niveau sans `tools` ni `skills` ; aucun plugin installé
|
||
(`installed_plugins.json` vide) ; `.cursor/skills/lifeplay-debug-build` = SKILL.md (105 l.) + reference.md.
|
||
- Addon : dépôt privé séparé, `.gitignore` ignore `.cursor/` mais pas `.claude/` ni `Tools/` (hors `Tools/debug/out/`).
|
||
- Les 45 types, échecs et priorités (SK-T1) ; le catalogue, licences et révisions (SK-T2) ; aucune contradiction entre
|
||
SK-T1/SK-T2 et la doc officielle n'a été relevée (SK-T2 § 1.4 est conforme à la page relue).
|
||
|
||
**Estimé (méthode)**
|
||
- Nombre de skills (33) et tailles (≤ 120 lignes) : dérivés des colonnes « Skill » de SK-T1 regroupées par couche.
|
||
- Coût en contexte (≈ 1 500 jetons par skill de 120 lignes, ≤ 6 000 par agent ; 2 800 jetons de métadonnées) : ratio
|
||
≈ 12 jetons par ligne de Markdown français.
|
||
- Effort SK-T4/T5 : 3,5–5 séances (§ 8.2, barème UA-SYNTHESE § 7).
|
||
- Gains attendus (§ 6.3) : cibles posées, non mesurées.
|
||
|
||
**Incertain (test qui tranche)**
|
||
- Application de `skills:` par l'application de bureau → **T5a** (la doc décrit la CLI ; même moteur présumé).
|
||
- Préchargement d'un skill situé sous une jonction `.claude/skills` ou sous un dossier `--add-dir` → **T5c**.
|
||
- Conservation de l'`effort` du frontmatter quand l'outil Agent surcharge `model` → **T5d**.
|
||
- Acceptation d'un nom `plugin:skill` dans `skills:` → **T5e**.
|
||
- Coût réel en jetons du préchargement → **T5f** ; gain réel sur un piège connu → **T5g**.
|
||
- Écarts 5.5/5.8 et contenu exact des skills quodsoler (Markdown seul ?) → revue R1 avant adaptation.
|