Analysis & Estimation Tools (Stream C)
Stream C tools help you understand your codebase, estimate effort, detect quality issues, and keep specs aligned with reality.
Quick Reference
| Tool | Description | Availability |
|---|---|---|
estimate | Calculate time, effort, and cost to build a feature | Included |
estimate_ai_cost | Estimate the AI token costs for implementing a spec | Included |
validate | Check how much of a plan has actually been built | Included |
detect_drift | Detect where implementation diverges from an approved spec | Included |
validate_workflow | Validate that the development workflow matches the intended process | Included |
audit | Comprehensive audit of project configuration, architecture, and compliance | Included |
audit_stack | Analyze the tech stack for compatibility, security, and performance issues | Included |
audit_trail | Query the immutable audit log | Included |
generate_attestation | Generate a compliance attestation document for a spec | Included |
reverse_engineer | Reverse-engineer a spec from existing code | Included |
scan_project | Scan entire project and analyze modules in parallel | Included |
learn_pattern | Capture a learned pattern or best practice from your codebase | Included |
capture_learning | Capture a pattern from implementation experience | Included |
paradigm_report | Report on architectural paradigms and patterns in the project | Included |
reality_check | Validate a plan against real-world constraints and assumptions | Included |
security_check | Run a comprehensive security analysis on the codebase and specs | Included |
security_report | Generate a security report from the audit log | Included |
living_spec_watch | Watch a spec for changes and auto-sync with code | Included |
living_spec_status | Get the status of living spec synchronization | Included |
living_spec_coverage | Show test coverage analysis for a living spec | Included |
sync_spec_to_code | Sync spec acceptance criteria to code comments and tests | Included |
sync_code_to_spec | Sync code changes back to the spec as living documentation | Included |
resolve_sync_conflict | Resolve conflicts between spec and code during synchronization | Included |
snapshot_spec_hashes | Create a snapshot of spec content hashes for change tracking | Included |
auto_reconcile | Automatically reconcile specs with code changes using pattern matching | Included |
validate_annotations | Validate annotations in a spec for correctness and completeness | Included |
generate_annotations | Generate annotations for a spec based on best practices | Included |
Estimation
estimate
Calculate time, effort, and cost to build a feature based on its plan.
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?"estimate_ai_cost
Estimate the AI token costs for implementing a spec — broken down by model, phase, and complexity.
What it produces:
- Token count estimate per implementation phase
- Cost breakdown by model (GPT-4, Claude, etc.)
- Complexity multipliers and risk factors
- Comparison across different AI models
When to use: When budgeting AI-assisted development, or when choosing which model to use for implementation.
Prompt: "Estimate AI cost for spec SPEC-003 in project proj_abc123"Validation
validate
Check how much of a plan has actually been built. Compares spec acceptance criteria with real code.
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 /workspace/my-app/src for project proj_abc123"detect_drift
Analyze code changes against an approved spec and highlight where implementation diverges.
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 the SPEC-001 spec"validate_workflow
Validate that the development workflow matches the intended process — checks that spec status transitions, review gates, and team practices follow the configured workflow.
When to use: When onboarding a new team to Planu, or after a process change to verify adoption.
Prompt: "Validate the development workflow for project proj_abc123"Audit
audit
Comprehensive audit of project configuration, architecture, and compliance. 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 /workspace/my-app/src for project proj_abc123"audit_stack
Analyze the current tech stack for compatibility, security, and performance issues.
What it checks:
- Dependency version compatibility
- Known CVEs and security advisories
- Performance anti-patterns in the chosen stack
- Suggestions for upgrades or replacements
When to use: During quarterly reviews or before a major release to catch hidden risks in the dependency tree.
Prompt: "Audit the tech stack for project proj_abc123"audit_trail
Query the immutable audit log. Filter by specId, userId, eventType, and date range.
What it returns:
- Chronological log of all spec changes and status transitions
- Who triggered each event and when
- Tool calls that produced the changes
- Exportable for compliance purposes
When to use: During security audits, compliance reviews, or when investigating a 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
Generate a compliance attestation document for a specific spec — confirms that all acceptance criteria were met, reviewed, and validated.
What it produces:
- Signed attestation with spec ID and criteria summary
- Timestamp of validation run
- Coverage percentage and any open exceptions
- Ready for inclusion in compliance packages
When to use: When a spec must pass a formal compliance review before release (SOC 2, HIPAA, ISO 27001, etc.).
Prompt: "Generate an attestation for spec SPEC-010 in project proj_abc123"Reverse Engineering & Scanning
reverse_engineer
Reverse-engineer a spec from existing code.
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 formal documentation.
What it produces: A complete spec.md reverse-engineered from the code — acceptance criteria inferred from implementation behavior, schema inferred from data models, and gaps identified where behavior is ambiguous.
Prompt: "Reverse engineer my codebase at /workspace/my-app/src/auth and generate specs for project proj_abc123"scan_project
Scan the entire project, discover modules, analyze each in parallel, and detect cross-module dependencies and antipatterns.
What it produces:
- Module map with dependency graph
- Cross-cutting concerns and coupling issues
- Antipattern detection (God objects, circular deps, leaky abstractions)
- Spec coverage gaps per module
When to use: When onboarding to a large unfamiliar codebase, or before a major refactor.
TIP
scan_project is the fastest way to understand an existing codebase. Run it before creating any specs on a legacy project.
Prompt: "Scan the project at /workspace/my-app for proj_abc123"Learning
learn_pattern
Capture a learned pattern or best practice from your codebase for reuse across future specs.
Pattern types: architecture, convention, estimation, stack, quality
When to use: When your team has established a pattern that Planu should apply when generating specs, plans, or estimates.
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
Capture a learned pattern or improvement opportunity from implementation experience — 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.
Planu 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
Generate a report on architectural paradigms and patterns in the 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
Validate a plan against real-world constraints and assumptions.
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?"Security
security_check
Run a comprehensive security analysis on the codebase and specs — OWASP Top 10, insecure patterns, and 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 /workspace/my-app/src/api for project proj_abc123"security_report
Generate a security report from the audit log — shows threats, blocked calls, and recommendations.
What it produces:
- Summary of security events from the audit log
- Threats detected and blocked
- Open vulnerabilities ranked by severity
- Remediation recommendations
When to use: For periodic security reviews, compliance packages, or after a security incident.
Prompt: "Generate a security report for project proj_abc123"Living Specs
Living specs stay synchronized with your code automatically. The tools below manage that two-way sync.
living_spec_watch
Watch a spec for changes and auto-sync with code as the implementation evolves.
When to use: During active implementation of a spec to keep the spec document up to date without manual reconciliation.
Prompt: "Start watching spec SPEC-007 in project proj_abc123"living_spec_status
Get the status of living spec synchronization — shows which specs are being watched and their last sync timestamp.
Prompt: "Show living spec status for project proj_abc123"living_spec_coverage
Show test coverage analysis for a living spec — maps test files to acceptance criteria.
When to use: To verify that all criteria in a living spec have corresponding tests before marking it done.
Prompt: "Show living spec coverage for SPEC-007 in project proj_abc123"sync_spec_to_code
Sync spec acceptance criteria to code comments and tests — injects criteria references as structured comments into implementation files.
When to use: At the start of implementation to give the AI agent (or developer) a clear link between code and criteria.
Prompt: "Sync spec SPEC-007 criteria to the code in project proj_abc123"sync_code_to_spec
Sync code changes back to the spec as living documentation — updates the spec to reflect what the code actually does.
When to use: After implementation diverges from the original spec in ways that should be captured as the new truth.
Prompt: "Sync code changes back to spec SPEC-007 in project proj_abc123"resolve_sync_conflict
Resolve conflicts between spec and code during synchronization — presents each conflict for human decision.
When to use: When sync_spec_to_code or sync_code_to_spec detects contradictions that require human judgment.
Prompt: "Resolve sync conflicts for spec SPEC-007 in project proj_abc123"snapshot_spec_hashes
Create a snapshot of spec content hashes for change tracking — enables diffing spec content over time.
When to use: Before a major refactor or release to establish a baseline for drift detection.
Prompt: "Snapshot spec hashes for project proj_abc123"auto_reconcile
Automatically reconcile specs with code changes using pattern matching — applies learned reconciliation rules without human intervention.
When to use: As part of a CI step to keep specs aligned after every merge.
Prompt: "Auto-reconcile all specs in project proj_abc123"validate_annotations
Validate annotations in a spec for correctness and completeness — checks that criteria references, file links, and metadata are valid.
Prompt: "Validate annotations for spec SPEC-007 in project proj_abc123"generate_annotations
Generate annotations for a spec based on best practices — adds structured metadata, criteria references, and traceability links.
Prompt: "Generate annotations for spec SPEC-007 in project proj_abc123"See Also
- Spec Lifecycle Tools (Stream B) — create, update, and manage specs
- Design & Planning Tools (Stream D) — architecture decisions, schemas, execution plans
- Platform & Operations Tools (Streams E–I) — stack, agents, git, governance