Analyse & Schätzungs-Tools (Stream C)
Stream C Tools helfen dir, deine Codebasis zu verstehen, Aufwand zu schätzen, Qualitätsprobleme zu erkennen und Specs mit der Realität in Einklang zu halten.
Schnellreferenz
| Tool | Beschreibung | Verfügbarkeit |
|---|---|---|
estimate | Zeit, Aufwand und Kosten für die Implementierung eines Features berechnen | Enthalten |
estimate_ai_cost | KI-Token-Kosten für die Implementierung einer Spec schätzen | Enthalten |
validate | Prüfen, wie viel eines Plans tatsächlich gebaut wurde | Enthalten |
detect_drift | Erkennen, wo die Implementierung von einer genehmigten Spec abweicht | Enthalten |
validate_workflow | Validieren, dass der Entwicklungsworkflow dem beabsichtigten Prozess entspricht | Enthalten |
audit | Umfassender Audit von Projektkonfiguration, Architektur und Compliance | Enthalten |
audit_stack | Tech-Stack auf Kompatibilität, Sicherheit und Performance-Probleme analysieren | Enthalten |
audit_trail | Das unveränderliche Audit-Log abfragen | Enthalten |
generate_attestation | Ein Compliance-Attestierungsdokument für eine Spec generieren | Enthalten |
reverse_engineer | Eine Spec aus bestehendem Code rückwärts entwickeln | Enthalten |
scan_project | Gesamtes Projekt scannen und Module parallel analysieren | Enthalten |
learn_pattern | Ein erlerntes Muster oder eine Best Practice aus der Codebasis erfassen | Enthalten |
capture_learning | Ein Muster aus Implementierungserfahrung erfassen | Enthalten |
paradigm_report | Bericht über Architekturparadigmen und Muster im Projekt | Enthalten |
reality_check | Einen Plan gegen reale Einschränkungen und Annahmen validieren | Enthalten |
security_check | Eine umfassende Sicherheitsanalyse der Codebasis und Specs ausführen | Enthalten |
security_report | Einen Sicherheitsbericht aus dem Audit-Log generieren | Enthalten |
living_spec_watch | Eine Spec auf Änderungen überwachen und automatisch mit Code synchronisieren | Enthalten |
living_spec_status | Den Status der lebenden Spec-Synchronisierung abrufen | Enthalten |
living_spec_coverage | Testabdeckungsanalyse für eine lebende Spec anzeigen | Enthalten |
sync_spec_to_code | Spec-Abnahmekriterien mit Code-Kommentaren und Tests synchronisieren | Enthalten |
sync_code_to_spec | Code-Änderungen als lebende Dokumentation zurück in die Spec synchronisieren | Enthalten |
resolve_sync_conflict | Konflikte zwischen Spec und Code während der Synchronisierung lösen | Enthalten |
snapshot_spec_hashes | Einen Snapshot von Spec-Inhalts-Hashes für die Änderungsverfolgung erstellen | Enthalten |
auto_reconcile | Specs automatisch mit Code-Änderungen mithilfe von Musterabgleich abgleichen | Enthalten |
validate_annotations | Annotationen in einer Spec auf Korrektheit und Vollständigkeit validieren | Enthalten |
generate_annotations | Annotationen für eine Spec basierend auf Best Practices generieren | Enthalten |
Schätzung
estimate
Zeit, Aufwand und Kosten für die Implementierung eines Features basierend auf seinem Plan berechnen.
Was es erzeugt:
- Story-Point-Spanne (optimistisch / realistisch / pessimistisch)
- Dollar-Kostenspanne (basierend auf
SDD_HOURLY_RATE) - Token-Nutzungsschätzung für KI-gestützte Implementierung
- Risikofaktoren, die die Schätzung beeinflussen
- Aufschlüsselung nach Implementierungsphase
Wann verwenden: Vor dem Commit einer Spec zu einem Sprint oder beim Kommunizieren des Umfangs an Stakeholder.
Prompt: "Estimate spec SPEC-003 for project proj_abc123"
Prompt: "How much effort is spec SPEC-007 in project proj_abc123?"estimate_ai_cost
KI-Token-Kosten für die Implementierung einer Spec schätzen — aufgeschlüsselt nach Modell, Phase und Komplexität.
Was es erzeugt:
- Token-Schätzung pro Implementierungsphase
- Kostenaufschlüsselung nach Modell (GPT-4, Claude usw.)
- Komplexitätsmultiplikatoren und Risikofaktoren
- Vergleich zwischen verschiedenen KI-Modellen
Wann verwenden: Beim Budgetieren KI-gestützter Entwicklung oder bei der Wahl des Modells für die Implementierung.
Prompt: "Estimate AI cost for spec SPEC-003 in project proj_abc123"Validierung
validate
Prüfen, wie viel eines Plans tatsächlich gebaut wurde. Vergleicht Spec-Abnahmekriterien mit echtem Code.
Was geprüft wird:
- Welche Abnahmekriterien durch den Code erfüllt werden
- Welche fehlen oder nur teilweise implementiert sind
- Gesamte Abdeckung in Prozent
- Vorschläge zum Schließen von Lücken
Wann verwenden: Nach Abschluss der Implementierung, bevor eine Spec als done markiert wird.
Prompt: "Validate spec SPEC-001 against the code at /workspace/my-app/src for project proj_abc123"detect_drift
Code-Änderungen gegen eine genehmigte Spec analysieren und hervorheben, wo die Implementierung abweicht.
Was berichtet wird:
- Kriterien, die nicht mehr mit dem Code übereinstimmen
- Neue Code-Muster, die von keiner Spec abgedeckt werden
- Verfassungsverstöße, die seit der letzten Prüfung eingeführt wurden
- Nachgelagerte Specs, die von der Abweichung betroffen sind (Kaskadeneffekte)
Wann verwenden: Regelmäßig, wenn sich die Codebasis weiterentwickelt, oder vor einer größeren Veröffentlichung.
Prompt: "Detect drift in spec SPEC-003 for project proj_abc123"
Prompt: "Check if my implementation matches the SPEC-001 spec"validate_workflow
Validieren, dass der Entwicklungsworkflow dem beabsichtigten Prozess entspricht — prüft, ob Spec-Status-Übergänge, Review-Gates und Teampraktiken dem konfigurierten Workflow folgen.
Wann verwenden: Beim Onboarding eines neuen Teams zu Planu oder nach einer Prozessänderung zur Überprüfung der Einführung.
Prompt: "Validate the development workflow for project proj_abc123"Audit
audit
Umfassender Audit von Projektkonfiguration, Architektur und Compliance. Generiert einen Qualitäts-Score 0–100.
Score-Aufschlüsselung:
- Einhaltung der SOLID-Prinzipien
- Sauberer-Code-Metriken (Benennung, Funktionsgröße, Kopplung)
- Architektur-Schicht-Compliance
- Einhaltung der Verfassung
- Test-Abdeckungs-Signale
Wann verwenden: Beim Code-Review, vor dem Mergen oder als regelmäßige Codebasis-Gesundheitsprüfung.
Prompt: "Audit the code at /workspace/my-app/src for project proj_abc123"audit_stack
Den aktuellen Tech-Stack auf Kompatibilität, Sicherheit und Performance-Probleme analysieren.
Was geprüft wird:
- Abhängigkeitsversionskompatibilität
- Bekannte CVEs und Sicherheitshinweise
- Performance-Anti-Pattern im gewählten Stack
- Vorschläge für Upgrades oder Ersatz
Wann verwenden: Bei vierteljährlichen Überprüfungen oder vor einer größeren Veröffentlichung, um versteckte Risiken im Abhängigkeitsbaum zu erkennen.
Prompt: "Audit the tech stack for project proj_abc123"audit_trail
Das unveränderliche Audit-Log abfragen. Nach specId, userId, eventType und Datumsbereich filtern.
Was zurückgegeben wird:
- Chronologisches Log aller Spec-Änderungen und Status-Übergänge
- Wer jedes Event ausgelöst hat und wann
- Tool-Aufrufe, die die Änderungen verursacht haben
- Exportierbar für Compliance-Zwecke
Wann verwenden: Bei Sicherheitsaudits, Compliance-Überprüfungen oder beim Untersuchen einer Spec-Regression.
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
Ein Compliance-Attestierungsdokument für eine bestimmte Spec generieren — bestätigt, dass alle Abnahmekriterien erfüllt, überprüft und validiert wurden.
Was es erzeugt:
- Signierte Attestierung mit Spec-ID und Kriterienübersicht
- Zeitstempel des Validierungslaufs
- Abdeckungsprozentsatz und offene Ausnahmen
- Bereit zur Aufnahme in Compliance-Pakete
Wann verwenden: Wenn eine Spec eine formale Compliance-Überprüfung vor der Veröffentlichung bestehen muss (SOC 2, HIPAA, ISO 27001 usw.).
Prompt: "Generate an attestation for spec SPEC-010 in project proj_abc123"Rückwärts-Engineering & Scanning
reverse_engineer
Eine Spec aus bestehendem Code rückwärts entwickeln.
Wann verwenden: Wenn du funktionierenden Code, aber keine Spec hast — häufig beim Onboarding von Legacy-Systemen oder wenn eine Funktion ad-hoc gebaut wurde und nun formal dokumentiert werden muss.
Was es erzeugt: Eine vollständige spec.md, die aus dem Code rückwärts entwickelt wurde — Abnahmekriterien aus dem Implementierungsverhalten abgeleitet, Schema aus Datenmodellen abgeleitet und Lücken identifiziert, wo das Verhalten unklar ist.
Prompt: "Reverse engineer my codebase at /workspace/my-app/src/auth and generate specs for project proj_abc123"scan_project
Das gesamte Projekt scannen, Module entdecken, jeden parallel analysieren und modulübergreifende Abhängigkeiten und Anti-Pattern erkennen.
Was es erzeugt:
- Modul-Map mit Abhängigkeitsgraph
- Querschnittsbedenken und Kopplungsprobleme
- Anti-Pattern-Erkennung (God-Objects, zirkuläre Abhängigkeiten, undichte Abstraktionen)
- Spec-Abdeckungslücken pro Modul
Wann verwenden: Beim Onboarding in eine große unbekannte Codebasis oder vor einem größeren Refactoring.
TIP
scan_project ist der schnellste Weg, eine bestehende Codebasis zu verstehen. Führe es aus, bevor du Specs für ein Legacy-Projekt erstellst.
Prompt: "Scan the project at /workspace/my-app for proj_abc123"Lernen
learn_pattern
Ein erlerntes Muster oder eine Best Practice aus der Codebasis für die Wiederverwendung in zukünftigen Specs erfassen.
Mustertypen: architecture, convention, estimation, stack, quality
Wann verwenden: Wenn dein Team ein Muster etabliert hat, das Planu beim Generieren von Specs, Plänen oder Schätzungen anwenden soll.
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
Ein erlerntes Muster oder eine Verbesserungsmöglichkeit aus Implementierungserfahrung erfassen — mit semantischer Deduplizierung.
Wann verwenden: Nach einer Bug-Post-Mortem-Analyse, einem schmerzhaften Schätzungsfehler oder einer Workflow-Entdeckung, die auf zukünftige Specs angewendet werden soll.
Planu dedupliziert gegen bestehende Muster, damit keine redundanten Regeln angesammelt werden.
Prompt: "Capture learning: when integrating third-party OAuth, always verify token expiry handling with an explicit test"paradigm_report
Einen Bericht über Architekturparadigmen und Muster im Projekt generieren — funktional, OOP, reaktiv, ereignisgesteuert, deklarativ usw.
Wann verwenden: Beim Onboarding in eine unbekannte Codebasis oder beim Etablieren von Coding-Standards, die in Specs durchgesetzt werden sollen.
Prompt: "Generate a paradigm report for project proj_abc123"reality_check
Einen Plan gegen reale Einschränkungen und Annahmen validieren.
Was bewertet wird:
- Technische Machbarkeit angesichts des aktuellen Stacks
- Abhängigkeitseinschränkungen
- Zeitplanrealismus basierend auf historischen Schätzungen
- Risiken, die die Lieferung blockieren könnten
Wann verwenden: Vor dem Commit zu einem Termin oder wenn ein Stakeholder etwas anfordert, das unrealistisch erscheint.
Prompt: "Reality check: can we build a real-time collaborative editor in 2 weeks for project proj_abc123?"Sicherheit
security_check
Eine umfassende Sicherheitsanalyse der Codebasis und Specs ausführen — OWASP Top 10, unsichere Muster und ein Sicherheits-Score (A–F) mit Abweichungserkennung.
Was geprüft wird:
- Injection-Schwachstellen (SQL, Befehl, LDAP)
- Authentifizierung und Session-Verwaltung
- Sensible Datenexposition
- Zugriffskontrollprobleme
- Sicherheitsfehlkonfiguration
Wann verwenden: Vor jeder Spec, die Authentifizierung, Autorisierung, Zahlungen oder Benutzerdaten betrifft.
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
Einen Sicherheitsbericht aus dem Audit-Log generieren — zeigt Bedrohungen, blockierte Aufrufe und Empfehlungen.
Was es erzeugt:
- Zusammenfassung der Sicherheitsereignisse aus dem Audit-Log
- Erkannte und blockierte Bedrohungen
- Offene Schwachstellen nach Schweregrad geordnet
- Behebungsempfehlungen
Wann verwenden: Für regelmäßige Sicherheitsüberprüfungen, Compliance-Pakete oder nach einem Sicherheitsvorfall.
Prompt: "Generate a security report for project proj_abc123"Lebende Specs
Lebende Specs bleiben automatisch mit deinem Code synchronisiert. Die folgenden Tools verwalten diese bidirektionale Synchronisierung.
living_spec_watch
Eine Spec auf Änderungen überwachen und automatisch mit Code synchronisieren, während sich die Implementierung weiterentwickelt.
Wann verwenden: Während der aktiven Implementierung einer Spec, um das Spec-Dokument ohne manuelle Abstimmung aktuell zu halten.
Prompt: "Start watching spec SPEC-007 in project proj_abc123"living_spec_status
Den Status der lebenden Spec-Synchronisierung abrufen — zeigt, welche Specs beobachtet werden und ihren letzten Sync-Zeitstempel.
Prompt: "Show living spec status for project proj_abc123"living_spec_coverage
Testabdeckungsanalyse für eine lebende Spec anzeigen — ordnet Testdateien Abnahmekriterien zu.
Wann verwenden: Um zu überprüfen, ob alle Kriterien in einer lebenden Spec entsprechende Tests haben, bevor sie als done markiert wird.
Prompt: "Show living spec coverage for SPEC-007 in project proj_abc123"sync_spec_to_code
Spec-Abnahmekriterien mit Code-Kommentaren und Tests synchronisieren — injiziert Kriterienreferenzen als strukturierte Kommentare in Implementierungsdateien.
Wann verwenden: Zu Beginn der Implementierung, um dem KI-Agenten (oder Entwickler) eine klare Verbindung zwischen Code und Kriterien zu geben.
Prompt: "Sync spec SPEC-007 criteria to the code in project proj_abc123"sync_code_to_spec
Code-Änderungen als lebende Dokumentation zurück in die Spec synchronisieren — aktualisiert die Spec, um widerzuspiegeln, was der Code tatsächlich tut.
Wann verwenden: Wenn die Implementierung von der ursprünglichen Spec abweicht, in einer Weise, die als neue Wahrheit erfasst werden sollte.
Prompt: "Sync code changes back to spec SPEC-007 in project proj_abc123"resolve_sync_conflict
Konflikte zwischen Spec und Code während der Synchronisierung lösen — präsentiert jeden Konflikt zur menschlichen Entscheidung.
Wann verwenden: Wenn sync_spec_to_code oder sync_code_to_spec Widersprüche erkennt, die menschliches Urteil erfordern.
Prompt: "Resolve sync conflicts for spec SPEC-007 in project proj_abc123"snapshot_spec_hashes
Einen Snapshot von Spec-Inhalts-Hashes für die Änderungsverfolgung erstellen — ermöglicht den Diff von Spec-Inhalten über die Zeit.
Wann verwenden: Vor einem größeren Refactoring oder einer Veröffentlichung, um eine Baseline für die Abweichungserkennung festzulegen.
Prompt: "Snapshot spec hashes for project proj_abc123"auto_reconcile
Specs automatisch mit Code-Änderungen mithilfe von Musterabgleich abgleichen — wendet erlernte Abstimmungsregeln ohne menschliches Eingreifen an.
Wann verwenden: Als Teil eines CI-Schritts, um Specs nach jedem Merge synchron zu halten.
Prompt: "Auto-reconcile all specs in project proj_abc123"validate_annotations
Annotationen in einer Spec auf Korrektheit und Vollständigkeit validieren — prüft, ob Kriterienreferenzen, Datei-Links und Metadaten gültig sind.
Prompt: "Validate annotations for spec SPEC-007 in project proj_abc123"generate_annotations
Annotationen für eine Spec basierend auf Best Practices generieren — fügt strukturierte Metadaten, Kriterienreferenzen und Rückverfolgbarkeitslinks hinzu.
Prompt: "Generate annotations for spec SPEC-007 in project proj_abc123"Siehe auch
- Spec-Lebenszyklus-Tools (Stream B) — Specs erstellen, aktualisieren und verwalten
- Design & Planungs-Tools (Stream D) — Architekturentscheidungen, Schemas, Ausführungspläne
- Plattform & Betriebs-Tools (Streams E–I) — Stack, Agenten, Git, Governance