BIGboss248/nextjs-wordpress

Personnalisateur Antigravity (ag-customizer)

Utilisez cette compétence pour concevoir, structurer, configurer, migrer et valider de manière autonome les personnalisations pour Google Antigravity, aussi bien au niveau de l'espace de travail qu'au niveau global.

---

Matrice de Décision Rapide

Déterminez quel mécanisme de personnalisation est le mieux adapté au problème :

Besoin	Mécanisme	Emplacement du fichier	Guide de référence
Enseigner à l'agent une procédure en plusieurs étapes, une procédure ou une commande slash	Compétence	.agents/skills/<nom>/SKILL.md ou ~/.gemini/antigravity/skills/<nom>/SKILL.md	skills-guide.md
Imposer des contraintes persistantes, des normes de codage ou des règles de style	Règle	.agents/rules/<nom>.md, AGENTS.md ou ~/.gemini/GEMINI.md	rules-guide.md
Connecter des services externes, des bases de données locales ou des outils personnalisés	Serveur MCP	.agents/mcp_config.json ou ~/.gemini/config/mcp_config.json	mcp-guide.md
Intercepter des événements du cycle de vie (commande de porte, injection d'invites, arrêt du chien de garde)	Hook de cycle de vie	.agents/hooks.json ou ~/.gemini/config/hooks.json	hooks-guide.md
Regrouper compétences, règles, hooks et MCP dans un package partageable	Plugin	.agents/plugins/<nom>/ ou ~/.gemini/config/plugins/<nom>/	plugins-and-configs.md
Enregistrer des chemins non standard ou partager des personnalisations via un VCS	Config JSON	.agents/skills.json ou .agents/plugins.json	plugins-and-configs.md
Mettre à niveau des workflows obsolètes vers des compétences modernes de type commande slash	Migration de workflow	.agents/workflows/*.md -> .agents/skills/<nom>/SKILL.md	workflows-migration.md

---

Flux de Travail Opérationnels

1. Ajout d'une Nouvelle Compétence

1. Déterminer la Portée :
   • Espace de travail : .agents/skills/<nom>/ (versionné dans le dépôt pour l'équipe).
   • Global : ~/.gemini/antigravity/skills/<nom>/ (disponible dans tous les projets).
2. Structurer le Répertoire :

   <racine_de_personnalisation>/skills/<nom-de-la-competence>/
   ├── SKILL.md             # Requis : Point d'entrée avec frontmatter YAML
   ├── scripts/             # Facultatif : Scripts d'aide (exécutés avec --help)
   ├── references/          # Facultatif : Manuels fournis et documentation lourde
   └── examples/            # Facultatif : Exemples de code ou de sortie de référence
   

3. Rédiger le Frontmatter :
   • name : En minuscules, avec traits d'union (ex. nextjs-otel, docker-deploy). Cela enregistre également la commande slash (/<nom>).
   • description : 1 à 3 phrases à la troisième personne, indiquant explicitement ce que fait la compétence et les déclencheurs/scénarios spécifiques pour lesquels l'agent doit l'activer.
4. Appliquer la Divulgation Progressive :
   • Gardez le fichier SKILL.md principal concentré sur la séquence des étapes opérationnelles et les critères de réalisation.
   • Placez les références détaillées dans les fichiers references/<sujet>.md et liez-les de manière relative.
   • Reportez-vous au skills-guide.md pour les modèles de structure.
5. Vérification du Miroir Obsidian :
   • Lors de la mise à jour ou de la création de compétences dans cet espace de travail, créez un miroir du dossier de compétence vers d:/Scripts/Obsidian/skills/<nom>/ conformément aux directives du dépôt.

---

2. Création d'une Règle

1. Déterminer la Portée et le Format :
   • Règle d'espace de travail : .agents/rules/<nom-de-la-regle>.md ou AGENTS.md à la racine du projet.
   • Règle globale : ~/.gemini/GEMINI.md.
2. Choisir le Mode d'Activation (pour .agents/rules/*.md) :
   • always_on : Injectée inconditionnellement à chaque tour. À utiliser avec parcimonie pour préserver le contexte.
   • model_decision : Divulguée lorsque l'agent détermine la pertinence en fonction de la description.
   • glob : Activée automatiquement lorsque des fichiers correspondants sont touchés ou ouverts (par ex., *.tsx, src/api/**/*.ts).
   • manual : Chargée uniquement lorsqu'elle est explicitement invoquée via @mention dans le chat (par ex., @ma-regle.md).
3. Rédiger le Contenu :
   • Restez dans la limite de 12 000 caractères par fichier.
   • Exprimez les comportements cibles de manière positive (« Faites X », « Structurez toujours Y ») plutôt que par des interdictions.
   • Utilisez @nom-de-fichier pour lier des fichiers de contexte compagnons si nécessaire.
   • Reportez-vous au rules-guide.md pour la syntaxe complète et le frontmatter d'activation.

---

3. Configuration d'un Serveur MCP

