traduction
This commit is contained in:
@@ -0,0 +1,140 @@
|
||||
---
|
||||
description: Suivre les changements du rapport des commandes Claude Code et trouver ce qui doit être mis à jour
|
||||
argument-hint: [number of versions to check, default 10]
|
||||
---
|
||||
|
||||
# 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** :
|
||||
1. **Champs de frontmatter** — tout champ ajouté ou supprimé dans la documentation officielle
|
||||
2. **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:
|
||||
> 1. Slash Commands Reference: https://code.claude.com/docs/en/slash-commands
|
||||
> 2. 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:
|
||||
> 1. **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.
|
||||
> 2. **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 :
|
||||
|
||||
1. **Frontmatter Field Changes** — Champs ajoutés ou supprimés dans la documentation officielle par rapport à notre rapport
|
||||
2. **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` :
|
||||
|
||||
```markdown
|
||||
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 :
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## [<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ès
|
||||
- `INVALID (reason)` — le constat était incorrect, non applicable ou intentionnel
|
||||
- `ON 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.md` n’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 :
|
||||
|
||||
1. **Execute all actions** — Appliquer tous les changements
|
||||
2. **Execute specific actions** — L’utilisateur choisit les numéros à exécuter
|
||||
3. **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
|
||||
|
||||
1. **Ne jamais deviner** les versions ou dates — utiliser les données de l’agent
|
||||
2. **Croiser les nombres de champs** — le nombre de champs du rapport doit correspondre à la documentation officielle
|
||||
3. **Croiser les nombres de commandes** — le nombre de commandes du rapport doit correspondre à la documentation officielle
|
||||
4. **Ne pas auto-exécuter** — toujours présenter le rapport d’abord
|
||||
5. **TOUJOURS ajouter au changelog** — la Phase 3.5 est obligatoire. Ne jamais la sauter. Ne jamais écraser les entrées précédentes.
|
||||
6. **TOUJOURS mettre à jour le badge Last Updated** — la Phase 3.6 est obligatoire. Ne jamais la sauter.
|
||||
7. **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.
|
||||
8. **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.
|
||||
@@ -0,0 +1,243 @@
|
||||
---
|
||||
description: Suivre les changements du rapport des paramètres Claude Code et trouver ce qui doit être mis à jour
|
||||
argument-hint: [number of versions to check, default 10]
|
||||
---
|
||||
|
||||
# Workflow Changelog — Rapport Settings
|
||||
|
||||
Tu es un coordinateur pour le projet claude-code-best-practice. Ta mission consiste à lancer deux agents de recherche en parallèle, attendre leurs résultats, fusionner les constats et présenter un rapport unifié sur la dérive du rapport **Settings Reference** (`best-practice/claude-settings.md`).
|
||||
|
||||
**Versions à vérifier :** `$ARGUMENTS` (par défaut : 10 si vide ou non numérique)
|
||||
|
||||
Il s’agit d’un workflow **lire puis rapporter**. Lance les agents, fusionne les résultats et produis un rapport. N’agis que si l’utilisateur approuve.
|
||||
|
||||
---
|
||||
|
||||
## Phase 0 : lancer les deux agents en parallèle
|
||||
|
||||
**Immédiatement**, lance les deux agents avec l’outil Task **dans le même message** (lancement parallèle) :
|
||||
|
||||
### Agent 1 : workflow-claude-settings-agent
|
||||
|
||||
Lance avec `subagent_type: "workflow-claude-settings-agent"`. Donne-lui ce prompt :
|
||||
|
||||
> Research the claude-code-best-practice project for settings report drift. Check the last $ARGUMENTS versions (default: 10).
|
||||
>
|
||||
> Fetch these 3 external sources:
|
||||
> 1. Settings Documentation: https://code.claude.com/docs/en/settings
|
||||
> 2. CLI Reference: https://code.claude.com/docs/en/cli-reference
|
||||
> 3. Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
|
||||
>
|
||||
> Then read the local report file (`best-practice/claude-settings.md`) and the CLAUDE.md file. Analyze differences between what the official docs say about settings keys, permission syntax, hook events, MCP configuration, sandbox options, plugin settings, model aliases, display settings, and environment variables versus what our report documents. Return a structured findings report covering missing settings, changed types/defaults, new settings additions, deprecated settings, permission syntax changes, hook event changes, MCP setting changes, sandbox setting changes, environment variable completeness, example accuracy, settings hierarchy accuracy, and sources validity.
|
||||
|
||||
### Agent 2 : claude-code-guide
|
||||
|
||||
Lance avec `subagent_type: "claude-code-guide"`. Donne-lui ce prompt :
|
||||
|
||||
> Research the latest Claude Code settings system. I need you to find:
|
||||
> 1. The complete list of all currently supported settings.json keys with their types, defaults, and descriptions
|
||||
> 2. Any new settings keys introduced in recent Claude Code versions
|
||||
> 3. Changes to existing settings behavior (e.g. new permission modes, new hook events, new sandbox options)
|
||||
> 4. Changes to the settings hierarchy (new priority levels, new file locations)
|
||||
> 5. Changes to permission syntax (new tool patterns, new wildcard behavior)
|
||||
> 6. New hook events or changes to hook configuration structure
|
||||
> 7. Changes to MCP server configuration (new matching fields, new settings)
|
||||
> 8. Changes to sandbox settings (new network options, new commands)
|
||||
> 9. Changes to plugin configuration (new fields, new marketplace options)
|
||||
> 10. Changes to environment variables (new vars, deprecated vars, changed behavior)
|
||||
> 11. Changes to model aliases or model configuration
|
||||
> 12. Changes to display/UX settings (status line, spinners, progress bars)
|
||||
> 13. Any deprecations or removals of settings keys
|
||||
>
|
||||
> Be thorough — search the web, fetch docs, and provide concrete version numbers and details for everything you find.
|
||||
|
||||
Les deux agents s’exécutent indépendamment et retourneront leurs constats.
|
||||
|
||||
---
|
||||
|
||||
## Phase 0.5 : lire la checklist de vérification
|
||||
|
||||
**Pendant que les agents s’exécutent**, lis `changelog/best-practice/claude-settings/verification-checklist.md`. Ce fichier contient les règles de vérification accumulées — chaque règle précise quoi vérifier, à quelle profondeur et contre quelle source. Chaque règle DOIT être exécutée pendant la Phase 2. La checklist est la suite de tests de régression du projet pour la détection de dérive.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 : lire les entrées précédentes du changelog
|
||||
|
||||
**Avant de fusionner les constats**, lis le fichier `changelog/best-practice/claude-settings/changelog.md` pour obtenir les 25 dernières entrées de changelog. Chaque entrée est séparée par `---`. Analyse les actions prioritaires des entrées précédentes afin de pouvoir les comparer aux constats actuels. Cela permet d’identifier :
|
||||
- **Éléments récurrents** — problèmes déjà apparus et encore non résolus
|
||||
- **Éléments nouvellement résolus** — problèmes des exécutions précédentes désormais corrigés
|
||||
- **Nouveaux éléments** — problèmes apparaissant pour la première fois dans cette exécution
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 : fusionner les constats et générer le rapport
|
||||
|
||||
**Attends que les deux agents terminent.** Une fois que tu as :
|
||||
- **Constats de workflow-claude-settings-agent** — analyse détaillée du rapport avec lectures de fichiers locaux, récupération de docs externes et détection de dérive
|
||||
- **Constats de claude-code-guide** — recherche indépendante sur les dernières fonctionnalités et changements des paramètres Claude Code
|
||||
|
||||
Croise les deux. L’agent dédié fournit l’analyse de dérive spécifique au rapport, tandis que claude-code-guide peut faire remonter des éléments qu’il a manqués (par exemple des changements très récents, des fonctionnalités non documentées ou du contexte issu de recherches web). Signale toute contradiction entre les deux pour résolution par l’utilisateur.
|
||||
|
||||
**Exécute la checklist de vérification :** pour chaque règle dans `changelog/best-practice/claude-settings/verification-checklist.md`, effectue la vérification à la profondeur indiquée en utilisant les constats des agents comme données source. Inclus une section **Verification Log** dans le rapport montrant le résultat de chaque règle :
|
||||
|
||||
```text
|
||||
Verification Log:
|
||||
Rule # | Category | Depth | Result | Notes
|
||||
1 | Settings Keys | field-level | PASS | All keys match
|
||||
2 | Permission Syntax | content-match | FAIL | New tool pattern added
|
||||
...
|
||||
```
|
||||
|
||||
**Mets à jour la checklist si nécessaire :** si un constat révèle un nouveau type de dérive qu’aucune règle existante ne couvre (ou couvre à une profondeur insuffisante), ajoute une nouvelle règle à `changelog/best-practice/claude-settings/verification-checklist.md`. La règle doit inclure : catégorie, quoi vérifier, niveau de profondeur, source de comparaison, date d’ajout et origine (l’erreur ayant motivé cette règle). N’ajoute PAS de règles pour des problèmes ponctuels qui ne se reproduiront pas.
|
||||
|
||||
Compare aussi les constats actuels aux entrées précédentes du changelog (depuis la Phase 1). Pour chaque action prioritaire, marque-la comme :
|
||||
- `NEW` — première apparition du problème
|
||||
- `RECURRING` — déjà apparu lors d’une exécution précédente et encore non résolu (inclure la date de première apparition)
|
||||
- `RESOLVED` — apparu lors d’une exécution précédente mais désormais corrigé (inclure la date de résolution)
|
||||
|
||||
Produis un rapport structuré avec ces sections :
|
||||
|
||||
1. **New Settings Keys** — Clés présentes dans la documentation officielle mais absentes du rapport, avec version d’introduction
|
||||
2. **Changed Setting Behavior** — Paramètres dont le type, la valeur par défaut ou la description a changé
|
||||
3. **Deprecated/Removed Settings** — Paramètres présents dans le rapport mais absents de la documentation officielle
|
||||
4. **Permission Syntax Changes** — Nouveaux motifs d’outils, comportement de jokers ou changements de modes de permission
|
||||
5. **MCP Setting Changes** — Nouvelles clés de configuration MCP, comportement de matching ou paramètres serveur
|
||||
6. **Sandbox Setting Changes** — Nouvelles options de sandbox, paramètres réseau ou exclusions de commandes
|
||||
7. **Plugin Setting Changes** — Nouvelles clés de configuration de plugin ou options marketplace
|
||||
8. **Model Configuration Changes** — Nouveaux alias de modèles, niveaux d’effort ou variables d’environnement de modèles
|
||||
9. **Display & UX Changes** — Nouveaux champs de status line, options de spinner ou paramètres d’affichage
|
||||
10. **Environment Variable Completeness** — Variables présentes dans la documentation officielle mais absentes du rapport, ou variables du rapport qui ne sont plus documentées
|
||||
11. **Settings Hierarchy Accuracy** — Vérifier niveaux de priorité, emplacements de fichiers et comportement de surcharge
|
||||
12. **Example Accuracy** — Vérifier si l’exemple complet Quick Reference reflète les paramètres actuels
|
||||
13. **Sources Accuracy** — Vérifier que tous les liens de sources sont valides et pointent vers la bonne documentation
|
||||
14. **claude-code-guide Agent Findings** — Informations uniques de l’agent non capturées par l’agent dédié. N’inclus que les constats qui ajoutent une nouvelle information. S’il existe des contradictions entre les deux agents, signale-les pour résolution par l’utilisateur. Ne liste PAS les "confirmed agreements".
|
||||
|
||||
> **Note :** l’analyse liée aux hooks (événements, propriétés, matchers, codes de sortie, HTTP hooks, variables d’environnement de hooks) est **exclue** de ce workflow. Les hooks sont maintenus dans le dépôt [claude-code-hooks](https://github.com/shanraisshan/claude-code-hooks).
|
||||
|
||||
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` :
|
||||
|
||||
```text
|
||||
Priority Actions:
|
||||
# | Type | Action | Status
|
||||
1 | New Setting | Add <key> to <section> table | NEW
|
||||
2 | Changed Behavior | Update <key> description | NEW
|
||||
3 | Deprecated Setting | Remove <key> from table | RECURRING (first seen: 2026-03-05)
|
||||
4 | Permission Syntax | Add new tool pattern syntax | NEW
|
||||
5 | Env Variable | Add <var> to environment variables table | NEW
|
||||
7 | Example Update | Update Quick Reference example | NEW
|
||||
```
|
||||
|
||||
Inclus aussi une section **Resolved Since Last Run** listant les éléments de l’exécution précédente qui ne sont plus des problèmes.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.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-settings/changelog.md` existant, puis **ajoute** (ne remplace PAS) une nouvelle entrée à la fin. Le format de l’entrée doit être exactement :
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## [<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ès
|
||||
- `INVALID (reason)` — le constat était incorrect, non applicable ou intentionnel
|
||||
- `ON 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-settings/changelog.md` n’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 (éléments ne nécessitant aucune action)
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.6 : mettre à jour le badge Last Updated
|
||||
|
||||
**Cette phase est OBLIGATOIRE — exécute-la toujours immédiatement après la Phase 2.5, avant de présenter le rapport.**
|
||||
|
||||
Mets à jour le badge "Last Updated" en haut de `best-practice/claude-settings.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 2.7 : valider tous les liens
|
||||
|
||||
**Cette phase est OBLIGATOIRE — exécute-la toujours après la Phase 2.6, avant de présenter le rapport.**
|
||||
|
||||
Scanne `best-practice/claude-settings.md` pour chaque lien (markdown `[text](url)` et URLs inline). Pour chaque lien :
|
||||
|
||||
1. **Liens de fichiers locaux** (chemins relatifs) : vérifier que le fichier existe au chemin résolu avec l’outil Read. Signaler tout lien cassé.
|
||||
2. **URLs externes** (par exemple `https://code.claude.com/docs/en/settings`) : récupérer chaque URL avec WebFetch et vérifier qu’elle retourne une page valide (pas une 404 ni une redirection vers une page d’erreur). Signaler tout lien mort ou déplacé.
|
||||
3. **Liens d’ancre** (par exemple `#section-name`) : vérifier que le titre cible existe dans le même fichier.
|
||||
|
||||
Inclus un **Hyperlink Validation Log** dans le rapport :
|
||||
|
||||
```text
|
||||
Hyperlink Validation Log:
|
||||
# | Type | Link | Status | Notes
|
||||
1 | Local | ../ | OK |
|
||||
2 | External | https://code.claude.com/docs/en/settings | OK |
|
||||
3 | External | https://www.schemastore.org/claude-code-settings.json | BROKEN | 404
|
||||
...
|
||||
```
|
||||
|
||||
**Si des liens sont cassés**, ajoute-les comme action items de priorité HIGH dans le rapport. Les liens cassés dégradent l’utilité du rapport et doivent être corrigés avant tout autre changement.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 : 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 :
|
||||
|
||||
1. **Execute all actions** — Tout traiter (ajouter paramètres manquants, mettre à jour descriptions, corriger exemples)
|
||||
2. **Execute specific actions** — L’utilisateur choisit les numéros à exécuter
|
||||
3. **Just save the report** — Aucun changement
|
||||
|
||||
Pendant l’exécution :
|
||||
- **Nouveaux paramètres** : ajouter à la section appropriée du tableau avec type, valeur par défaut et description corrects
|
||||
- **Comportement modifié** : mettre à jour la description ou la valeur par défaut du paramètre dans le tableau
|
||||
- **Paramètres dépréciés** : confirmer avec l’utilisateur avant suppression
|
||||
- **Changements de syntaxe des permissions** : mettre à jour le tableau Permission Syntax avec les nouveaux motifs
|
||||
- **Changements MCP** : mettre à jour la section MCP Settings
|
||||
- **Changements sandbox** : mettre à jour la section Sandbox Settings
|
||||
- **Changements plugin** : mettre à jour la section Plugin Settings
|
||||
- **Changements de modèles** : mettre à jour la section Model Configuration
|
||||
- **Changements d’affichage** : mettre à jour la section Display & UX
|
||||
- **Changements de variables d’environnement** : ajouter/mettre à jour/supprimer des variables dans la section Environment Variables
|
||||
- **Changements de hiérarchie des paramètres** : mettre à jour le tableau Settings Hierarchy
|
||||
- **Mises à jour d’exemple** : mettre à jour l’exemple complet Quick Reference pour refléter les paramètres actuels
|
||||
- **Liens cassés** : corriger ou remplacer les URLs cassées
|
||||
- Après toutes les actions, relancer la vérification pour confirmer la cohérence
|
||||
|
||||
---
|
||||
|
||||
## Règles critiques
|
||||
|
||||
1. **Lancer les DEUX agents en parallèle** dans un seul message — jamais séquentiellement
|
||||
2. **Attendre les deux agents** avant de générer le rapport
|
||||
3. **Ne jamais deviner** les versions ou dates — utiliser les données des agents
|
||||
4. **Les nouvelles clés de paramètres sont PRIORITAIRES** — elles nécessitent des mises à jour de tableaux et d’exemples
|
||||
5. **Croiser les nombres de paramètres** — le nombre de paramètres dans chaque tableau doit correspondre à la documentation officielle
|
||||
6. **Ne pas auto-exécuter** — toujours présenter le rapport d’abord
|
||||
7. **TOUJOURS ajouter au changelog** — la Phase 2.5 est obligatoire. Ne jamais la sauter. Ne jamais écraser les entrées précédentes.
|
||||
8. **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.
|
||||
9. **TOUJOURS exécuter la checklist de vérification** — lire verification-checklist.md et exécuter chaque règle. Inclure un Verification Log dans le rapport. Ajouter de nouvelles règles quand un nouveau type de dérive est découvert.
|
||||
10. **Les règles de checklist sont append-only** — ne jamais retirer ni affaiblir les règles existantes. Ajouter seulement de nouvelles règles ou augmenter les niveaux de profondeur.
|
||||
11. **TOUJOURS mettre à jour le badge Last Updated** — la Phase 2.6 est obligatoire. Ne jamais la sauter.
|
||||
12. **TOUJOURS valider tous les liens** — la Phase 2.7 est obligatoire. Ne jamais la sauter. Les liens cassés sont prioritaires HIGH.
|
||||
13. **Les variables d’environnement sont réparties entre deux fichiers** — `claude-settings.md` possède les variables configurables via `env` ; `claude-cli-startup-flags.md` possède les variables uniquement au démarrage. Ne PAS signaler une variable env comme manquante si elle appartient au fichier CLI. Croiser avec `best-practice/claude-cli-startup-flags.md` pour vérifier les frontières de responsabilité.
|
||||
14. **Vérifier la hiérarchie des paramètres** — la chaîne de surcharge à 5 niveaux plus la couche de politique managed doivent correspondre exactement à la documentation officielle.
|
||||
@@ -0,0 +1,138 @@
|
||||
---
|
||||
description: Suivre les changements du rapport des skills Claude Code et trouver ce qui doit être mis à jour
|
||||
argument-hint: [number of versions to check, default 10]
|
||||
---
|
||||
|
||||
# Workflow Changelog — Rapport Skills
|
||||
|
||||
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 **Skills Reference** (`best-practice/claude-skills.md`).
|
||||
|
||||
Ce workflow vérifie exactement **deux types de dérive** :
|
||||
1. **Champs de frontmatter** — tout champ ajouté ou supprimé dans la documentation officielle
|
||||
2. **Skills officielles intégrées** — toute skill 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-skills-agent` avec ce prompt :
|
||||
|
||||
> Research the claude-code-best-practice project for skills report drift. Check the last $ARGUMENTS versions (default: 10).
|
||||
>
|
||||
> Fetch these 2 external sources:
|
||||
> 1. Skills Reference: https://code.claude.com/docs/en/skills
|
||||
> 2. Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
|
||||
>
|
||||
> Then read the local report (`best-practice/claude-skills.md`).
|
||||
>
|
||||
> Check for exactly two things:
|
||||
> 1. **Frontmatter fields**: Compare the official docs' supported skill frontmatter fields against the report's Frontmatter Fields table. Flag any fields that were added or removed.
|
||||
> 2. **Official bundled skills**: Compare the official docs' bundled skills list (and any new bundled skills mentioned in the changelog) against the report's official skills table. Flag any skills that were added or removed.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 : lire les entrées précédentes du changelog
|
||||
|
||||
**Pendant que l’agent s’exécute**, lis `changelog/best-practice/claude-skills/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 :
|
||||
|
||||
1. **Frontmatter Field Changes** — Champs ajoutés ou supprimés dans la documentation officielle par rapport à notre rapport
|
||||
2. **Official Bundled Skill Changes** — Skills 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` :
|
||||
|
||||
```markdown
|
||||
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 Skill | Add <skill> to official skills table | NEW
|
||||
4 | Removed Skill | Remove <skill> from table | 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-skills/changelog.md` existant, puis **ajoute** (ne remplace PAS) une nouvelle entrée à la fin. Le format de l’entrée doit être exactement :
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## [<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ès
|
||||
- `INVALID (reason)` — le constat était incorrect, non applicable ou intentionnel
|
||||
- `ON 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-skills/changelog.md` n’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-skills.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 :
|
||||
|
||||
1. **Execute all actions** — Appliquer tous les changements
|
||||
2. **Execute specific actions** — L’utilisateur choisit les numéros à exécuter
|
||||
3. **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 skills** : ajouter au tableau des skills officielles avec #, nom de skill et description corrects
|
||||
- **Skills supprimées** : confirmer avec l’utilisateur avant suppression
|
||||
- Après tout ajout ou suppression, mettre à jour le nombre dans les titres `## Frontmatter Fields (N)` et `##  **(N)**`
|
||||
|
||||
---
|
||||
|
||||
## Règles critiques
|
||||
|
||||
1. **Ne jamais deviner** les versions ou dates — utiliser les données de l’agent
|
||||
2. **Croiser les nombres de champs** — le nombre de champs du rapport doit correspondre à la documentation officielle
|
||||
3. **Croiser les nombres de skills** — le nombre de skills du rapport doit correspondre à la documentation officielle
|
||||
4. **Ne pas auto-exécuter** — toujours présenter le rapport d’abord
|
||||
5. **TOUJOURS ajouter au changelog** — la Phase 3.5 est obligatoire. Ne jamais la sauter. Ne jamais écraser les entrées précédentes.
|
||||
6. **TOUJOURS mettre à jour le badge Last Updated** — la Phase 3.6 est obligatoire. Ne jamais la sauter.
|
||||
7. **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.
|
||||
8. **Distinguer intégré d’installable** — suivre uniquement les skills fournies avec Claude Code (intégrées). Ne pas suivre les skills de l’Official Skills Repository (github.com/anthropics/skills) — elles sont installables, pas intégrées.
|
||||
@@ -0,0 +1,136 @@
|
||||
---
|
||||
description: Suivre les changements du rapport des sous-agents Claude Code et trouver ce qui doit être mis à jour
|
||||
argument-hint: [number of versions to check, default 10]
|
||||
---
|
||||
|
||||
# Workflow Changelog — Rapport Subagents
|
||||
|
||||
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 **Subagents Reference** (`best-practice/claude-subagents.md`).
|
||||
|
||||
Ce workflow vérifie exactement **deux types de dérive** :
|
||||
1. **Champs de frontmatter** — tout champ ajouté ou supprimé dans la documentation officielle
|
||||
2. **Sous-agents officiels** — tout agent intégré ajouté ou supprimé
|
||||
|
||||
**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-subagents-agent` avec ce prompt :
|
||||
|
||||
> Research the claude-code-best-practice project for subagents report drift. Check the last $ARGUMENTS versions (default: 10).
|
||||
>
|
||||
> Fetch these 2 external sources:
|
||||
> 1. Sub-agents Reference: https://code.claude.com/docs/en/sub-agents
|
||||
> 2. Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
|
||||
>
|
||||
> Then read the local report (`best-practice/claude-subagents.md`).
|
||||
>
|
||||
> Check for exactly two things:
|
||||
> 1. **Frontmatter fields**: Compare the official docs' supported frontmatter fields table against the report's Frontmatter Fields table. Flag any fields that were added or removed.
|
||||
> 2. **Official sub-agents**: Compare the official docs' built-in subagents list against the report's official agents table. Flag any agents that were added or removed.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 : lire les entrées précédentes du changelog
|
||||
|
||||
**Pendant que l’agent s’exécute**, lis `changelog/best-practice/claude-subagents/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 :
|
||||
|
||||
1. **Frontmatter Field Changes** — Champs ajoutés ou supprimés dans la documentation officielle par rapport à notre rapport
|
||||
2. **Official Sub-agent Changes** — Agents intégrés ajoutés ou supprimés 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` :
|
||||
|
||||
```markdown
|
||||
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 Agent | Add <agent> to official agents table | NEW
|
||||
4 | Removed Agent | Remove <agent> from table | 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-subagents/changelog.md` existant, puis **ajoute** (ne remplace PAS) une nouvelle entrée à la fin. Le format de l’entrée doit être exactement :
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## [<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ès
|
||||
- `INVALID (reason)` — le constat était incorrect, non applicable ou intentionnel
|
||||
- `ON 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-subagents/changelog.md` n’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-subagents.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 :
|
||||
|
||||
1. **Execute all actions** — Appliquer tous les changements
|
||||
2. **Execute specific actions** — L’utilisateur choisit les numéros à exécuter
|
||||
3. **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
|
||||
- **Nouveaux agents** : ajouter au tableau des agents officiels avec #, nom, modèle, outils et description corrects
|
||||
- **Agents supprimés** : confirmer avec l’utilisateur avant suppression
|
||||
|
||||
---
|
||||
|
||||
## Règles critiques
|
||||
|
||||
1. **Ne jamais deviner** les versions ou dates — utiliser les données de l’agent
|
||||
2. **Croiser les nombres de champs** — le nombre de champs du rapport doit correspondre à la documentation officielle
|
||||
3. **Croiser les nombres d’agents** — le nombre d’agents du rapport doit correspondre à la documentation officielle
|
||||
4. **Ne pas auto-exécuter** — toujours présenter le rapport d’abord
|
||||
5. **TOUJOURS ajouter au changelog** — la Phase 3.5 est obligatoire. Ne jamais la sauter. Ne jamais écraser les entrées précédentes.
|
||||
6. **TOUJOURS mettre à jour le badge Last Updated** — la Phase 3.6 est obligatoire. Ne jamais la sauter.
|
||||
7. **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.
|
||||
@@ -0,0 +1,232 @@
|
||||
---
|
||||
description: Mettre à jour la section README CONCEPTS avec les dernières fonctionnalités et concepts Claude Code
|
||||
argument-hint: [number of changelog versions to check, default 10]
|
||||
---
|
||||
|
||||
# Workflow Changelog — README Concepts
|
||||
|
||||
Tu es un coordinateur pour le projet claude-code-best-practice. Ta mission consiste à lancer deux agents de recherche en parallèle, attendre leurs résultats, fusionner les constats et présenter un rapport unifié sur la dérive de la **section README CONCEPTS** (`README.md`).
|
||||
|
||||
**Versions à vérifier :** `$ARGUMENTS` (par défaut : 10 si vide ou non numérique)
|
||||
|
||||
Il s’agit d’un workflow **lire puis rapporter**. Lance les agents, fusionne les résultats et produis un rapport. N’agis que si l’utilisateur approuve.
|
||||
|
||||
---
|
||||
|
||||
## Phase 0 : lancer les deux agents en parallèle
|
||||
|
||||
**Immédiatement**, lance les deux agents avec l’outil Task **dans le même message** (lancement parallèle) :
|
||||
|
||||
### Agent 1 : workflow-concepts-agent
|
||||
|
||||
Lance avec `subagent_type: "workflow-concepts-agent"`. Donne-lui ce prompt :
|
||||
|
||||
> Research the claude-code-best-practice project for README CONCEPTS section drift. Check the last $ARGUMENTS versions (default: 10).
|
||||
>
|
||||
> Fetch these 3 external sources:
|
||||
> 1. Claude Code Docs Index: https://code.claude.com/docs/en
|
||||
> 2. Claude Code Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
|
||||
> 3. Claude Code Features Overview: https://code.claude.com/docs/en/overview
|
||||
>
|
||||
> Then read the local README.md (specifically the CONCEPTS table), CLAUDE.md, and `reports/claude-global-vs-project-settings.md`. Analyze differences between what the official docs list as Claude Code concepts/features and what our README CONCEPTS table documents. Return a structured findings report covering missing concepts, changed concepts, deprecated concepts, URL accuracy, description accuracy, and badge accuracy.
|
||||
|
||||
### Agent 2 : claude-code-guide
|
||||
|
||||
Lance avec `subagent_type: "claude-code-guide"`. Donne-lui ce prompt :
|
||||
|
||||
> Research the latest Claude Code features and concepts. I need you to find the COMPLETE list of all Claude Code concepts/features that should be documented. For each, provide:
|
||||
> 1. Official feature name
|
||||
> 2. Official docs URL
|
||||
> 3. File system location (e.g., `.claude/commands/`, `~/.claude/teams/`)
|
||||
> 4. Brief description (one line)
|
||||
> 5. When it was introduced (version/date if known)
|
||||
>
|
||||
> Specifically check for these potentially missing concepts:
|
||||
> - **Worktrees** — git worktree isolation for parallel development
|
||||
> - **Agent Teams** — multi-agent coordination
|
||||
> - **Tasks** — persistent task lists across sessions
|
||||
> - **Auto Memory** — Claude's self-written project learnings
|
||||
> - **Keybindings** — custom keyboard shortcuts
|
||||
> - **Remote Connections** — SSH, Docker, cloud development
|
||||
> - **IDE Integration** — VS Code, JetBrains extensions
|
||||
> - **Model Configuration** — model selection and routing
|
||||
> - **GitHub Integration** — PR reviews, issue triage
|
||||
> - Any other concept from recent Claude Code versions
|
||||
>
|
||||
> Be thorough — search the web, fetch docs, and provide concrete version numbers and details for everything you find.
|
||||
|
||||
Les deux agents s’exécutent indépendamment et retourneront leurs constats.
|
||||
|
||||
---
|
||||
|
||||
## Phase 0.5 : lire la checklist de vérification
|
||||
|
||||
**Pendant que les agents s’exécutent**, lis `changelog/best-practice/concepts/verification-checklist.md` si le fichier existe. Ce fichier contient les règles de vérification accumulées. S’il n’existe pas encore, saute cette étape — il sera créé en Phase 2.
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 : lire les entrées précédentes du changelog
|
||||
|
||||
**Avant de fusionner les constats**, lis le fichier `changelog/best-practice/concepts/changelog.md` s’il existe, afin d’obtenir les entrées précédentes du changelog. Chaque entrée est séparée par `---`. Analyse les actions prioritaires des entrées précédentes pour pouvoir les comparer aux constats actuels. Cela permet d’identifier :
|
||||
- **Éléments récurrents** — problèmes déjà apparus et encore non résolus
|
||||
- **Éléments nouvellement résolus** — problèmes des exécutions précédentes désormais corrigés
|
||||
- **Nouveaux éléments** — problèmes apparaissant pour la première fois dans cette exécution
|
||||
|
||||
Si le fichier n’existe pas encore, tous les éléments sont `NEW`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 : fusionner les constats et générer le rapport
|
||||
|
||||
**Attends que les deux agents terminent.** Une fois que tu as :
|
||||
- **Constats de workflow-concepts-agent** — analyse détaillée avec lectures de fichiers locaux, récupérations de docs externes et détection de dérive
|
||||
- **Constats de claude-code-guide** — recherche indépendante sur les dernières fonctionnalités et concepts Claude Code
|
||||
|
||||
Croise les deux. L’agent dédié fournit l’analyse de dérive spécifique à CONCEPTS, tandis que claude-code-guide peut faire remonter des éléments qu’il a manqués (par exemple des changements très récents, des fonctionnalités non documentées ou du contexte issu de recherches web). Signale toute contradiction entre les deux pour résolution par l’utilisateur.
|
||||
|
||||
**Exécute la checklist de vérification (si elle existe) :** pour chaque règle dans `changelog/best-practice/concepts/verification-checklist.md`, effectue la vérification. Inclus une section **Verification Log** dans le rapport.
|
||||
|
||||
**Mets à jour la checklist si nécessaire :** si un constat révèle un nouveau type de dérive qu’aucune règle existante ne couvre, ajoute une nouvelle règle à `changelog/best-practice/concepts/verification-checklist.md`. Si le fichier n’existe pas, crée-le. La règle doit inclure : catégorie, quoi vérifier, niveau de profondeur, source de comparaison, date d’ajout et origine.
|
||||
|
||||
Compare aussi les constats actuels aux entrées précédentes du changelog (depuis la Phase 1). Pour chaque action prioritaire, marque-la comme :
|
||||
- `NEW` — première apparition du problème
|
||||
- `RECURRING` — déjà apparu lors d’une exécution précédente et encore non résolu (inclure la date de première apparition)
|
||||
- `RESOLVED` — apparu lors d’une exécution précédente mais désormais corrigé (inclure la date de résolution)
|
||||
|
||||
Produis un rapport structuré avec ces sections :
|
||||
|
||||
1. **Missing Concepts** — Fonctionnalités/concepts présents dans la documentation officielle mais absents du tableau CONCEPTS, avec :
|
||||
- Nom officiel et URL de documentation
|
||||
- Valeur recommandée pour la colonne Location
|
||||
- Valeur recommandée pour la colonne Description — **badges et liens complémentaires uniquement ; pas de descriptions en prose** (la colonne Description est conventionnellement une colonne de liens, pas un résumé de fonctionnalité)
|
||||
- Ligne de tableau markdown exacte prête à coller
|
||||
- Version d’introduction (si connue)
|
||||
2. **Changed Concepts** — Concepts dont le nom, l’URL, l’emplacement ou la description a changé
|
||||
3. **Deprecated/Removed Concepts** — Concepts du tableau CONCEPTS qui ne figurent plus dans la documentation officielle
|
||||
4. **URL Accuracy** — Vérification URL par concept
|
||||
5. **Description Accuracy** — Vérification description/emplacement par concept
|
||||
6. **Badge Accuracy** — Vérification des liens de badges et recommandations de badges manquants
|
||||
7. **claude-code-guide Agent Findings** — Informations uniques de l’agent non capturées par l’agent dédié. N’inclus que les constats qui ajoutent une nouvelle information. Signale les contradictions.
|
||||
|
||||
Termine par un tableau récapitulatif priorisé **Action Items** :
|
||||
|
||||
```text
|
||||
Priority Actions:
|
||||
# | Type | Action | Status
|
||||
1 | Missing Concept | Add <concept> row to CONCEPTS table | NEW
|
||||
2 | Changed URL | Update <concept> docs link | NEW
|
||||
3 | Changed Description | Update <concept> description | RECURRING (first seen: <date>)
|
||||
4 | Deprecated Concept | Remove <concept> row from CONCEPTS table | NEW
|
||||
5 | Broken Badge | Fix badge link for <concept> | NEW
|
||||
```
|
||||
|
||||
Inclus aussi une section **Resolved Since Last Run** listant les éléments de l’exécution précédente qui ne sont plus des problèmes.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.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/concepts/changelog.md` existant, puis **ajoute** (ne remplace PAS) une nouvelle entrée à la fin. Si le fichier n’existe pas, crée-le avec un tableau Status Legend puis la première entrée. Le format de l’entrée doit être exactement :
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## [<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ès
|
||||
- `INVALID (reason)` — le constat était incorrect, non applicable ou intentionnel
|
||||
- `ON 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
|
||||
- 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 2.6 : mettre à jour le badge Last Updated
|
||||
|
||||
**Cette phase est OBLIGATOIRE — exécute-la toujours immédiatement après la Phase 2.5, avant de présenter le rapport.**
|
||||
|
||||
Mets à jour le badge "Last Updated" en haut de `README.md` (ligne 3). 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.
|
||||
|
||||
**Ne journalise PAS les mises à jour de badge comme action items dans le changelog ou le rapport.**
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.7 : valider toutes les URLs CONCEPTS
|
||||
|
||||
**Cette phase est OBLIGATOIRE — exécute-la toujours après la Phase 2.6, avant de présenter le rapport.**
|
||||
|
||||
Pour chaque concept du tableau CONCEPTS :
|
||||
|
||||
1. **URLs de docs externes** (par exemple `https://code.claude.com/docs/en/skills`) : récupérer chaque URL avec WebFetch et vérifier qu’elle retourne une page valide. Signaler tout lien mort ou déplacé.
|
||||
2. **Liens de badges locaux** (par exemple `best-practice/claude-commands.md`) : vérifier que le fichier existe avec l’outil Read. Signaler tout lien cassé.
|
||||
3. **Liens de badges d’implémentation** (par exemple `.claude/commands/`) : vérifier que le chemin existe.
|
||||
|
||||
Inclus un **URL Validation Log** dans le rapport :
|
||||
|
||||
```text
|
||||
URL Validation Log:
|
||||
# | Concept | URL Type | URL | Status | Notes
|
||||
1 | Commands | External | https://code.claude.com/docs/en/skills | OK |
|
||||
2 | Commands | Badge | best-practice/claude-commands.md | OK |
|
||||
3 | Sub-Agents | External | https://code.claude.com/docs/en/sub-agents | OK |
|
||||
...
|
||||
```
|
||||
|
||||
**Si des URLs sont cassées**, ajoute-les comme action items de priorité HIGH.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 : proposer d’agir
|
||||
|
||||
Après avoir présenté le rapport (et confirmé que le changelog a été mis à jour), demande à l’utilisateur :
|
||||
|
||||
1. **Execute all actions** — Ajouter les concepts manquants, mettre à jour ceux qui ont changé, supprimer les dépréciés
|
||||
2. **Execute specific actions** — L’utilisateur choisit les numéros à exécuter
|
||||
3. **Just save the report** — Aucun changement
|
||||
|
||||
Pendant l’exécution :
|
||||
- **Concepts manquants** : ajouter une nouvelle ligne au tableau CONCEPTS dans `README.md` en suivant le format existant :
|
||||
```markdown
|
||||
| [**Name**](docs-url) | `location` | [](...) [](...) [Supplementary Link](...) |
|
||||
```
|
||||
La troisième colonne contient **badges et liens uniquement — jamais de prose**. Ajouter les badges (best-practice, implemented) seulement si les fichiers correspondants existent. Si aucun badge ou lien ne s’applique, laisser la cellule vide (simplement `| |`).
|
||||
- **Concepts modifiés** : mettre à jour les colonnes spécifiques qui ont changé
|
||||
- **Concepts dépréciés** : confirmer avec l’utilisateur avant de supprimer des lignes
|
||||
- **URLs cassées** : corriger l’URL vers la version valide actuelle
|
||||
- **Corrections de badges** : mettre à jour les liens de badges vers les bons chemins de fichiers
|
||||
- Maintenir l’ordre alphabétique ou logique cohérent avec le tableau existant
|
||||
- Après toutes les actions, revérifier la cohérence du tableau CONCEPTS
|
||||
|
||||
---
|
||||
|
||||
## Règles critiques
|
||||
|
||||
1. **Lancer les DEUX agents en parallèle** dans un seul message — jamais séquentiellement
|
||||
2. **Attendre les deux agents** avant de générer le rapport
|
||||
3. **Ne jamais deviner** versions, URLs ou dates — utiliser les données des agents
|
||||
4. **Les concepts manquants sont PRIORITAIRES** — le tableau CONCEPTS est la première chose que voient les développeurs
|
||||
5. **Vérifier chaque URL** — les liens cassés dégradent la confiance dans tout le projet
|
||||
6. **Ne pas auto-exécuter** — toujours présenter le rapport d’abord
|
||||
7. **TOUJOURS ajouter au changelog** — la Phase 2.5 est obligatoire. Ne jamais la sauter. Ne jamais écraser les entrées précédentes.
|
||||
8. **Comparer avec les exécutions précédentes** — lire les entrées précédentes du changelog et marquer chaque action item comme NEW, RECURRING ou RESOLVED.
|
||||
9. **Exécuter la checklist de vérification si elle existe** — lire verification-checklist.md et exécuter chaque règle. Créer le fichier s’il n’existe pas et que des constats justifient des règles persistantes.
|
||||
10. **TOUJOURS mettre à jour le badge Last Updated** — la Phase 2.6 est obligatoire.
|
||||
11. **TOUJOURS valider toutes les URLs CONCEPTS** — la Phase 2.7 est obligatoire. Les URLs cassées sont prioritaires HIGH.
|
||||
12. **Fournir des lignes prêtes à coller** — pour les concepts manquants, inclure la ligne markdown exacte afin que l’exécution soit copier-coller.
|
||||
13. **Respecter le format de tableau existant** — faire correspondre la structure de colonnes, le motif de badges et le style de liens des lignes existantes.
|
||||
14. **La colonne Description sert aux badges et liens uniquement** — jamais de prose. La troisième colonne du tableau CONCEPTS (y compris le sous-tableau Hot) contient badges (best-practice, implemented, beta) et liens complémentaires (docs, articles de blog, rapports liés). Ne jamais écrire une description en prose de ce que fait une fonctionnalité — le nom de fonctionnalité pointe vers la documentation officielle, où l’explication appartient. Si une ligne n’a ni badge ni lien, laisse la cellule vide.
|
||||
Reference in New Issue
Block a user