Files

T

2026-06-02 23:24:21 +02:00

15 KiB

Raw Blame History

description

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 :

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

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

> *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 :

README.md — le tableau ## ⚙️ DEVELOPMENT WORKFLOWS (noter étoiles actuelles, pipelines de workflow, comptes)
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:

Stars — use GitHub API https://api.github.com/repos/{owner}/{repo}, read stargazers_count. Round to k.

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

Skill count — count folders in skills/ or .claude/skills/. For mattpocock, count folders in skills/ at repo root.

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

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.

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:

Stars — use GitHub API https://api.github.com/repos/{owner}/{repo}, read stargazers_count. Round to k.

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.

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.

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

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.

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 :

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.

---

## [<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

Lancer les DEUX agents en parallèle — message unique, jamais séquentiel
Ne jamais deviner — utiliser uniquement les données des agents
Ne pas auto-exécuter — présenter le rapport d’abord, attendre l’approbation
TOUJOURS ajouter au changelog et TOUJOURS mettre à jour le badge — obligatoire
Trier par étoiles décroissantes — plus grand nombre d’étoiles d’abord
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.
Agents, commandes et skills sont différents — compter depuis leurs répertoires respectifs, ne pas les confondre
Arrondir les étoiles de façon cohérente — suffixe k (98k, 10k, 4.1k). Sous 1000, afficher le nombre exact
Comparer avec le changelog précédent — marquer les éléments NEW, RECURRING ou RESOLVED
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).
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.

15 KiB Raw Blame History Unescape Escape