La suite AI SDLC Skills ne se limite plus à une collection de bonnes pratiques. Les derniers ajouts introduisent une couche d’orchestration qui transforme les skills en système de travail complet : rôles agents, harnais d’exécution, pipelines, intégrations runtime et exemple concret idée -> PR.
Le problème : les agents codent vite, mais pas toujours dans le bon cadre
Un agent de code peut lire un repository, modifier des fichiers et lancer des tests. Mais sans cadre explicite, il peut aussi partir trop vite : specs floues, architecture implicite, tests incomplets, dette non vue, sécurité traitée trop tard, ou déploiement confondu avec une simple commande.
L’objectif de cette extension est de rendre l’automatisation plus fiable : venir avec une idée d’application, la faire passer par le produit, le domaine, le BDD, l’architecture, l’UX/UI, l’implémentation, les tests, la sécurité, la review et la readiness production.
La solution : une agent factory au-dessus des skills
La logique ajoutée sépare clairement quatre niveaux.
- Skills : les méthodes de travail, par exemple PRD, BDD, bounded contexts, architecture, tests, release readiness, observabilité.
- Agents : les rôles qui exécutent, comme product strategist, domain architect, fullstack builder, QA test engineer, security reviewer ou release manager.
- Harnais : les machines d’état qui disent dans quel ordre travailler, quels livrables produire et où placer les gates humains.
- Intégrations : les modes d’emploi pour brancher le même système dans Codex, Claude Code, Hermes, OpenClaw, GitHub Actions ou des connecteurs MCP.
Ce qui a été ajouté au dépôt
Le dépôt contient maintenant onze agents spécialisés, trois harnais, trois pipelines, une matrice runtime et des guides d’intégration.
- Agents : orchestrator, product strategist, domain architect, UX/UI designer, solution architect, fullstack builder, QA test engineer, security reviewer, DevOps/SRE, code reviewer, release manager.
- Harnais : app idea to production, feature to production, production feedback loop.
- Pipelines : idea to PR, PR to production, production feedback loop.
- Intégrations : Codex, Claude Code, Hermes, OpenClaw, GitHub Actions et MCP.
- Exemple complet : un cas ReleasePilot qui montre comment une idée brute devient un task graph, une carte d’artefacts, une PR simulée et un review gate.
Comment le cycle fonctionne
Le point d’entrée est l’orchestrateur. Il classe la demande : nouvelle app, feature, refactor, incident, audit ou amélioration production. Ensuite il choisit le harnais adapté et distribue le travail aux agents spécialisés.
Pour une nouvelle application, le parcours type est le suivant :
- clarifier l’idée, les utilisateurs, les hypothèses et le MVP ;
- rédiger le PRD et les exigences testables ;
- modéliser le domaine, les bounded contexts et les scénarios BDD ;
- définir les parcours UX, les états UI et les critères d’accessibilité ;
- poser l’architecture, le modèle de données, les APIs, l’identité et le multi-tenant ;
- découper le backlog en tranches verticales ;
- faire implémenter une première tranche dans une branche ou un worktree isolé ;
- faire vérifier par QA, sécurité et code review ;
- préparer la PR et s’arrêter avant la production.
Cas concret : ReleasePilot
L’exemple ajouté dans le dépôt part d’une idée simple : une application B2B pour petites équipes produit-tech qui transforme un brief de feature, des critères d’acceptation, un statut CI, des notes de risque et un contexte de déploiement en vue de readiness release.
La première tranche verticale reste volontairement petite : créer une checklist de release, classifier les gates manquants, afficher un résumé de risque et exporter un texte prêt pour une PR.
C’est exactement le type de cas où l’automatisation IA devient utile : le code n’est pas généré dans le vide. Il est relié à un comportement attendu, à une architecture, à des tests, à une revue de sécurité et à une décision de merge.
L’apport pour une équipe de développement
Pour une petite équipe, l’intérêt est de récupérer une discipline de delivery habituellement réservée aux organisations plus matures, sans créer une usine documentaire. Pour une équipe plus avancée, l’intérêt est de standardiser les gates et de rendre les agents plus prédictibles.
- moins d’ambiguïté entre idée, spec, comportement attendu et code ;
- meilleure traçabilité entre PRD, BDD, architecture, tests et PR ;
- travail parallèle possible avec des agents spécialisés ;
- intégration possible avec plusieurs runtimes au lieu de verrouiller le système dans un seul outil ;
- garde-fous explicites pour la production, les secrets, les migrations, les données clients et les dépendances.
Pourquoi ce n’est pas magique
L’ambition est d’automatiser beaucoup plus que la simple génération de code. Mais les gates humains restent indispensables. Une IA peut proposer, implémenter, tester et reviewer ; elle ne doit pas décider seule d’un changement de production, d’une migration destructive, d’un ajout de dépendance critique, d’un changement lié aux données clients ou d’une décision produit structurante.
Le bon objectif n’est donc pas « 99,9 % sans humain ». Le bon objectif est : spec plus claire, implémentation plus rapide, review plus systématique, release plus sûre, et apprentissage production mieux bouclé.
Où trouver le projet
Le dépôt public est disponible ici : https://github.com/fareswebnet/ai-sdlc-skills.
Le dossier clé pour comprendre cette nouvelle couche est examples/agent-factory-idea-to-pr/. Il montre comment le système peut passer d’une idée brute à une PR simulée avec task graph, artefacts SDLC, prompts Codex/Claude Code/Hermes et review gate.