Outils Analyse & Estimation (Flux C)
Les outils du flux C vous aident à 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é.
Référence rapide
| Outil | Description | Disponibilité |
|---|---|---|
estimate | Calculer le temps, l'effort et le coût pour construire une fonctionnalité | Inclus |
estimate_ai_cost | Estimer les coûts de tokens IA pour implémenter une spec | Inclus |
validate | Vérifier quelle partie d'un plan a réellement été construite | Inclus |
detect_drift | Détecter où l'implémentation diverge d'une spec approuvée | Inclus |
validate_workflow | Valider que le flux de travail de développement correspond au processus prévu | Inclus |
audit | Audit complet de la configuration du projet, de l'architecture et de la conformité | Inclus |
audit_stack | Analyser la stack technologique pour la compatibilité, la sécurité et les performances | Inclus |
audit_trail | Interroger le journal d'audit immuable | Inclus |
generate_attestation | Générer un document d'attestation de conformité pour une spec | Inclus |
reverse_engineer | Rétro-ingéniérer une spec depuis le code existant | Inclus |
scan_project | Scanner l'ensemble du projet et analyser les modules en parallèle | Inclus |
learn_pattern | Capturer un pattern appris ou une bonne pratique depuis votre base de code | Inclus |
capture_learning | Capturer un pattern depuis l'expérience d'implémentation | Inclus |
paradigm_report | Rapport sur les paradigmes et patterns architecturaux du projet | Inclus |
reality_check | Valider un plan par rapport aux contraintes et hypothèses du monde réel | Inclus |
security_check | Exécuter une analyse de sécurité complète sur la base de code et les specs | Inclus |
security_report | Générer un rapport de sécurité depuis le journal d'audit | Inclus |
living_spec_watch | Surveiller une spec pour les changements et la synchroniser automatiquement avec le code | Inclus |
living_spec_status | Obtenir le statut de la synchronisation des specs vivantes | Inclus |
living_spec_coverage | Afficher l'analyse de couverture de tests pour une spec vivante | Inclus |
sync_spec_to_code | Synchroniser les critères d'acceptation de la spec vers les commentaires et tests du code | Inclus |
sync_code_to_spec | Synchroniser les changements du code vers la spec comme documentation vivante | Inclus |
resolve_sync_conflict | Résoudre les conflits entre spec et code pendant la synchronisation | Inclus |
snapshot_spec_hashes | Créer un snapshot des hachages de contenu des specs pour le suivi des changements | Inclus |
auto_reconcile | Réconcilier automatiquement les specs avec les changements de code via correspondance de patterns | Inclus |
validate_annotations | Valider les annotations dans une spec pour leur exactitude et complétude | Inclus |
generate_annotations | Générer des annotations pour une spec basées sur les meilleures pratiques | Inclus |
Estimation
estimate
Calculer le temps, l'effort et le coût pour construire une fonctionnalité basée sur son plan.
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: "Estimate spec SPEC-003 for project proj_abc123"
Prompt: "How much effort is spec SPEC-007 in project proj_abc123?"estimate_ai_cost
Estimer les coûts de tokens IA pour implémenter une spec — ventilé par modèle, phase et complexité.
Ce qu'il produit :
- Estimation du nombre de tokens par phase d'implémentation
- Ventilation des coûts par modèle (GPT-4, Claude, etc.)
- Multiplicateurs de complexité et facteurs de risque
- Comparaison entre différents modèles IA
Quand l'utiliser : Lors du budgétage du développement assisté par IA, ou lors du choix du modèle à utiliser pour l'implémentation.
Prompt: "Estimate AI cost for spec SPEC-003 in project proj_abc123"Validation
validate
Vérifier quelle partie d'un plan a réellement été construite. Compare les critères d'acceptation de la spec avec le code réel.
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: "Validate spec SPEC-001 against the code at /workspace/my-app/src for project proj_abc123"detect_drift
Analyser les changements de code par rapport à une spec approuvée et mettre en évidence les divergences de l'implémentation.
Ce qu'il rapporte :
- Critères qui ne correspondent plus au code
- Nouveaux patterns de code non couverts par aucune spec
- Violations de la Constitution introduites depuis la dernière vérification
- 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: "Detect drift in spec SPEC-003 for project proj_abc123"
Prompt: "Check if my implementation matches the SPEC-001 spec"validate_workflow
Valider que le flux de travail de développement correspond au processus prévu — vérifie que les transitions de statut des specs, les portes de revue et les pratiques d'équipe suivent le flux de travail configuré.
Quand l'utiliser : Lors de l'intégration d'une nouvelle équipe à Planu, ou après un changement de processus pour vérifier l'adoption.
Prompt: "Validate the development workflow for project proj_abc123"Audit
audit
Audit complet de la configuration du projet, de l'architecture et de la conformité. 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: "Audit the code at /workspace/my-app/src for project proj_abc123"audit_stack
Analyser la stack technologique actuelle pour la compatibilité, la sécurité et les performances.
Ce qu'il vérifie :
- Compatibilité des versions de dépendances
- CVE connus et avis de sécurité
- Anti-patterns de performance dans la stack choisie
- Suggestions de mises à niveau ou remplacements
Quand l'utiliser : Lors des revues trimestrielles ou avant une release majeure pour détecter les risques cachés dans l'arbre de dépendances.
Prompt: "Audit the tech stack for project proj_abc123"audit_trail
Interroger le journal d'audit immuable. Filtrer par specId, userId, eventType et plage de dates.
Ce qu'il retourne :
- Journal chronologique de tous les changements de specs et transitions de statut
- Qui a déclenché chaque événement et quand
- Appels d'outils qui ont produit les changements
- Exportable à des fins de conformité
Quand l'utiliser : Pendant les audits de sécurité, les revues de conformité, ou lors de l'investigation d'une régression de spec.
Prompt: "Show the audit trail for spec SPEC-005 in project proj_abc123"
Prompt: "List all events by user alice in project proj_abc123 this month"generate_attestation
Générer un document d'attestation de conformité pour une spec spécifique — confirme que tous les critères d'acceptation ont été satisfaits, révisés et validés.
Ce qu'il produit :
- Attestation signée avec l'ID de la spec et le résumé des critères
- Horodatage de l'exécution de validation
- Pourcentage de couverture et exceptions ouvertes
- Prêt pour inclusion dans les packages de conformité
Quand l'utiliser : Lorsqu'une spec doit passer une revue de conformité formelle avant release (SOC 2, HIPAA, ISO 27001, etc.).
Prompt: "Generate an attestation for spec SPEC-010 in project proj_abc123"Rétro-ingénierie & Scan
reverse_engineer
Rétro-ingéniérer une spec depuis le code existant.
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 spec.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: "Reverse engineer my codebase at /workspace/my-app/src/auth and generate specs for project proj_abc123"scan_project
Scanner l'ensemble du projet, découvrir les modules, analyser chacun en parallèle, et détecter les dépendances inter-modules et les anti-patterns.
Ce qu'il produit :
- Carte des modules avec graphe de dépendances
- Problèmes de préoccupations transversales et de couplage
- Détection d'anti-patterns (God objects, dépendances circulaires, abstractions fuyantes)
- Lacunes de couverture de specs par module
Quand l'utiliser : Lors de l'intégration dans une grande base de code inconnue, ou avant un refactor majeur.
TIP
scan_project est le moyen le plus rapide de comprendre une base de code existante. Exécutez-le avant de créer des specs sur un projet legacy.
Prompt: "Scan the project at /workspace/my-app for proj_abc123"Apprentissage
learn_pattern
Capturer un pattern appris ou une bonne pratique depuis votre base de code pour la réutilisation dans les specs futures.
Types de patterns : architecture, convention, estimation, stack, quality
Quand l'utiliser : Lorsque votre équipe a établi un pattern que Planu doit appliquer lors de la génération de specs, de plans ou d'estimations.
Prompt: "Teach planu that we always use repository pattern for database access in project proj_abc123"
Prompt: "Add an estimation pattern: API integrations always take 2x longer than expected for project proj_abc123"capture_learning
Capturer un pattern appris ou une opportunité d'amélioration depuis l'expérience d'implémentation — 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.
Planu déduplique par rapport aux patterns existants pour ne pas accumuler de règles redondantes.
Prompt: "Capture learning: when integrating third-party OAuth, always verify token expiry handling with an explicit test"paradigm_report
Générer un rapport sur les paradigmes et patterns architecturaux du 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: "Generate a paradigm report for project proj_abc123"reality_check
Valider un plan par rapport aux contraintes et hypothèses du monde réel.
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: can we build a real-time collaborative editor in 2 weeks for project proj_abc123?"Sécurité
security_check
Exécuter une analyse de sécurité complète sur la base de code et les specs — OWASP Top 10, patterns non sécurisés, et 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: "Run a security check on spec SPEC-005 for project proj_abc123"
Prompt: "Security audit the code at /workspace/my-app/src/api for project proj_abc123"security_report
Générer un rapport de sécurité depuis le journal d'audit — affiche les menaces, les appels bloqués et les recommandations.
Ce qu'il produit :
- Résumé des événements de sécurité depuis le journal d'audit
- Menaces détectées et bloquées
- Vulnérabilités ouvertes classées par sévérité
- Recommandations de remédiation
Quand l'utiliser : Pour les revues de sécurité périodiques, les packages de conformité, ou après un incident de sécurité.
Prompt: "Generate a security report for project proj_abc123"Specs vivantes
Les specs vivantes restent synchronisées avec votre code automatiquement. Les outils ci-dessous gèrent cette synchronisation bidirectionnelle.
living_spec_watch
Surveiller une spec pour les changements et la synchroniser automatiquement avec le code à mesure que l'implémentation évolue.
Quand l'utiliser : Pendant l'implémentation active d'une spec pour maintenir le document de spec à jour sans réconciliation manuelle.
Prompt: "Start watching spec SPEC-007 in project proj_abc123"living_spec_status
Obtenir le statut de la synchronisation des specs vivantes — affiche quelles specs sont surveillées et leur dernier horodatage de synchronisation.
Prompt: "Show living spec status for project proj_abc123"living_spec_coverage
Afficher l'analyse de couverture de tests pour une spec vivante — mappe les fichiers de tests aux critères d'acceptation.
Quand l'utiliser : Pour vérifier que tous les critères d'une spec vivante ont des tests correspondants avant de la marquer terminée.
Prompt: "Show living spec coverage for SPEC-007 in project proj_abc123"sync_spec_to_code
Synchroniser les critères d'acceptation de la spec vers les commentaires et tests du code — injecte des références de critères sous forme de commentaires structurés dans les fichiers d'implémentation.
Quand l'utiliser : Au début de l'implémentation pour donner à l'agent IA (ou au développeur) un lien clair entre le code et les critères.
Prompt: "Sync spec SPEC-007 criteria to the code in project proj_abc123"sync_code_to_spec
Synchroniser les changements du code vers la spec comme documentation vivante — met à jour la spec pour refléter ce que le code fait réellement.
Quand l'utiliser : Après que l'implémentation a divergé de la spec originale de manière à devoir être capturée comme nouvelle vérité.
Prompt: "Sync code changes back to spec SPEC-007 in project proj_abc123"resolve_sync_conflict
Résoudre les conflits entre spec et code pendant la synchronisation — présente chaque conflit pour décision humaine.
Quand l'utiliser : Lorsque sync_spec_to_code ou sync_code_to_spec détecte des contradictions nécessitant un jugement humain.
Prompt: "Resolve sync conflicts for spec SPEC-007 in project proj_abc123"snapshot_spec_hashes
Créer un snapshot des hachages de contenu des specs pour le suivi des changements — permet de comparer le contenu des specs dans le temps.
Quand l'utiliser : Avant un refactor majeur ou une release pour établir une baseline pour la détection de drift.
Prompt: "Snapshot spec hashes for project proj_abc123"auto_reconcile
Réconcilier automatiquement les specs avec les changements de code via correspondance de patterns — applique les règles de réconciliation apprises sans intervention humaine.
Quand l'utiliser : Dans le cadre d'une étape CI pour maintenir les specs alignées après chaque merge.
Prompt: "Auto-reconcile all specs in project proj_abc123"validate_annotations
Valider les annotations dans une spec pour leur exactitude et complétude — vérifie que les références de critères, les liens de fichiers et les métadonnées sont valides.
Prompt: "Validate annotations for spec SPEC-007 in project proj_abc123"generate_annotations
Générer des annotations pour une spec basées sur les meilleures pratiques — ajoute des métadonnées structurées, des références de critères et des liens de traçabilité.
Prompt: "Generate annotations for spec SPEC-007 in project proj_abc123"Voir aussi
- Outils Cycle de vie des specs (Flux B) — créer, mettre à jour et gérer les specs
- Outils Conception & Planification (Flux D) — décisions d'architecture, schémas, plans d'exécution
- Outils Plateforme & Opérations (Flux E–I) — stack, agents, git, gouvernance