Capturar como intent.md

El intent.md, que da inicio al proceso de desarrollo de software, puede ingresar por diferentes vías. Una persona tiene una idea, se presenta un ticket, o se detecta un incidente mediante una alerta (ver Etapa 6: Mantener).

Cuando una persona tiene una idea, hace una lluvia de ideas con Claude y produce un proto-spec en Markdown. En el SDLC tradicional, esa misma persona debe luego convencer a un miembro del equipo de producto para que redacte la idea junto con ella o en su nombre.

El proto-spec generado por Claude es legible para humanos, está bajo control de versiones, y es inmediatamente consumible por la siguiente etapa. El proto-spec se guarda como un intent.md.

Independientemente de si la intención se origina a partir de un evento disparador o de una persona, se aplican los mismos pasos: el propietario del producto revisa y corrige el intent.md escrito por el agente antes de que se confirme (commit).

Qué cambia

Primeros pasos

• Prerrequisitos: Ninguno.
• Infraestructura: Acceso a Claude para personas que no son ingenieros (claude.ai o Cowork); una plantilla de intent.md acordada; un hogar compartido y bajo control de versiones para la intención que el propietario del producto supervisa. Para un solo producto, el hogar más simple es una carpeta intent/ en el repositorio del producto. Esta configuración mantiene la cadena de artefactos junto al código derivado de ella. Un repositorio de intención dedicado solo vale la sobrecarga cuando la intención abarca muchos repositorios, y en un monorepo es un directorio. La sección de Sistemas heredados en Etapa 3: Construir explica cómo este hogar se relaciona con una herramienta como Jira o de requisitos que ya contiene el registro.

Configurar esto es una tarea única para el equipo de plataforma o de ingeniería. Un miembro técnico del equipo necesita establecer el hogar de la intención y decidir quién puede escribir en él, ya que muchos colaboradores provendrán de distintas partes de la organización.

Una vez que el repositorio existe, los colaboradores sin experiencia en Git no necesitan usar Git directamente. En su lugar, un conector al sistema de control de versiones (por ejemplo, GitHub) permite que Claude confirme (commit) archivos Markdown en su nombre desde claude.ai o Cowork.

Cómo ejecutarlo

1. El originador describe el problema a Claude con sus propias palabras. El originador puede describir qué no puede hacer hoy, a quién afecta la idea, cómo se ve algo mejor, o qué queda fuera del alcance. No se requiere lenguaje formal.
2. Haz una lluvia de ideas hasta que la idea sea concreta. Claude hace las preguntas que haría un analista: alcance, usuarios, restricciones, y cómo se ve el éxito.
3. Pide a Claude que escriba el resultado como intent.md usando la plantilla de la organización, que puede codificarse como un conjunto de skills configurado por un miembro técnico del equipo y aprobado por un líder. Esto puede cubrir el problema, el resultado propuesto, los usuarios y sistemas afectados, las restricciones, y las preguntas abiertas.
4. El originador corrige cualquier cosa que Claude haya malinterpretado.
5. Confirma (commit) intent.md en el hogar compartido. El autor y la marca de tiempo se unen al registro, y el propietario del producto retoma la idea a partir de ahí.

Cómo se ve

intent.md:

# Intent: claims status self-service
Author: J. Ortiz (claims operations). Status: draft.
## Problem
Customers phone the contact center to ask where their claim is.
Handlers spend roughly a third of call time on status-only queries.
## Proposed outcome
Customers see claim status, next step and expected date in the portal.
## Affected users and systems
Claims handlers, portal team, claims-core API.
## Constraints
No new PII in the portal session. Existing authentication only.
## Open questions
Do third-party loss adjusters need access too?

Consideraciones de gobernanza

La evidencia es el intent.md confirmado (committed), que enumera al autor, la marca de tiempo, y el historial completo de revisiones. Queda registrado en el historial de Git del hogar de la intención. El propietario del producto aprueba, y la decisión de aceptar o rechazar que envía la intención a la Etapa 2: Diseñar se registra como el merge o la revisión de cierre.

Cómo medirlo

• Indicador adelantado: Tiempo desde la primera conversación hasta un intent.md confirmado (committed), leído del historial de Git en el hogar de la intención, que registra al autor y la marca de tiempo. La expectativa es que esto disminuya de un ciclo de obtención y refinamiento de varias semanas a horas.
• Indicador rezagado: La tasa de supervivencia, o la proporción de archivos intent.md que el propietario del producto acepta hacia la Etapa 2: Diseñar en lugar de cerrar. La decisión de aceptar o rechazar se registra como el merge del artefacto o la revisión cerrada. Además, cuenta los cambios realizados en intent.md después del primer commit de spec.md para el mismo cambio.