1. Déterminer l'Emplacement du Fichier :
   • Espace de travail : <espace-de-travail>/.agents/mcp_config.json
   • Global : ~/.gemini/config/mcp_config.json
2. Sélectionner le Transport :
   • stdio (Exécutable local) :

     {
       "mcpServers": {
         "mon-serveur": {
           "command": "npx",
           "args": ["-y", "@modelcontextprotocol/server-sqlite", "app.db"],
           "env": { "SQLITE_READONLY": "true" }
         }
       }
     }
     

   • Distant (SSE / Streamable HTTP) :

     [!IMPORTANT] Utilisez toujours la clé serverUrl. Les clés obsolètes url ou httpUrl ne sont pas prises en charge.

     {
       "mcpServers": {
         "mon-distant": {
           "serverUrl": "https://api.exemple.com/mcp/",
           "headers": { "Authorization": "Bearer VOTRE_TOKEN" }
         }
       }
     }
     

3. Authentification :
   • Identifiants par défaut de l'application Google : "authProviderType": "google_credentials" (nécessite gcloud auth application-default login).
   • OAuth : "oauth": { "clientId": "...", "clientSecret": "..." } avec URI de redirection https://antigravity.google/oauth-callback.
4. Filtrage des Outils :
   • Désactivez temporairement des outils sans supprimer le serveur : "disabledTools": ["destructive_command"].
   • Reportez-vous au mcp-guide.md pour les configurations pré-construites.

---

4. Mise en Place de Hooks de Cycle de Vie

1. Fichier Cible : .agents/hooks.json (ou ~/.gemini/config/hooks.json).
2. Événements Pris en Charge :
   • PreToolUse : Faire correspondre les noms d'outils (run_command, write_to_file, *) pour contrôler l'exécution (allow, deny, ask, force_ask) ou remplacer partiellement les arguments.
   • PostToolUse : Auditer la sortie, exécuter des linters ou formater le code après l'achèvement de l'outil.
   • PreInvocation : Injecter du contexte ou des instructions système (injectSteps avec ephemeralMessage) avant que le modèle ne traite le tour.
   • PostInvocation : Forcer la continuation (terminationBehavior: "force_continue") ou arrêter.
   • Stop : Inspecter l'achèvement de la tâche (terminationReason, fullyIdle) et retourner decision: "continue" avec reason pour bloquer une sortie prématurée.
3. Règles du Contrat :
   • L'exécution passe le contexte via stdin et reçoit la réponse via stdout.
   • Toutes les clés de la charge utile JSON utilisent le camelCase (conversationId, stepIdx, toolCall, etc.).
   • Les commandes s'exécutent de manière synchrone et bloquent la boucle de l'agent jusqu'au délai d'attente (30s par défaut).
   • Reportez-vous au hooks-guide.md pour les modèles en Python, PowerShell et Bash.

---

5. Empaquetage d'un Plugin ou d'une Configuration Partagée via VCS

1. Package du Plugin :
   • Regroupez les compétences, règles, hooks et serveurs MCP associés dans .agents/plugins/<nom-du-plugin>/.
   • Ajoutez le manifeste plugin.json ({"name": "mon-plugin"}).
   • Gérez l'état d'activation dans config.json sous "plugins": { "<nom-du-plugin>": { "enabled": true } }.
2. Configurations JSON (skills.json / plugins.json) :
   • Enregistrez des répertoires externes ou des dépôts d'équipe partagés.
   • Prenez en charge les entries (chemins) et les inherits (autres configurations) avec des filtres regex include_only et exclude.
   • Reportez-vous au plugins-and-configs.md pour des exemples de manifeste complets.

---

6. Modernisation des Workflows Obsolètes

1. Inspectez la présence de fichiers .agents/workflows/*.md ou ~/.gemini/config/workflows/*.md obsolètes.
2. Extrayez les instructions opérationnelles et générez le SKILL.md équivalent avec un frontmatter YAML approprié.
3. Archivez le fichier original en <nom>.md.bak (préservation sécurisée).
4. Reportez-vous au workflows-migration.md pour le guide de migration automatisée.

---

Liste de Vérification & Validation

Avant de considérer une personnalisation comme terminée :

• Syntaxe JSON : Assurez-vous que tous les fichiers .json sont analysés correctement sans erreurs de syntaxe ni commentaires.
• Vérification du Frontmatter : Vérifiez que SKILL.md contient un frontmatter YAML valide avec name et une description descriptive.
• Budget de Caractères : Assurez-vous que les fichiers de règles Markdown respectent la limite de 12 000 caractères.
• Connexion MCP : Vérifiez que les binaires de commande ou les URL distantes existent et s'authentifient.
• Contrat de Hook : Vérifiez que les scripts de hook acceptent le JSON en camelCase sur stdin et renvoient un JSON valide sur stdout.
• Miroir Obsidian : Pour les compétences dans cet espace de travail, synchronisez le dossier de compétence créé vers d:/Scripts/Obsidian/skills/<nom>/.