---
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.
