AnpingWhale/skills

Setup Anping Skills Lanceur de projet

Initialise le dépôt courant dans un environnement de projet adapté à une collaboration à long terme avec Codex. Cette compétence est pilotée par des invites (prompt-driven), pas un script d'installation déterministe : elle explore d'abord, puis demande, puis affiche un brouillon, et enfin écrit.

L'objectif n'est pas d'installer toutes les compétences, mais de les combiner selon les besoins du projet :

• Compétences internes Anping, par exemple multi-agent-orchestrator, transfer-codex-sessions.
• Compétences externes de qualité, par exemple les compétences d'ingénierie de Matt Pocock.
• Fichiers de règles et de connaissances au niveau du projet, par exemple AGENTS.md, CONTEXT.md, CONTEXT-MAP.md, docs/agents/, docs/adr/.

Principes de fonctionnement

• Expliquer le support d'exécution avant de commencer. Les initialisations longues ou multi-fichiers doivent suivre les règles d'orchestration multi-agent du projet en cours ; si la politique de l'outil ne permet pas la délégation, expliquer l'utilisation d'un repli progressif (staged fallback).
• Ne poser qu'une seule question à la fois à l'utilisateur sur une partie donnée. Ne pas lui soumettre toutes les décisions en une seule fois.
• Pour chaque compétence recommandée, expliquer son utilité, sa source et pourquoi elle convient au projet actuel.
• Ne pas inclure le code source de compétences tierces. Les compétences externes sont intégrées uniquement via leur source d'installation ou un répertoire de référence.
• Avant d'écrire un fichier, montrer d'abord les fichiers à modifier, les blocs clés et les choix par défaut, puis obtenir la confirmation de l'utilisateur avant d'écrire.
• Ne pas écraser le contenu existant de AGENTS.md, README.md, CONTEXT.md ou docs/agents/* ; mettre à jour les blocs existants, éviter les ajouts redondants.

Flux de travail

1. Pré-vérification des compétences dépendantes

Vérifier d'abord si les compétences clés sont présentes dans la session en cours et dans ~/.codex/skills/. Lire references/skill-catalog.md et déterminer, selon les besoins du projet, lesquelles sont obligatoires, recommandées ou optionnelles :

• Sélection des compétences et clarification des objectifs : ask-matt, grill-with-docs.
• Modélisation du domaine et capitalisation des connaissances : domain-modeling.
• Orchestration du thread principal : multi-agent-orchestrator.
• Configuration de projet d'ingénierie : setup-matt-pocock-skills.

Ne pas installer automatiquement tous les éléments manquants. Expliquer d'abord à l'utilisateur les compétences manquantes, leur source, leur utilité et leur niveau de recommandation ; une fois l'utilisateur d'accord, les installer via skill-installer ou la méthode recommandée par la source amont.

2. Exploration du projet

Lire rapidement l'état actuel du dépôt, ne donner qu'un bref aperçu à l'utilisateur, sans tirer de conclusions excessives :

• git remote -v et .git/config : est-ce un projet GitHub/GitLab/local.
• AGENTS.md, CLAUDE.md à la racine : existe-t-il déjà des règles d'agent ou une section Agent skills.
• README.md à la racine : l'objectif du projet est-il déjà clair.
• CONTEXT.md, CONTEXT-MAP.md à la racine.
• docs/agents/, docs/adr/, src/*/docs/adr/.
• .scratch/ : existe-t-il déjà une convention de suivi des problèmes en markdown local.
• ~/.codex/skills/ ou les compétences disponibles dans la session en cours : quelles compétences internes et externes sont installées.

3. Affichage des découvertes

Informer l'utilisateur avec une courte liste :

• Le type approximatif du projet actuel.
• Les fichiers de collaboration IA déjà existants.
• Les fichiers manquants mais potentiellement utiles.
• Les compétences clés installées/non installées.
• Les décisions qui seront demandées progressivement.

4. Questions progressives

Chaque section commence par expliquer l'utilité et l'impact en 1 à 3 phrases, puis donne une suggestion par défaut, attend la réponse de l'utilisateur avant de passer à la section suivante.

A. Objectif du projet

Si l'objectif du projet n'est pas clair, utiliser d'abord ask-matt pour choisir le processus approprié ; si une documentation doit être élaborée au fur et à mesure des entretiens, utiliser grill-with-docs. Une fois l'objectif convenu, demander s'il faut écrire ou mettre à jour la description du projet dans README.md.

