8.0 KiB
description, argument-hint
| description | argument-hint | ||
|---|---|---|---|
| Suivre les changements du rapport des commandes Claude Code et trouver ce qui doit être mis à jour |
|
Workflow Changelog — Rapport Commands
Tu es un coordinateur pour le projet claude-code-best-practice. Ta mission consiste à lancer un agent de recherche, attendre ses résultats et présenter un rapport sur la dérive du rapport Commands Reference (best-practice/claude-commands.md).
Ce workflow vérifie exactement deux types de dérive :
- Champs de frontmatter — tout champ ajouté ou supprimé dans la documentation officielle
- Commandes officielles — toute commande slash intégrée ajoutée ou supprimée
Versions à vérifier : $ARGUMENTS (par défaut : 10 si vide ou non numérique)
Il s’agit d’un workflow lire puis rapporter. Lance l’agent, fusionne les constats et produis un rapport. N’agis que si l’utilisateur approuve.
Phase 1 : lancer l’agent de recherche
Lance workflow-claude-commands-agent avec ce prompt :
Research the claude-code-best-practice project for commands report drift. Check the last $ARGUMENTS versions (default: 10).
Fetch these 2 external sources:
- Slash Commands Reference: https://code.claude.com/docs/en/slash-commands
- Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
Then read the local report (
best-practice/claude-commands.md).Check for exactly two things:
- Frontmatter fields: Compare the official docs' supported command frontmatter fields against the report's Frontmatter Fields table. Flag any fields that were added or removed.
- Official commands: Compare the official docs' built-in slash commands list against the report's official commands table. Flag any commands that were added or removed. Also check if any command's tag or description has changed.
Phase 2 : lire les entrées précédentes du changelog
Pendant que l’agent s’exécute, lis changelog/best-practice/claude-commands/changelog.md pour obtenir les 25 dernières entrées. Analyse les actions prioritaires afin d’identifier :
- Éléments récurrents — problèmes déjà apparus et encore non résolus
- Nouveaux éléments — problèmes apparaissant pour la première fois
- Éléments résolus — problèmes signalés précédemment et désormais corrigés
Phase 3 : générer le rapport
Attends que l’agent termine. Produis un rapport avec ces sections :
- Frontmatter Field Changes — Champs ajoutés ou supprimés dans la documentation officielle par rapport à notre rapport
- Official Command Changes — Commandes slash intégrées ajoutées ou supprimées par rapport à notre tableau
Termine par un tableau récapitulatif priorisé Action Items. Chaque élément doit inclure une colonne Status indiquant NEW, RECURRING (first seen: <date>) ou RESOLVED :
Priority Actions:
# | Type | Action | Status
1 | New Field | Add <field> to frontmatter table | NEW
2 | Removed Field | Remove <field> from table | RECURRING (first seen: <date>)
3 | New Command | Add <command> to official table | NEW
4 | Removed Command | Remove <command> from table | NEW
5 | Changed Tag | Update <command> tag from X to Y | NEW
Inclus aussi une section Resolved Since Last Run listant les éléments des exécutions précédentes qui ne sont plus des problèmes.
Phase 3.5 : ajouter le résumé au changelog
Cette phase est OBLIGATOIRE — exécute-la toujours avant de présenter le rapport à l’utilisateur.
Lis le fichier changelog/best-practice/claude-commands/changelog.md existant, puis ajoute (ne remplace PAS) une nouvelle entrée à la fin. Le format de l’entrée doit être exactement :
---
## [<YYYY-MM-DD HH:MM AM/PM PKT>] Claude Code v<VERSION>
| # | Priority | Type | Action | Status |
|---|----------|------|--------|--------|
| 1 | HIGH/MED/LOW | <type> | <action description> | <status> |
| ... | ... | ... | ... | ... |
Format de statut — DOIT utiliser l’un de ces trois formats :
COMPLETE (reason)— l’action a été réalisée et résolue avec succèsINVALID (reason)— le constat était incorrect, non applicable ou intentionnelON HOLD (reason)— action différée, en attente d’une dépendance externe ou d’une décision utilisateur
Le (reason) est obligatoire et doit expliquer brièvement ce qui a été fait ou pourquoi.
Règles d’ajout :
- Toujours ajouter — ne jamais écraser ou remplacer les entrées précédentes
- La date et l’heure correspondent à l’exécution de la commande en Pakistan Standard Time (PKT, UTC+5) ; obtiens-les avec
TZ=Asia/Karachi date "+%Y-%m-%d %I:%M %p PKT". La version vient des constats de l’agent - Si
changelog/best-practice/claude-commands/changelog.mdn’existe pas ou est vide, crée-le avec le tableau Status Legend (voir le haut du fichier), puis la première entrée - Chaque entrée est séparée par
--- - Inclure uniquement les éléments de priorité HIGH, MEDIUM ou LOW — omettre les éléments de priorité NONE
Phase 3.6 : mettre à jour le badge Last Updated
Cette phase est OBLIGATOIRE — exécute-la toujours immédiatement après la Phase 3.5, avant de présenter le rapport.
Mets à jour le badge "Last Updated" en haut de best-practice/claude-commands.md. Exécute TZ=Asia/Karachi date "+%b %d, %Y %-I:%M %p PKT" pour obtenir l’heure, encode-la pour URL (espaces en %20, virgules en %2C) et remplace la portion date du badge. Mets aussi à jour la version Claude Code dans le badge si elle a changé.
Ne journalise PAS les mises à jour de badge comme action items dans le changelog ou le rapport. La synchronisation du badge est une routine de chaque exécution, pas un constat.
Phase 4 : proposer d’agir
Après avoir présenté le rapport (et confirmé que le changelog et le badge ont été mis à jour), demande à l’utilisateur :
- Execute all actions — Appliquer tous les changements
- Execute specific actions — L’utilisateur choisit les numéros à exécuter
- Just save the report — Aucun changement
Pendant l’exécution :
- Nouveaux champs : ajouter au tableau Frontmatter Fields avec le type, le statut obligatoire et la description corrects depuis la documentation officielle
- Champs supprimés : confirmer avec l’utilisateur avant suppression
- Nouvelles commandes : ajouter au tableau des commandes officielles avec #, commande, tag et description corrects. Insérer dans le bon groupe de tags (le tableau est trié par tag)
- Commandes supprimées : confirmer avec l’utilisateur avant suppression
- Tags modifiés : mettre à jour le tag de la commande et retrier si nécessaire
- Après tout ajout ou suppression, mettre à jour le nombre dans les titres
## Frontmatter Fields (N)et##  **(N)**
Règles critiques
- Ne jamais deviner les versions ou dates — utiliser les données de l’agent
- Croiser les nombres de champs — le nombre de champs du rapport doit correspondre à la documentation officielle
- Croiser les nombres de commandes — le nombre de commandes du rapport doit correspondre à la documentation officielle
- Ne pas auto-exécuter — toujours présenter le rapport d’abord
- TOUJOURS ajouter au changelog — la Phase 3.5 est obligatoire. Ne jamais la sauter. Ne jamais écraser les entrées précédentes.
- TOUJOURS mettre à jour le badge Last Updated — la Phase 3.6 est obligatoire. Ne jamais la sauter.
- Comparer avec les exécutions précédentes — lire les 25 dernières entrées du changelog et marquer chaque action item comme NEW, RECURRING ou RESOLVED.
- Maintenir l’ordre de tri des tags — le tableau des commandes officielles est trié par tag (alphabétique), puis par nom de commande dans chaque groupe. Préserve cet ordre lors des ajouts ou suppressions.