[shikanime]

Pourquoi

Les skills du dépôt couvrent le cycle d'une unité (cpn-dev) et ses métadonnées (cpn-issue, cpn-triage, cpn-pi-transition) mais pas la couche d'orchestration au-dessus : planifier un milestone depuis un but, faire tourner une boucle de travail pilotée par le board, suivre les cartes et leur champ Status. Ces mécaniques sont éprouvées dans le catalogue d'agents ; leur absence oblige chaque agent à improviser la planification et le pilotage.

Quoi

• .agents/skills/cpn-plan/ — converger un but, décomposer en unités dépendancées (table gate avant ouverture), remplir le milestone selon la convention du dépôt, issues triées et boardées, rapport de passe à cpn-iterate
• .agents/skills/cpn-iterate/ — boucle board : tirer la carte la plus à droite de la colonne active, router vers cpn-delegate/cpn-dev, trois conditions d'arrêt, bloc de statut par itération
• .agents/skills/cpn-project/ — boarding et champ Status sur le Projet Socle : découverte du vocabulaire du board en direct, carte des phases, gate des mutations en lot
• evals/evals.json par skill : trois scénarios (nominal, cas limite, pression)
• Pointeurs board de cpn-dev, cpn-issue et cpn-triage routés vers cpn-project ; référence cpn-dev-workflow obsolète corrigée dans cpn-triage
• Alignement amont (commit ca6c4e98) : cpn-merge/cpn-commit/cpn-project suivent la lane réelle du dépôt — la merge queue est la seule voie (--auto --rebase, rebase seul, squash rejeté même avec --admin), une poussée après approbation la révoque (dismiss_stale_reviews_on_push), éjection → restack → ré-armement ; cpn-triage/cpn-issue/cpn-pr portent la porte de pertinence — assignation seulement pour un travail pilotable par un agent, sinon champ vide motivé ; scan-untriaged.sh retire assignee des classes de gap (relecture réelle sur le dépôt : zéro gap d'assignee restant)

Frontière : les itérations PI et la cohérence PI↔milestone restent cpn-pi-transition ; le cycle d'une unité reste cpn-dev.

Vérification

• Frontmatter et squelette vérifiés par script : name = répertoire, description Use when, license, metadata.version, ## Prérequis en tête, ## Vérification en clôture, < 500 lignes par skill
• Aucun contenu personnel : grep -riE 'sks-|jj |auth switch|shikanime|automata' vide sur les nouveaux fichiers
• JSON des trois batteries d'evals validé (3 scénarios chacun, assertions présentes)
• Comparaison sans/avec skill exécutée (protocole cpn-create-skill, itération 1) : candidat conforme sur toutes les assertions requises ; les contrôles sans skill échouent sur les mêmes discriminants (aucune gate d'approbation, milestone à titre libre créé inline, ids de board PVTSSF_ codés en dur, décomposition forcée d'un but non convergé). Deux assertions trop faibles ou trop larges détectées à la relecture, corrigées dans le second commit (PVTSSF_, milestones -f title). Aucune régression du candidat.
• Alignement amont : bash -n sur le script modifié, exécution réelle de scan-untriaged.sh sur le dépôt (aucun gap d'assignee rapporté), CI verte sur la tête poussée (ca6c4e98)

Références

• 💡 [REQUEST] - Upstreamer la couche d'orchestration du catalogue (plan, itération, board) #2941
• 💡 [REQUEST] - Distiller les conventions de contribution en skills agent-owned #2710 (premier pass skills)
• 💡 [REQUEST] - Renommer cpn-dev-workflow en cpn-dev et porter les mécaniques amont de triage, milestones et board #2897 (mécaniques amont milestones/board dans cpn-dev)