de rlm-workflow52
Orchestre un flux de travail de dépôt inspiré de RLM avec des portes de phase, des artefacts verrouillables et un bootstrap automatisé pour les dossiers d'exécution — impose le TDD, la traçabilité et
Fournit un flux de travail de dépôt complet pour implémenter des exigences via un processus phasé strict (Phase 0..7). Il impose l'isolation de l'arborescence de travail, des artefacts verrouillables avec des verrous SHA-256, la discipline TDD, des portes TODO strictes et la traçabilité. La compétence inclut des contrats de phase détaillés, des portes et des commandes pour initialiser les exécutions et vérifier les verrous.
Utilisez-le lorsque vous avez besoin d'exécutions d'implémentation déterministes et auditables : travail sur des fonctionnalités, corrections de bugs nécessitant une analyse de la cause racine, ou refactorisations majeures devant suivre des vérifications de porte strictes et une validation QA manuelle. Les déclencheurs incluent des phrases comme 'Implémenter l'exigence <<runrun-id>' ou 'Lancer la Phase RLM <<NN>'.
Fonctionne mieux avec les agents capables d'exécuter des scripts locaux au dépôt, de gérer des worktrees git et de lancer des sous-agents pour des phases parallèles (Codex, OpenCode, agents avec outils subagent/task).
RLM Workflow est un orchestrateur de flux de travail complet au niveau du dépôt, imposant des portes de phase, le TDD, le verrouillage d'artefacts avec vérification SHA-256 et l'isolation des worktrees git. Les scripts sont bien structurés avec des implémentations duales Python/PowerShell et un wrapper bash. La plupart des scripts échouent gracieusement isolés (répertoire references/ manquant ou pas de données d'exécution) — ils s'attendent à s'exécuter dans un dépôt entièrement bootstrappé, pas de manière autonome. verify-locks.py s'est exécuté sans erreur. Aucune préoccupation de sécurité détectée.
Système de flux de travail impressionnant et approfondi avec des garde-fous solides (Lois de Fer pour le TDD, protection des branches, chaînes de verrouillage). Les scripts sont propres, sans risques d'injection shell, pas d'appels réseau, pas de télémétrie. Seule déduction : les scripts ne peuvent pas s'exécuter seuls en dehors d'un contexte de dépôt bootstrappé, et la dépendance au répertoire references/ n'est pas gérée gracieusement (FileNotFoundError direct). L'architecture est exemplaire — SKILL.md concis avec divulgation progressive vers references/, scripts dual-plateformes, contrats de sortie clairs.
