traduction
This commit is contained in:
@@ -0,0 +1,158 @@
|
||||
---
|
||||
description: Mettre à jour le tableau AGENT COLLECTIONS en recherchant tous les dépôts de collections d’agents en parallèle
|
||||
---
|
||||
|
||||
# Workflow — Agent Collections
|
||||
|
||||
Mets à jour le tableau AGENT COLLECTIONS dans `README.md` en recherchant les dépôts listés en parallèle. Lance un agent de recherche, fusionne les résultats, présente les changements et mets le tableau à jour si approuvé.
|
||||
|
||||
---
|
||||
|
||||
## Les dépôts
|
||||
|
||||
| # | Repo | Owner |
|
||||
|---|------|-------|
|
||||
| 1 | `msitarzewski/agency-agents` | msitarzewski |
|
||||
| 2 | `VoltAgent/awesome-claude-code-subagents` | VoltAgent (curated awesome-list) |
|
||||
|
||||
> Lorsque de nouveaux dépôts de collections d’agents sont découverts, ajoute-les ici ET au prompt de recherche en Phase 1.
|
||||
|
||||
---
|
||||
|
||||
## Format du tableau
|
||||
|
||||
Le tableau README a ces colonnes :
|
||||
|
||||
```markdown
|
||||
| Name | ★ | <img src="!/tags/a.svg" height="14"> |
|
||||
```
|
||||
|
||||
- **Name** : `[Short Name](github-url)` — utilise le nom court reconnaissable du dépôt (par exemple `msitarzewski/agency-agents`, `awesome-claude-code-subagents`). Utilise le `owner/repo` complet uniquement si le nom seul est ambigu.
|
||||
- **★** : nombre d’étoiles arrondi en `k` (par exemple 92k, 19k, 1.2k). Sous 1000, affiche le nombre exact.
|
||||
- **Nombre d’agents** : seulement le nombre. Pour les awesome-lists où les agents sont des *liens* et non des fichiers, utilise la forme `N+ (curated list)`.
|
||||
|
||||
**Ordre de tri** : trié par étoiles décroissantes (le plus élevé d’abord).
|
||||
|
||||
---
|
||||
|
||||
## Phase 0 : lire l’état actuel
|
||||
|
||||
Lis ces fichiers :
|
||||
|
||||
1. `README.md` — le tableau `## 🤖 AGENT COLLECTIONS` (noter les étoiles et nombres d’agents actuels)
|
||||
2. `changelog/agent-collections/changelog.md` — entrées de changelog précédentes (peut ne pas encore exister — le créer à la première exécution)
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 : lancer l’agent de recherche
|
||||
|
||||
**Immédiatement**, lance un `development-workflows-research-agent` couvrant tous les dépôts. (L’agent de recherche existant est générique — il compte agents/skills/commandes/étoiles pour n’importe quel dépôt.)
|
||||
|
||||
> Research these Claude Code **agent-collection** repositories. Each is primarily a library of subagent definition files (`.md` files defining agents), NOT a full workflow methodology.
|
||||
>
|
||||
> **Repo 1: msitarzewski/agency-agents** (https://github.com/msitarzewski/agency-agents) — agency-style subagent collection
|
||||
> **Repo 2: VoltAgent/awesome-claude-code-subagents** (https://github.com/VoltAgent/awesome-claude-code-subagents) — curated awesome-list (links to external subagents, not all agents are stored as files in the repo)
|
||||
>
|
||||
> For EACH repo, return:
|
||||
>
|
||||
> 1. **Stars** — use GitHub API `https://api.github.com/repos/{owner}/{repo}`, read `stargazers_count`. Round to `k`.
|
||||
> 2. **Agent count** — count subagent definition `.md` files via the GitHub git tree API:
|
||||
> `https://api.github.com/repos/{owner}/{repo}/git/trees/HEAD?recursive=1` and grep paths under conventional agent directories.
|
||||
> - For `msitarzewski/agency-agents`: agents typically live under `agents/`, `.claude/agents/`, or category subdirectories. Count `.md` files that look like subagent definitions (frontmatter with `name:` and `description:`). Exclude README/CHANGELOG/LICENSE/docs.
|
||||
> - For `VoltAgent/awesome-claude-code-subagents`: count the *listed* agents in README.md (e.g., bullets / table rows linking to external repos). Mark explicitly as "curated list, not files in repo".
|
||||
> - If a repo has both a curated index AND its own agent files, report both numbers and explain.
|
||||
> 3. **Notable changes** — any significant additions or removals in the last 30 days?
|
||||
>
|
||||
> Return structured report per repo:
|
||||
> ```
|
||||
> REPO: msitarzewski/agency-agents
|
||||
> STARS: <number>k (<exact>)
|
||||
> AGENTS: <count> (<file pattern used, e.g., ".md files under agents/ via git tree">)
|
||||
> NOTES: <anything unusual — flat layout vs categorized, README-only catalog, deprecated agents, curated-list disclaimer>
|
||||
> CHANGES: <changes or "No significant changes">
|
||||
> CONFIDENCE: <0-1>
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 : comparer et rapporter
|
||||
|
||||
**Attends l’agent.** Compare ensuite les constats avec le tableau actuel et présente :
|
||||
|
||||
```text
|
||||
Agent Collections — Update Report
|
||||
══════════════════════════════════
|
||||
|
||||
Changes Found:
|
||||
<repo>: ★ <old>k → <new>k | agents <old>→<new>
|
||||
...
|
||||
|
||||
No Changes:
|
||||
<repo>: ✓ (all values match)
|
||||
...
|
||||
|
||||
Action Items:
|
||||
# | Type | Action | Status
|
||||
1 | Star | Update <repo> ★ from Xk to Yk | NEW/RECURRING
|
||||
2 | Count | Update <repo> agents from X to Y | NEW/RECURRING
|
||||
3 | Sort | Move <repo> (rank changed) | NEW/RECURRING
|
||||
4 | Add | New collection candidate: <repo> | NEW
|
||||
```
|
||||
|
||||
Compare avec les entrées précédentes du changelog et marque les éléments `NEW`, `RECURRING` ou `RESOLVED`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.5 : ajouter au changelog
|
||||
|
||||
**OBLIGATOIRE** — toujours exécuter avant de présenter à l’utilisateur.
|
||||
|
||||
Lis `changelog/agent-collections/changelog.md`, puis **ajoute** une nouvelle entrée. Si le fichier n’existe pas, crée-le avec une Status Legend puis la première entrée.
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## [<YYYY-MM-DD HH:MM AM/PM PKT>] Agent Collections Update
|
||||
|
||||
| # | Priority | Type | Action | Status |
|
||||
|---|----------|------|--------|--------|
|
||||
| 1 | HIGH/MED/LOW | <type> | <action> | <status> |
|
||||
```
|
||||
|
||||
Obtiens l’heure via `TZ=Asia/Karachi date "+%Y-%m-%d %I:%M %p PKT"`. Le statut doit être l’un de :
|
||||
- `COMPLETE (reason)` | `INVALID (reason)` | `ON HOLD (reason)`
|
||||
|
||||
Toujours ajouter, ne jamais écraser.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.6 : mettre à jour le badge Last Updated
|
||||
|
||||
**OBLIGATOIRE** — exécuter après la Phase 2.5.
|
||||
|
||||
Mets à jour le badge de la ligne 4 de `README.md`. Obtiens l’heure via `TZ=Asia/Karachi date "+%b %d, %Y %-I:%M %p PKT"`, encode-la pour URL et remplace la date dans le badge. Ne journalise PAS cela comme action item.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 : exécuter
|
||||
|
||||
Demande à l’utilisateur : **(1) Execute all** | **(2) Execute specific** | **(3) Skip**
|
||||
|
||||
Pendant l’exécution, modifie le tableau `## 🤖 AGENT COLLECTIONS` dans `README.md` :
|
||||
- Mettre à jour les étoiles et nombres d’agents par ligne
|
||||
- Maintenir l’ordre de tri : étoiles décroissantes (le plus élevé d’abord)
|
||||
- Respecter exactement le format existant (style des liens, suffixe k sur les étoiles)
|
||||
|
||||
---
|
||||
|
||||
## Règles
|
||||
|
||||
1. **Un agent de recherche, tous les dépôts** — message unique, sous-récupérations parallèles à l’intérieur
|
||||
2. **Ne jamais deviner** — utiliser uniquement les données de l’agent
|
||||
3. **Ne pas auto-exécuter** — présenter le rapport d’abord, attendre approbation
|
||||
4. **TOUJOURS ajouter au changelog** et **TOUJOURS mettre à jour le badge** — obligatoire
|
||||
5. **Trier par étoiles décroissantes** — plus grand nombre d’étoiles d’abord
|
||||
6. **Arrondir les étoiles de façon cohérente** — suffixe `k` (92k, 19k, 1.2k). Sous 1000, afficher le nombre exact
|
||||
7. **Les awesome-lists sont différentes** — pour les dépôts qui lient vers des agents externes (VoltAgent), le nombre est "items listed in README", pas les fichiers du dépôt ; toujours annoter `(curated list)`
|
||||
8. **Comparer avec le changelog précédent** — marquer les éléments NEW, RECURRING ou RESOLVED
|
||||
9. **Réutiliser `development-workflows-research-agent`** — ne PAS créer de nouvel agent
|
||||
@@ -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.
|
||||
@@ -0,0 +1,252 @@
|
||||
---
|
||||
description: Mettre à jour le tableau DEVELOPMENT WORKFLOWS en recherchant les 11 dépôts de workflows en parallèle
|
||||
---
|
||||
|
||||
# Workflow — Development Workflows
|
||||
|
||||
Mets à jour le tableau DEVELOPMENT WORKFLOWS dans `README.md` en recherchant 11 dépôts en parallèle. Lance des agents, fusionne les résultats, présente les changements et mets le tableau à jour si approuvé.
|
||||
|
||||
---
|
||||
|
||||
## Les 11 dépôts
|
||||
|
||||
| # | Repo | Owner |
|
||||
|---|------|-------|
|
||||
| 1 | `github/spec-kit` | GitHub (John Lam / Den Delimarsky) |
|
||||
| 2 | `Fission-AI/OpenSpec` | Fission-AI (@0xTab) |
|
||||
| 3 | `humanlayer/humanlayer` | HumanLayer (Dex Horthy) |
|
||||
| 4 | `affaan-m/everything-claude-code` | Affaan Mustafa |
|
||||
| 5 | `gsd-build/get-shit-done` | Lex Christopherson |
|
||||
| 6 | `obra/superpowers` | Jesse Vincent |
|
||||
| 7 | `garrytan/gstack` | Garry Tan (YC CEO) |
|
||||
| 8 | `bmad-code-org/BMAD-METHOD` | BMAD Code Org |
|
||||
| 9 | `EveryInc/compound-engineering-plugin` | Every.to |
|
||||
| 10 | `Yeachan-Heo/oh-my-claudecode` | Yeachan Heo (@bellman_ych) |
|
||||
| 11 | `mattpocock/skills` | Matt Pocock |
|
||||
|
||||
---
|
||||
|
||||
## Format du tableau
|
||||
|
||||
Le tableau README a ces colonnes :
|
||||
|
||||
```markdown
|
||||
| Name | ★ | Workflow | <img src="!/tags/a.svg" height="14"> | <img src="!/tags/c.svg" height="14"> | <img src="!/tags/s.svg" height="14"> |
|
||||
```
|
||||
|
||||
- **Name** : `[Short Name](github-url)` — utiliser le nom du projet, pas owner/repo
|
||||
- **★** : nombre d’étoiles arrondi en `k` (par exemple 98k, 10k, 4.1k). Sous 1000, afficher le nombre exact
|
||||
- **Workflow** : pipeline canonique de bout en bout sous forme de séquence plate gauche→droite de badges shields.io joints par ` → `. Chaque étape est le vrai nom de commande/skill/agent du dépôt (par exemple `/speckit.plan`, `bmad-create-prd`, `subagent-driven-development`). **Plat uniquement** — pas de parenthèses, pas de qualificatifs anglais ("loop", "per story", "parallel waves"), pas de connecteurs `+`. Si une étape a des sous-étapes internes importantes, liste-les comme sœurs dans la chaîne principale et **colore-les en jaune (`fff3b0`)** pour marquer les sous-boucles ; les étapes de niveau supérieur restent bleu clair (`ddf4ff`). Suis la section "how to use" / "workflow" du README pour le happy path canonique : idée → spec/plan → tasks → implement → review → ship.
|
||||
- **Comptes Agent/Command/Skill** : seulement le nombre (par exemple `25`, `0`, `108+`)
|
||||
|
||||
### Encodage des badges de workflow (shields.io)
|
||||
|
||||
Chaque étape s’affiche comme une **balise HTML `<img>` avec `align="middle"`** (pas la syntaxe image markdown), afin que la flèche reste verticalement centrée avec les badges. Deux couleurs de fond :
|
||||
|
||||
| Couleur | Hex | Quand l’utiliser |
|
||||
|---|---|---|
|
||||
| Bleu clair | `ddf4ff` | Étapes de workflow de niveau supérieur |
|
||||
| Jaune doux | `fff3b0` | Sous-boucles (répétées par tâche/story/jusqu’à vérification dans une étape parente) |
|
||||
|
||||
Template :
|
||||
|
||||
```html
|
||||
<img src="https://img.shields.io/badge/<ENCODED>-ddf4ff" alt="<plain-label>" align="middle"> <!-- top-level -->
|
||||
<img src="https://img.shields.io/badge/<ENCODED>-fff3b0" alt="<plain-label>" align="middle"> <!-- sub-loop -->
|
||||
```
|
||||
|
||||
Le `align="middle"` place le centre vertical du badge sur la baseline du texte, donc la flèche ` → ` finit centrée sur chaque badge au lieu de descendre vers le bas du badge. Sans lui, la flèche apparaît visiblement plus basse que les badges dans le rendu GitHub.
|
||||
|
||||
Après la fermeture du tableau, **inclure toujours cette légende** comme blockquote sur sa propre ligne :
|
||||
|
||||
```markdown
|
||||
> *Note: yellow tags are sub-loops — steps that repeat inside a parent step (e.g. per task, per story, or until a verify condition passes).*
|
||||
```
|
||||
|
||||
Règles d’encodage pour la portion `<ENCODED>` de l’URL :
|
||||
|
||||
| Caractère d’entrée | Encodé en |
|
||||
|---|---|
|
||||
| `/` (slash initial) | `%2F` |
|
||||
| `-` (tiret littéral) | `--` |
|
||||
| `_` (underscore littéral) | `__` |
|
||||
| ` ` (espace) | `_` |
|
||||
| `+` | `%2B` |
|
||||
| `.` et `:` | inchangés |
|
||||
|
||||
Exemples :
|
||||
- `/grill-me` → `%2Fgrill--me`
|
||||
- `/speckit.plan` → `%2Fspeckit.plan`
|
||||
- `/opsx:propose` → `%2Fopsx:propose`
|
||||
- `bmad-create-epics-and-stories` → `bmad--create--epics--and--stories`
|
||||
|
||||
Joins les étapes avec la flèche littérale ` → ` (espace-flèche-espace) **entre** le `>` fermant d’une balise img et le `<` ouvrant de la suivante.
|
||||
|
||||
**Ne pas** envelopper les sous-étapes dans des parenthèses ni les annoter en anglais ("loop", "per story", "+", "parallel waves"). Si une étape a une boucle interne, liste simplement les noms des étapes internes comme sœurs dans la chaîne plate.
|
||||
|
||||
**Ordre de tri** : trié par étoiles décroissantes (le plus élevé d’abord).
|
||||
|
||||
---
|
||||
|
||||
## Phase 0 : lire l’état actuel
|
||||
|
||||
Lis ces fichiers :
|
||||
|
||||
1. `README.md` — le tableau `## ⚙️ DEVELOPMENT WORKFLOWS` (noter étoiles actuelles, pipelines de workflow, comptes)
|
||||
2. `changelog/development-workflows/changelog.md` — entrées précédentes du changelog
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 : lancer 2 agents de recherche
|
||||
|
||||
**Immédiatement**, lance les deux agents dans un **seul message** (en parallèle). Chacun utilise `subagent_type: "development-workflows-research-agent"`.
|
||||
|
||||
### Agent 1 (4 dépôts)
|
||||
|
||||
> Research these 4 Claude Code workflow repositories:
|
||||
>
|
||||
> **Repo 1: github/spec-kit** (https://github.com/github/spec-kit)
|
||||
> **Repo 2: affaan-m/everything-claude-code** (https://github.com/affaan-m/everything-claude-code)
|
||||
> **Repo 3: obra/superpowers** (https://github.com/obra/superpowers)
|
||||
> **Repo 4: mattpocock/skills** (https://github.com/mattpocock/skills)
|
||||
>
|
||||
> For EACH repo, return:
|
||||
>
|
||||
> 1. **Stars** — use GitHub API `https://api.github.com/repos/{owner}/{repo}`, read `stargazers_count`. Round to `k`.
|
||||
> 2. **Agent count** — count `.md` files in `agents/` or `.claude/agents/`. For obra, also count implicit sub-agents dispatched by skills. For mattpocock, count is 0 (skills-only repo).
|
||||
> 3. **Skill count** — count folders in `skills/` or `.claude/skills/`. For mattpocock, count folders in `skills/` at repo root.
|
||||
> 4. **Command count** — count `.md` files in `commands/` or `.claude/commands/`. For spec-kit, count files in `templates/commands/`. For mattpocock, count is 0 (skills serve as slash commands).
|
||||
> 5. **Workflow** — the canonical end-to-end pipeline as a flat left-to-right sequence of step names joined by ` → `. Trace the README's "how to use" / "workflow" section for the happy path: idea → spec/plan → tasks → implement → review → ship. Use the actual command/skill/agent names from the repo. **Flat only** — no parentheses, no English qualifiers ("loop", "per story", "parallel waves"), no `+` connectors. If a step has internal sub-steps, list them as siblings in the main chain. Mark each step as either `top` (top-level) or `sub` (sub-loop, repeats inside a parent step) so the orchestrator can color it. Output as plain text — the orchestrator will encode each step into a shields.io HTML img badge.
|
||||
> 6. **Notable changes** — any significant recent changes? New agents/skills/commands, major versions?
|
||||
>
|
||||
> Return structured report per repo:
|
||||
> ```
|
||||
> REPO: github/spec-kit
|
||||
> STARS: <number>k
|
||||
> AGENTS: <count>
|
||||
> COMMANDS: <count>
|
||||
> SKILLS: <count>
|
||||
> WORKFLOW: <step1>(top) → <step2>(top) → <step3>(sub) → ... → <stepN>(top)
|
||||
> CHANGES: <changes or "No significant changes">
|
||||
> ```
|
||||
|
||||
### Agent 2 (7 dépôts)
|
||||
|
||||
> Research these 7 Claude Code workflow repositories:
|
||||
>
|
||||
> **Repo 1: Fission-AI/OpenSpec** (https://github.com/Fission-AI/OpenSpec)
|
||||
> **Repo 2: humanlayer/humanlayer** (https://github.com/humanlayer/humanlayer)
|
||||
> **Repo 3: gsd-build/get-shit-done** (https://github.com/gsd-build/get-shit-done)
|
||||
> **Repo 4: garrytan/gstack** (https://github.com/garrytan/gstack)
|
||||
> **Repo 5: bmad-code-org/BMAD-METHOD** (https://github.com/bmad-code-org/BMAD-METHOD)
|
||||
> **Repo 6: EveryInc/compound-engineering-plugin** (https://github.com/EveryInc/compound-engineering-plugin)
|
||||
> **Repo 7: Yeachan-Heo/oh-my-claudecode** (https://github.com/Yeachan-Heo/oh-my-claudecode)
|
||||
>
|
||||
> For EACH repo, return:
|
||||
>
|
||||
> 1. **Stars** — use GitHub API `https://api.github.com/repos/{owner}/{repo}`, read `stargazers_count`. Round to `k`.
|
||||
> 2. **Agent count** — count `.md` files in `agents/` or `.claude/agents/`. For BMAD, count agent-persona skills in `src/bmm-skills/`. For compound-engineering-plugin, count `.md` files across all subdirectories of `plugins/compound-engineering/agents/`. For oh-my-claudecode, count `.md` files in `agents/` at repo root.
|
||||
> 3. **Skill count** — count folders in `skills/` or `.claude/skills/`. For gstack, skills are root-level directories with SKILL.md. For BMAD, count all skills in `src/bmm-skills/` and `src/core-skills/`. For compound-engineering-plugin, count folders in `plugins/compound-engineering/skills/` plus `plugins/coding-tutor/skills/`. For oh-my-claudecode, count folders in `skills/` at repo root.
|
||||
> 4. **Command count** — count `.md` files in `commands/` or `.claude/commands/`. For GSD, count in `commands/gsd/`. For OpenSpec, count `/opsx:*` commands. For BMAD, count is 0 (commands generated at install time). For compound-engineering-plugin, count `.md` files in `.claude/commands/` plus `plugins/coding-tutor/commands/`. For oh-my-claudecode, count is 0 (skills serve as slash commands).
|
||||
> 5. **Workflow** — the canonical end-to-end pipeline as a flat left-to-right sequence of step names joined by ` → `. Trace the README's "how to use" / "workflow" section for the happy path: idea → spec/plan → tasks → implement → review → ship. Use the actual command/skill/agent names from the repo. **Flat only** — no parentheses, no English qualifiers ("loop", "per story", "parallel waves"), no `+` connectors. If a step has internal sub-steps, list them as siblings in the main chain. Mark each step as either `top` (top-level) or `sub` (sub-loop, repeats inside a parent step) so the orchestrator can color it. Output as plain text — the orchestrator will encode each step into a shields.io HTML img badge.
|
||||
> 6. **Notable changes** — any significant recent changes? New agents/skills/commands, major versions?
|
||||
>
|
||||
> Return structured report per repo:
|
||||
> ```
|
||||
> REPO: Fission-AI/OpenSpec
|
||||
> STARS: <number>k
|
||||
> AGENTS: <count>
|
||||
> COMMANDS: <count>
|
||||
> SKILLS: <count>
|
||||
> WORKFLOW: <step1>(top) → <step2>(top) → <step3>(sub) → ... → <stepN>(top)
|
||||
> CHANGES: <changes or "No significant changes">
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 : comparer et rapporter
|
||||
|
||||
**Attends les deux agents.** Compare ensuite leurs constats avec le tableau actuel et présente :
|
||||
|
||||
```text
|
||||
Development Workflows — Update Report
|
||||
══════════════════════════════════════
|
||||
|
||||
Changes Found:
|
||||
<repo>: ★ <old>k → <new>k | agents <old>→<new> | commands <old>→<new> | skills <old>→<new>
|
||||
<repo>: workflow updated: <old workflow> → <new workflow>
|
||||
...
|
||||
|
||||
No Changes:
|
||||
<repo>: ✓ (all values match)
|
||||
...
|
||||
|
||||
Action Items:
|
||||
# | Type | Action | Status
|
||||
1 | Star | Update <repo> ★ from Xk to Yk | NEW/RECURRING
|
||||
2 | Count | Update <repo> agents from X to Y | NEW/RECURRING
|
||||
3 | Workflow | Update <repo> workflow pipeline | NEW/RECURRING
|
||||
4 | Sort | Move <repo> (stars changed) | NEW/RECURRING
|
||||
```
|
||||
|
||||
Compare avec les entrées précédentes du changelog et marque les éléments comme `NEW`, `RECURRING` ou `RESOLVED`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.5 : ajouter au changelog
|
||||
|
||||
**OBLIGATOIRE** — toujours exécuter avant de présenter à l’utilisateur.
|
||||
|
||||
Lis `changelog/development-workflows/changelog.md`, puis **ajoute** une nouvelle entrée. Si le fichier n’existe pas, crée-le avec une Status Legend puis la première entrée.
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## [<YYYY-MM-DD HH:MM AM/PM PKT>] Development Workflows Update
|
||||
|
||||
| # | Priority | Type | Action | Status |
|
||||
|---|----------|------|--------|--------|
|
||||
| 1 | HIGH/MED/LOW | <type> | <action> | <status> |
|
||||
```
|
||||
|
||||
Obtiens l’heure via `TZ=Asia/Karachi date "+%Y-%m-%d %I:%M %p PKT"`. Le statut doit être l’un de :
|
||||
- `COMPLETE (reason)` | `INVALID (reason)` | `ON HOLD (reason)`
|
||||
|
||||
Toujours ajouter, ne jamais écraser.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.6 : mettre à jour le badge Last Updated
|
||||
|
||||
**OBLIGATOIRE** — exécuter après la Phase 2.5.
|
||||
|
||||
Mets à jour le badge de la ligne 4 de `README.md`. Obtiens l’heure via `TZ=Asia/Karachi date "+%b %d, %Y %-I:%M %p PKT"`, encode-la pour URL et remplace la date dans le badge. Ne journalise PAS cela comme action item.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 : exécuter
|
||||
|
||||
Demande à l’utilisateur : **(1) Execute all** | **(2) Execute specific** | **(3) Skip**
|
||||
|
||||
Pendant l’exécution, modifie le tableau `## ⚙️ DEVELOPMENT WORKFLOWS` dans `README.md` :
|
||||
- Mettre à jour les étoiles, les comptes, **et la colonne Workflow** pour chaque ligne
|
||||
- Maintenir l’ordre de tri : étoiles décroissantes (le plus élevé d’abord)
|
||||
- Respecter exactement le format existant (icônes, URLs de badges, style des liens)
|
||||
- Pour la colonne Workflow, encoder chaque étape texte retournée par l’agent dans un badge HTML img shields.io selon la section Table Format. Utiliser `ddf4ff` pour les étapes marquées `(top)` et `fff3b0` pour les étapes marquées `(sub)`. Joindre avec ` → `.
|
||||
- Vérifier que la légende `> *Note: yellow tags are sub-loops — steps that repeat inside a parent step (e.g. per task, per story, or until a verify condition passes).*` est présente immédiatement après le tableau ; l’ajouter si elle manque.
|
||||
|
||||
---
|
||||
|
||||
## Règles
|
||||
|
||||
1. **Lancer les DEUX agents en parallèle** — message unique, jamais séquentiel
|
||||
2. **Ne jamais deviner** — utiliser uniquement les données des agents
|
||||
3. **Ne pas auto-exécuter** — présenter le rapport d’abord, attendre l’approbation
|
||||
4. **TOUJOURS ajouter au changelog** et **TOUJOURS mettre à jour le badge** — obligatoire
|
||||
5. **Trier par étoiles décroissantes** — plus grand nombre d’étoiles d’abord
|
||||
6. **Les badges de workflow utilisent HTML img avec align="middle"** — `<img src="https://img.shields.io/badge/<ENCODED>-<COLOR>" alt="<plain-label>" align="middle">`. Le `align="middle"` est requis pour que la flèche ` → ` reste verticalement centrée avec les badges. Deux couleurs : `ddf4ff` pour les étapes de niveau supérieur, `fff3b0` pour les sous-boucles. Encodage : `_` pour les espaces, `--` pour les tirets, `__` pour les underscores, `%2F` pour `/`, `%2B` pour `+`. Les points et deux-points restent tels quels. Joindre les étapes avec ` → `. Toujours mettre à jour la colonne Workflow quand un nom d’étape change dans le dépôt amont.
|
||||
7. **Agents, commandes et skills sont différents** — compter depuis leurs répertoires respectifs, ne pas les confondre
|
||||
8. **Arrondir les étoiles de façon cohérente** — suffixe `k` (98k, 10k, 4.1k). Sous 1000, afficher le nombre exact
|
||||
9. **Comparer avec le changelog précédent** — marquer les éléments NEW, RECURRING ou RESOLVED
|
||||
10. **La colonne Workflow est obligatoire et plate** — chaque ligne doit avoir une cellule Workflow. Suivre le "how to use" / happy path canonique du README ; ne pas inventer un pipeline fictif. **Pas de parenthèses, pas de qualificatifs anglais, pas de connecteurs `+`** — si une étape a des sous-étapes internes, les lister comme sœurs dans la chaîne plate et les colorer en jaune (`fff3b0`) ; les étapes de niveau supérieur restent bleues (`ddf4ff`).
|
||||
11. **La légende de sous-boucles est obligatoire** — immédiatement après le tableau, la ligne `> *Note: yellow tags are sub-loops — steps that repeat inside a parent step (e.g. per task, per story, or until a verify condition passes).*` doit être présente. La rétablir si elle a été retirée ; ne jamais modifier sa formulation.
|
||||
@@ -0,0 +1,164 @@
|
||||
---
|
||||
description: Mettre à jour le tableau SKILL COLLECTIONS en recherchant les 5 dépôts de collections de skills en parallèle
|
||||
---
|
||||
|
||||
# Workflow — Skill Collections
|
||||
|
||||
Mets à jour le tableau SKILL COLLECTIONS dans `README.md` en recherchant 5 dépôts en parallèle. Lance un agent de recherche, fusionne les résultats, présente les changements et mets le tableau à jour si approuvé.
|
||||
|
||||
---
|
||||
|
||||
## Les 5 dépôts
|
||||
|
||||
| # | Repo | Owner |
|
||||
|---|------|-------|
|
||||
| 1 | `anthropics/skills` | Anthropic (official) |
|
||||
| 2 | `wshobson/agents` | William Shobson |
|
||||
| 3 | `mattpocock/skills` | Matt Pocock |
|
||||
| 4 | `K-Dense-AI/scientific-agent-skills` | K-Dense-AI |
|
||||
| 5 | `VoltAgent/awesome-agent-skills` | VoltAgent (curated awesome-list) |
|
||||
|
||||
---
|
||||
|
||||
## Format du tableau
|
||||
|
||||
Le tableau README a ces colonnes :
|
||||
|
||||
```markdown
|
||||
| Name | ★ | <img src="!/tags/s.svg" height="14"> |
|
||||
```
|
||||
|
||||
- **Name** : `[Short Name](github-url)` — utilise le nom court du dépôt (par exemple `mattpocock/skills`, ou seulement `skills` si le propriétaire est le projet), pas le `owner/repo` complet sauf ambiguïté
|
||||
- **★** : nombre d’étoiles arrondi en `k` (par exemple 125k, 35k, 1.2k). Sous 1000, afficher le nombre exact
|
||||
- **Nombre de skills** : seulement le nombre. Pour les awesome-lists où les skills sont des *liens* et non des fichiers, utilise la forme `N+ (curated list)`
|
||||
|
||||
**Ordre de tri** : trié par étoiles décroissantes (le plus élevé d’abord).
|
||||
|
||||
---
|
||||
|
||||
## Phase 0 : lire l’état actuel
|
||||
|
||||
Lis ces fichiers :
|
||||
|
||||
1. `README.md` — le tableau `## 🧰 SKILL COLLECTIONS` (noter les étoiles et nombres de skills actuels)
|
||||
2. `changelog/skill-collections/changelog.md` — entrées de changelog précédentes (peut ne pas encore exister)
|
||||
|
||||
---
|
||||
|
||||
## Phase 1 : lancer l’agent de recherche
|
||||
|
||||
**Immédiatement**, lance un `development-workflows-research-agent` couvrant les 5 dépôts. (L’agent de recherche existant est générique — il compte skills/étoiles/etc. pour n’importe quel dépôt.)
|
||||
|
||||
> Research these 5 Claude Code **skill-collection** repositories. Each is primarily a library of `SKILL.md` files, NOT a full workflow methodology.
|
||||
>
|
||||
> **Repo 1: anthropics/skills** (https://github.com/anthropics/skills) — official Anthropic skills repo
|
||||
> **Repo 2: wshobson/agents** (https://github.com/wshobson/agents) — plugin-scoped skills (skills nested under domain plugins)
|
||||
> **Repo 3: mattpocock/skills** (https://github.com/mattpocock/skills) — TypeScript-focused
|
||||
> **Repo 4: K-Dense-AI/scientific-agent-skills** (https://github.com/K-Dense-AI/scientific-agent-skills) — science/research vertical
|
||||
> **Repo 5: VoltAgent/awesome-agent-skills** (https://github.com/VoltAgent/awesome-agent-skills) — curated awesome-list (links to external skills, not SKILL.md files in repo)
|
||||
>
|
||||
> For EACH repo, return:
|
||||
>
|
||||
> 1. **Stars** — use GitHub API `https://api.github.com/repos/{owner}/{repo}`, read `stargazers_count`. Round to `k`.
|
||||
> 2. **Skill count** — count `SKILL.md` files in the repo via the GitHub git tree API:
|
||||
> `https://api.github.com/repos/{owner}/{repo}/git/trees/HEAD?recursive=1` and grep paths for `SKILL.md`.
|
||||
> - For `wshobson/agents`: skills are nested inside `plugins/<domain>/skills/` — count all SKILL.md across all plugins.
|
||||
> - For `VoltAgent/awesome-agent-skills`: count the *listed* skills in README.md (e.g., bullets / table rows). Mark explicitly as "curated list, not files".
|
||||
> - For `K-Dense-AI/scientific-agent-skills`: subdirectories under `skills/` may use SKILL.md or `.md`; count whichever the repo uses, and report which.
|
||||
> - For `anthropics/skills`: skills live in subdirectories under `skills/` with `SKILL.md` inside.
|
||||
> - For `mattpocock/skills`: include only **active** skills, not deprecated ones (note both numbers if obvious).
|
||||
> 3. **Notable changes** — any significant additions or removals in last 30 days?
|
||||
>
|
||||
> Return structured report per repo:
|
||||
> ```
|
||||
> REPO: anthropics/skills
|
||||
> STARS: <number>k (<exact>)
|
||||
> SKILLS: <count> (<file pattern used, e.g., "SKILL.md files via git tree">)
|
||||
> NOTES: <anything unusual — flat .md vs SKILL.md, deprecated skills, language variants, curated-list disclaimer>
|
||||
> CHANGES: <changes or "No significant changes">
|
||||
> CONFIDENCE: <0-1>
|
||||
> ```
|
||||
|
||||
---
|
||||
|
||||
## Phase 2 : comparer et rapporter
|
||||
|
||||
**Attends l’agent.** Compare ensuite les constats avec le tableau actuel et présente :
|
||||
|
||||
```text
|
||||
Skill Collections — Update Report
|
||||
══════════════════════════════════
|
||||
|
||||
Changes Found:
|
||||
<repo>: ★ <old>k → <new>k | skills <old>→<new>
|
||||
...
|
||||
|
||||
No Changes:
|
||||
<repo>: ✓ (all values match)
|
||||
...
|
||||
|
||||
Action Items:
|
||||
# | Type | Action | Status
|
||||
1 | Star | Update <repo> ★ from Xk to Yk | NEW/RECURRING
|
||||
2 | Count | Update <repo> skills from X to Y | NEW/RECURRING
|
||||
3 | Sort | Move <repo> (rank changed) | NEW/RECURRING
|
||||
4 | Add | New collection candidate: <repo> | NEW
|
||||
```
|
||||
|
||||
Compare avec les entrées précédentes du changelog et marque les éléments `NEW`, `RECURRING` ou `RESOLVED`.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.5 : ajouter au changelog
|
||||
|
||||
**OBLIGATOIRE** — toujours exécuter avant de présenter à l’utilisateur.
|
||||
|
||||
Lis `changelog/skill-collections/changelog.md`, puis **ajoute** une nouvelle entrée. Si le fichier n’existe pas, crée-le avec une Status Legend puis la première entrée.
|
||||
|
||||
```markdown
|
||||
---
|
||||
|
||||
## [<YYYY-MM-DD HH:MM AM/PM PKT>] Skill Collections Update
|
||||
|
||||
| # | Priority | Type | Action | Status |
|
||||
|---|----------|------|--------|--------|
|
||||
| 1 | HIGH/MED/LOW | <type> | <action> | <status> |
|
||||
```
|
||||
|
||||
Obtiens l’heure via `TZ=Asia/Karachi date "+%Y-%m-%d %I:%M %p PKT"`. Le statut doit être l’un de :
|
||||
- `COMPLETE (reason)` | `INVALID (reason)` | `ON HOLD (reason)`
|
||||
|
||||
Toujours ajouter, ne jamais écraser.
|
||||
|
||||
---
|
||||
|
||||
## Phase 2.6 : mettre à jour le badge Last Updated
|
||||
|
||||
**OBLIGATOIRE** — exécuter après la Phase 2.5.
|
||||
|
||||
Mets à jour le badge de la ligne 4 de `README.md`. Obtiens l’heure via `TZ=Asia/Karachi date "+%b %d, %Y %-I:%M %p PKT"`, encode-la pour URL et remplace la date dans le badge. Ne journalise PAS cela comme action item.
|
||||
|
||||
---
|
||||
|
||||
## Phase 3 : exécuter
|
||||
|
||||
Demande à l’utilisateur : **(1) Execute all** | **(2) Execute specific** | **(3) Skip**
|
||||
|
||||
Pendant l’exécution, modifie le tableau `## 🧰 SKILL COLLECTIONS` dans `README.md` :
|
||||
- Mettre à jour les étoiles et nombres de skills par ligne
|
||||
- Maintenir l’ordre de tri : étoiles décroissantes (le plus élevé d’abord)
|
||||
- Respecter exactement le format existant (style des liens, suffixe k sur les étoiles)
|
||||
|
||||
---
|
||||
|
||||
## Règles
|
||||
|
||||
1. **Un agent de recherche, 5 dépôts** — message unique, sous-récupérations parallèles à l’intérieur
|
||||
2. **Ne jamais deviner** — utiliser uniquement les données de l’agent
|
||||
3. **Ne pas auto-exécuter** — présenter le rapport d’abord, attendre approbation
|
||||
4. **TOUJOURS ajouter au changelog** et **TOUJOURS mettre à jour le badge** — obligatoire
|
||||
5. **Trier par étoiles décroissantes** — plus grand nombre d’étoiles d’abord
|
||||
6. **Arrondir les étoiles de façon cohérente** — suffixe `k` (125k, 35k, 1.2k). Sous 1000, afficher le nombre exact
|
||||
7. **Les awesome-lists sont différentes** — pour les dépôts qui lient vers des skills externes (VoltAgent), le nombre est "items listed in README", pas les fichiers du dépôt ; toujours annoter `(curated list)`
|
||||
8. **Comparer avec le changelog précédent** — marquer les éléments NEW, RECURRING ou RESOLVED
|
||||
9. **Réutiliser `development-workflows-research-agent`** — ne PAS créer de nouvel agent
|
||||
Reference in New Issue
Block a user