253 lines
15 KiB
Markdown
253 lines
15 KiB
Markdown
---
|
||
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.
|