Analyse- & Schätzungs-Tools (Stream C)
Stream C enthält 10 Tools zum Verstehen deiner Codebasis, zum Schätzen von Aufwand, zum Erkennen von Qualitätsproblemen und zum Ausrichten von Specs mit der Realität.
estimate
Aufwand, Kosten und Token-Nutzung für eine Spec mit Multi-Agenten-Analyse schätzen.
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?"reverse_engineer
Bestehenden Code analysieren und eine SDD-Spec daraus generieren.
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 HU.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 /Users/me/my-app/src/auth and generate specs for project proj_abc123"validate
Implementierung gegen ihre Spec validieren — Abdeckung, Abweichung und Qualität.
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 /Users/me/my-app/src for project proj_abc123"detect_drift
Abweichungen zwischen Spec und Implementierung erkennen — einschließlich Verfassungs-Compliance und nachgelagerter Spec-Auswirkungsanalyse.
Was berichtet wird:
- Kriterien, die nicht mehr mit dem Code übereinstimmen
- Neue Code-Muster, die von keiner Spec abgedeckt werden
- Verstöße gegen die Verfassung seit der letzten Prüfung
- 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 SPEC-001 spec"audit
Code auf SOLID, sauberen Code, Architektur und Verstöße gegen die Verfassung prüfen. 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 /Users/me/my-app/src for project proj_abc123"learn_pattern
Dem System ein neues Muster beibringen — Architekturkonvention, Schätzungsheuristik, Stack-Entscheidung oder Qualitätsregel.
Mustertypen: architecture, convention, estimation, stack, quality
Wann verwenden: Wenn dein Team ein Muster etabliert hat, das SpecForge beim Generieren von Specs, Plänen oder Schätzungen anwenden soll.
Prompt: "Teach specforge 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"security_check
Eine Spec gegen OWASP Top 10 analysieren, Code auf unsichere Muster scannen und einen Sicherheits-Score (A–F) mit Abweichungserkennung generieren.
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 /Users/me/my-app/src/api for project proj_abc123"capture_learning
Ein entdecktes Muster oder eine Erkenntnis mit semantischer Deduplizierung in das Spec-System aufnehmen.
Wann verwenden: Nach einer Bug-Post-Mortem-Analyse, einem schmerzhaften Schätzungsfehler oder einer Workflow-Entdeckung, die auf zukünftige Specs angewendet werden soll.
SpecForge 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
Die in einem Projekt verwendeten Programmierparadigmen erkennen und berichten — 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
Prüfen, ob eine Reihe von Anforderungen angesichts des Projektkontexts machbar ist.
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?"