LifePlay-Revival/Docs/Migration/etat/SK/SK-ARBRE.md

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.