B. Mode d'orchestration du thread principal

Demander si multi-agent-orchestrator doit être activé. Expliquer que les avantages sont la gouvernance du contexte, la validation indépendante et la réduction de l'auto-validation ; l'inconvénient est que les tâches courtes peuvent augmenter le nombre total de tokens. Une fois l'utilisateur d'accord, continuer en demandant s'il faut écrire une délégation au niveau du projet : autoriser le thread principal, dans le respect des politiques système/développeur/outil, des règles du dépôt et des exigences d'approbation, à créer ou utiliser de manière autonome un subagent / role agent avec un thread Codex visible par l'utilisateur. Après confirmation, écrire les règles d'orchestration du thread principal et l'autorisation dans AGENTS.md, en utilisant de préférence le modèle de la compétence installée.

C. Disposition du contexte

Laisser l'utilisateur choisir :

• Single-context : un CONTEXT.md à la racine et docs/adr/. La plupart des dépôts choisissent ceci par défaut.
• Multi-context : un CONTEXT-MAP.md à la racine pointant vers plusieurs répertoires de contexte, adapté aux monorepos ou aux dépôts multi-produits.

Lors de l'écriture de fichiers spécifiques, lire references/project-files.md.

D. Base de connaissances du projet

Demander s'il faut créer une base de connaissances du projet destinée aux humains et à l'IA. Suggestion par défaut :

• docs/agents/anping-skills.md : les compétences activées pour ce projet, leur utilité et leurs limites d'appel.
• docs/agents/project-knowledge.md : règles de capitalisation des connaissances du projet.
• docs/adr/README.md : instructions d'utilisation des ADR. Par défaut, les ADR sont rédigés en chinois, sauf si l'utilisateur souhaite explicitement les rédiger en anglais ou en bilingue.

E. Intégration de compétences externes

Recommander des compétences externes en fonction du type de projet. Par défaut, ne pas toutes les installer ; ne recommander que les combinaisons utiles pour le projet actuel. Avant d'installer des compétences tierces, expliquer leur source et leur justification, et demander une confirmation.

5. Affichage du brouillon et confirmation

Avant d'écrire, afficher :

• La liste des fichiers à modifier ou à créer.
• Le résumé des sections à ajouter/mettre à jour dans AGENTS.md, y compris si Delegation Authorization est écrite.
• La liste des compétences à enregistrer dans docs/agents/anping-skills.md.
• La disposition de CONTEXT.md ou CONTEXT-MAP.md.
• Si des compétences externes doivent être installées ou recommandées.

Exécuter les modifications de fichiers après confirmation de l'utilisateur.

6. Écriture de la configuration du projet

Écrire selon le choix de l'utilisateur :

• La section de collaboration Anping/Codex dans AGENTS.md ou dans un fichier de règles d'agent existant.
• docs/agents/anping-skills.md.
• docs/agents/project-knowledge.md.
• CONTEXT.md ou CONTEXT-MAP.md.
• docs/adr/README.md.
• Les éléments d'ignorance sécurisée dans .gitignore, par exemple codex_sessions/, si le projet utilise la migration de sessions.

Si le projet utilise également setup-matt-pocock-skills, ne pas réécrire un bloc Agent skills de même signification ; mettre à jour ou fusionner les sections existantes.

7. Validation

Après l'écriture, effectuer une validation légère avant de signaler la fin :

• Relire les sections clés modifiées, vérifier que le contenu se trouve bien dans les fichiers prévus.
• Vérifier qu'il n'y a pas de bloc Anping / Agent skills / Multi-Agent Orchestrator en double.
• Confirmer que les fichiers à créer existent, par exemple docs/agents/anping-skills.md, CONTEXT.md ou CONTEXT-MAP.md, docs/adr/README.md.
• Si des fichiers YAML, TOML, JSON ou d'autres configurations analysables ont été modifiés, utiliser un analyseur local pour valider le format.
• Si un choix n'a pas été exécuté, enregistrer la raison et les risques restants.

8. Clôture

Rapporter en fin de processus :

• Quelles capacités ont été activées.
• Quels fichiers ont été modifiés.
• Quelles compétences sont installées, lesquelles sont seulement recommandées.
• Comment l'utilisateur peut déclencher ces capacités en une phrase par la suite.
• Les risques restants, par exemple compétence externe non installée, identifiants GitHub indisponibles, objectif du projet toujours flou.

Ne pas commit, push ou télécharger automatiquement, sauf demande explicite de l'utilisateur.