Analysis & Estimation Tools (Stream C)
Stream C contains 10 tools for understanding your codebase, estimating effort, detecting quality issues, and keeping specs aligned with reality.
estimate
Estimate effort, cost, and token usage for a spec using multi-agent analysis.
What it produces:
- Story point range (optimistic / realistic / pessimistic)
- Dollar cost range (based on
SDD_HOURLY_RATE) - Token usage estimate for AI-assisted implementation
- Risk factors affecting the estimate
- Breakdown by implementation phase
When to use: Before committing a spec to a sprint, or when communicating scope to stakeholders.
Prompt: "Estimate spec SPEC-003 for project proj_abc123"
Prompt: "How much effort is spec SPEC-007 in project proj_abc123?"reverse_engineer
Analyze existing code and generate an SDD spec from it.
When to use: When you have working code but no spec — common when onboarding legacy systems, or when a feature was built ad-hoc and now needs to be formally documented.
What it produces: A complete HU.md reverse-engineered from the code — acceptance criteria inferred from the implementation behavior, schema inferred from data models, and gaps identified where behavior is ambiguous.
Prompt: "Reverse engineer my codebase at /Users/me/my-app/src/auth and generate specs for project proj_abc123"validate
Validate implementation against its spec — coverage, drift, and quality.
What it checks:
- Which acceptance criteria are met by the code
- Which are missing or only partially implemented
- Overall coverage percentage
- Suggestions for closing gaps
When to use: After completing implementation, before marking a spec done.
Prompt: "Validate spec SPEC-001 against the code at /Users/me/my-app/src for project proj_abc123"detect_drift
Detect drift between spec and implementation — includes Constitution compliance and downstream spec impact analysis.
What it reports:
- Criteria that no longer match the code
- New code patterns not covered by any spec
- Constitution violations introduced since last check
- Downstream specs affected by the drift (cascading impact)
When to use: Periodically as the codebase evolves, or before any major release.
Prompt: "Detect drift in spec SPEC-003 for project proj_abc123"
Prompt: "Check if my implementation matches SPEC-001 spec"audit
Audit code for SOLID, clean code, architecture, and Constitution violations. Generates a quality score 0–100.
Score breakdown:
- SOLID principles compliance
- Clean code metrics (naming, function size, coupling)
- Architecture layer compliance
- Constitution adherence
- Test coverage signals
When to use: During code review, before merging, or as a periodic codebase health check.
Prompt: "Audit the code at /Users/me/my-app/src for project proj_abc123"learn_pattern
Teach the system a new pattern — architecture convention, estimation heuristic, stack decision, or quality rule.
Pattern types: architecture, convention, estimation, stack, quality
When to use: When your team has established a pattern that SpecForge should apply when generating specs, plans, or estimates.
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
Analyze a spec against OWASP Top 10, scan code for insecure patterns, and generate a security score (A–F) with drift detection.
What it checks:
- Injection vulnerabilities (SQL, command, LDAP)
- Authentication and session management
- Sensitive data exposure
- Access control issues
- Security misconfiguration
When to use: Before any spec involving authentication, authorization, payments, or user data.
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
Capture a discovered pattern or lesson into the spec system with semantic deduplication.
When to use: After a bug post-mortem, a painful estimation error, or any workflow discovery you want to apply to future specs.
SpecForge deduplicates against existing patterns so you don't accumulate redundant rules.
Prompt: "Capture learning: when integrating third-party OAuth, always verify token expiry handling with an explicit test"paradigm_report
Detect and report the programming paradigms used in a project — functional, OOP, reactive, event-driven, declarative, etc.
When to use: When onboarding to an unfamiliar codebase, or when establishing coding standards that should be enforced in specs.
Prompt: "Generate a paradigm report for project proj_abc123"reality_check
Evaluate whether a set of requirements is feasible given the project context.
What it evaluates:
- Technical feasibility given the current stack
- Dependency constraints
- Timeline realism based on historical estimates
- Risks that could block delivery
When to use: Before committing to a deadline, or when a stakeholder requests something that seems unrealistic.
Prompt: "Reality check: can we build a real-time collaborative editor in 2 weeks for project proj_abc123?"