Skip to content

Herramientas de Análisis y Estimación (Stream C)

El Stream C contiene 10 herramientas para entender tu codebase, estimar esfuerzo, detectar problemas de calidad y mantener las specs alineadas con la realidad.

estimate

Estima esfuerzo, costo y uso de tokens para una spec usando análisis multi-agente.

Qué produce:

  • Rango de story points (optimista / realista / pesimista)
  • Rango de costo en dólares (basado en SDD_HOURLY_RATE)
  • Estimación de uso de tokens para implementación asistida por IA
  • Factores de riesgo que afectan la estimación
  • Desglose por fase de implementación

Cuándo usarlo: Antes de comprometer una spec a un sprint, o al comunicar el alcance a stakeholders.

Prompt: "Estimate spec SPEC-003 for project proj_abc123"
Prompt: "How much effort is spec SPEC-007 in project proj_abc123?"

reverse_engineer

Analiza código existente y genera una spec SDD a partir de él.

Cuándo usarlo: Cuando tienes código funcionando pero sin spec — común al incorporar sistemas legacy, o cuando una feature fue construida ad-hoc y ahora necesita documentación formal.

Qué produce: Un HU.md completo generado por ingeniería inversa del código — criterios de aceptación inferidos del comportamiento de la implementación, esquema inferido de los modelos de datos, y brechas identificadas donde el comportamiento es ambiguo.

Prompt: "Reverse engineer my codebase at /Users/me/my-app/src/auth and generate specs for project proj_abc123"

validate

Valida la implementación contra su spec — cobertura, drift y calidad.

Qué verifica:

  • Qué criterios de aceptación cumple el código
  • Cuáles faltan o están solo parcialmente implementados
  • Porcentaje de cobertura global
  • Sugerencias para cerrar las brechas

Cuándo usarlo: Después de completar la implementación, antes de marcar una spec como done.

Prompt: "Validate spec SPEC-001 against the code at /Users/me/my-app/src for project proj_abc123"

detect_drift

Detecta drift entre la spec y la implementación — incluye cumplimiento de la Constitución y análisis de impacto en specs downstream.

Qué reporta:

  • Criterios que ya no coinciden con el código
  • Nuevos patrones de código no cubiertos por ninguna spec
  • Violaciones de la Constitución introducidas desde el último chequeo
  • Specs downstream afectadas por el drift (impacto en cascada)

Cuándo usarlo: Periódicamente a medida que el codebase evoluciona, o antes de cualquier release importante.

Prompt: "Detect drift in spec SPEC-003 for project proj_abc123"
Prompt: "Check if my implementation matches SPEC-001 spec"

audit

Audita código para detectar violaciones de SOLID, clean code, arquitectura y Constitución. Genera un score de calidad 0–100.

Desglose del score:

  • Cumplimiento de principios SOLID
  • Métricas de clean code (naming, tamaño de funciones, acoplamiento)
  • Cumplimiento de capas de arquitectura
  • Adherencia a la Constitución
  • Señales de cobertura de tests

Cuándo usarlo: Durante code review, antes de mergear, o como chequeo periódico de salud del codebase.

Prompt: "Audit the code at /Users/me/my-app/src for project proj_abc123"

learn_pattern

Enseña al sistema un nuevo patrón — convención de arquitectura, heurística de estimación, decisión de stack o regla de calidad.

Tipos de patrones: architecture, convention, estimation, stack, quality

Cuándo usarlo: Cuando tu equipo ha establecido un patrón que SpecForge debería aplicar al generar specs, planes o estimaciones.

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

Analiza una spec contra el OWASP Top 10, escanea el código en busca de patrones inseguros y genera un score de seguridad (A–F) con detección de drift.

Qué verifica:

  • Vulnerabilidades de inyección (SQL, comandos, LDAP)
  • Autenticación y gestión de sesiones
  • Exposición de datos sensibles
  • Problemas de control de acceso
  • Mala configuración de seguridad

Cuándo usarlo: Antes de cualquier spec que involucre autenticación, autorización, pagos o datos de usuario.

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

Captura un patrón descubierto o lección en el sistema de specs con deduplicación semántica.

Cuándo usarlo: Después de un post-mortem de bug, un error doloroso de estimación, o cualquier descubrimiento de workflow que quieras aplicar a specs futuras.

SpecForge deduplica contra patrones existentes para que no acumules reglas redundantes.

Prompt: "Capture learning: when integrating third-party OAuth, always verify token expiry handling with an explicit test"

paradigm_report

Detecta y reporta los paradigmas de programación usados en un proyecto — funcional, OOP, reactivo, event-driven, declarativo, etc.

Cuándo usarlo: Al incorporarse a un codebase desconocido, o al establecer estándares de código que deben aplicarse en las specs.

Prompt: "Generate a paradigm report for project proj_abc123"

reality_check

Evalúa si un conjunto de requisitos es factible dado el contexto del proyecto.

Qué evalúa:

  • Factibilidad técnica dado el stack actual
  • Restricciones de dependencias
  • Realismo del cronograma basado en estimaciones históricas
  • Riesgos que podrían bloquear la entrega

Cuándo usarlo: Antes de comprometerse con una fecha límite, o cuando un stakeholder solicita algo que parece poco realista.

Prompt: "Reality check: can we build a real-time collaborative editor in 2 weeks for project proj_abc123?"