Outils Analyse & Estimation (Flux C)
Le flux C contient 10 outils pour comprendre votre base de code, estimer l'effort, détecter les problèmes de qualité et maintenir les specs alignées avec la réalité.
estimate
Estimer l'effort, le coût et l'utilisation de tokens pour une spec via une analyse multi-agents.
Ce qu'il produit :
- Plage de story points (optimiste / réaliste / pessimiste)
- Plage de coût en dollars (basée sur
SDD_HOURLY_RATE) - Estimation d'utilisation de tokens pour l'implémentation assistée par IA
- Facteurs de risque affectant l'estimation
- Ventilation par phase d'implémentation
Quand l'utiliser : Avant de s'engager sur une spec pour un sprint, ou lors de la communication du périmètre aux parties prenantes.
Prompt : "Estime la spec SPEC-003 pour le projet proj_abc123"
Prompt : "Quel est l'effort de la spec SPEC-007 dans le projet proj_abc123 ?"reverse_engineer
Analyser le code existant et générer une spec SDD à partir de celui-ci.
Quand l'utiliser : Lorsque vous avez du code fonctionnel mais pas de spec — courant lors de l'intégration de systèmes hérités, ou lorsqu'une fonctionnalité a été construite ad-hoc et doit maintenant être formellement documentée.
Ce qu'il produit : Un HU.md complet rétro-ingéniéré depuis le code — critères d'acceptation inférés du comportement de l'implémentation, schéma inféré des modèles de données, et lacunes identifiées où le comportement est ambigu.
Prompt : "Rétro-ingénieure ma base de code dans /Users/moi/mon-app/src/auth et génère des specs pour le projet proj_abc123"validate
Valider l'implémentation contre sa spec — couverture, drift et qualité.
Ce qu'il vérifie :
- Quels critères d'acceptation sont satisfaits par le code
- Lesquels sont manquants ou seulement partiellement implémentés
- Pourcentage de couverture global
- Suggestions pour combler les lacunes
Quand l'utiliser : Après avoir terminé l'implémentation, avant de marquer une spec done.
Prompt : "Valide la spec SPEC-001 contre le code dans /Users/moi/mon-app/src pour le projet proj_abc123"detect_drift
Détecter le drift entre la spec et l'implémentation — inclut la conformité à la Constitution et l'analyse d'impact en cascade.
Ce qu'il rapporte :
- Les critères qui ne correspondent plus au code
- Les nouveaux patterns de code non couverts par aucune spec
- Les violations de la Constitution introduites depuis la dernière vérification
- Les specs en aval affectées par le drift (impact en cascade)
Quand l'utiliser : Périodiquement à mesure que la base de code évolue, ou avant toute release majeure.
Prompt : "Détecte le drift dans la spec SPEC-003 pour le projet proj_abc123"
Prompt : "Vérifie si mon implémentation correspond à la spec SPEC-001"audit
Auditer le code pour les violations SOLID, de code propre, d'architecture et de Constitution. Génère un score de qualité de 0 à 100.
Ventilation du score :
- Conformité aux principes SOLID
- Métriques de code propre (nommage, taille des fonctions, couplage)
- Conformité des couches architecturales
- Adhérence à la Constitution
- Signaux de couverture de tests
Quand l'utiliser : Lors de la revue de code, avant de merger, ou comme vérification périodique de la santé de la base de code.
Prompt : "Audite le code dans /Users/moi/mon-app/src pour le projet proj_abc123"learn_pattern
Enseigner au système un nouveau pattern — convention architecturale, heuristique d'estimation, décision de stack ou règle de qualité.
Types de patterns : architecture, convention, estimation, stack, quality
Quand l'utiliser : Lorsque votre équipe a établi un pattern que SpecForge doit appliquer lors de la génération de specs, de plans ou d'estimations.
Prompt : "Apprends à specforge que nous utilisons toujours le pattern repository pour l'accès à la base de données dans le projet proj_abc123"
Prompt : "Ajoute un pattern d'estimation : les intégrations API prennent toujours 2x plus de temps que prévu pour le projet proj_abc123"security_check
Analyser une spec contre l'OWASP Top 10, scanner le code pour des patterns non sécurisés et générer un score de sécurité (A–F) avec détection de drift.
Ce qu'il vérifie :
- Vulnérabilités d'injection (SQL, commande, LDAP)
- Authentification et gestion de session
- Exposition de données sensibles
- Problèmes de contrôle d'accès
- Mauvaise configuration de sécurité
Quand l'utiliser : Avant toute spec impliquant l'authentification, l'autorisation, les paiements ou les données utilisateur.
Prompt : "Lance une vérification de sécurité sur la spec SPEC-005 pour le projet proj_abc123"
Prompt : "Audit de sécurité du code dans /Users/moi/mon-app/src/api pour le projet proj_abc123"capture_learning
Capturer un pattern ou une leçon découverte dans le système de specs avec déduplication sémantique.
Quand l'utiliser : Après un post-mortem de bug, une erreur d'estimation douloureuse, ou toute découverte de flux de travail que vous voulez appliquer aux specs futures.
SpecForge déduplique par rapport aux patterns existants pour ne pas accumuler de règles redondantes.
Prompt : "Capture learning : lors de l'intégration d'OAuth tiers, toujours vérifier la gestion de l'expiration des tokens avec un test explicite"paradigm_report
Détecter et rapporter les paradigmes de programmation utilisés dans un projet — fonctionnel, OOP, réactif, événementiel, déclaratif, etc.
Quand l'utiliser : Lors de l'intégration dans une base de code inconnue, ou lors de l'établissement de standards de codage à appliquer dans les specs.
Prompt : "Génère un rapport de paradigmes pour le projet proj_abc123"reality_check
Évaluer si un ensemble d'exigences est faisable compte tenu du contexte du projet.
Ce qu'il évalue :
- Faisabilité technique compte tenu de la stack actuelle
- Contraintes de dépendances
- Réalisme des délais basé sur les estimations historiques
- Risques pouvant bloquer la livraison
Quand l'utiliser : Avant de s'engager sur une deadline, ou lorsqu'une partie prenante demande quelque chose qui semble irréaliste.
Prompt : "Reality check : peut-on construire un éditeur collaboratif en temps réel en 2 semaines pour le projet proj_abc123 ?"