Requisitos y diseño

Una vez que el propietario del producto aprueba el intent.md, Claude lo toma y produce una especificación de requisitos y diseño. Esto se guía por las skills de la organización para marca, seguridad, cumplimiento y UX.

El propietario del producto revisa esa especificación, pero no la escribe. El objetivo de este proceso es crear una especificación contra la cual el equipo de ingeniería pueda planificar, con las áreas de preocupación marcadas.

El trabajo de front-end es el ejemplo más claro. Una vez que se acepta el intent.md, el propietario del producto crea la maqueta del diseño en Claude Design a partir del intent.md, itera sobre la maqueta y luego la exporta a Claude Code para construirla.

Qué cambia

Primeros pasos

• Requisitos previos: Escribe un archivo intent.md, con las políticas de marca, seguridad, cumplimiento y UX escritas como skills.
• Infraestructura: Un propietario de producto con acceso a Claude. No se requiere habilidad de ingeniería.

Cómo ejecutarlo

1. El propietario del producto abre una sesión con las skills de la organización disponibles y adjunta el intent.md.
2. La indicación del propietario del producto apunta a la intención, nombra las restricciones y exige que se marquen las preocupaciones. Ejecútala manualmente al principio, y luego codifícala como un comando de barra a nivel de organización. A partir de ahí, haz que la aceptación del intent.md en el hogar de la intención sea el disparador, con un trabajo no interactivo que se activa al hacer el merge, ejecuta el pase con las skills de la organización cargadas, y confirma spec.md como un pull request (la jugada de CI/CD en Etapa 5: Desplegar cubre la fontanería). A partir de ese punto, la primera participación del propietario del producto es la revisión.
3. El mismo propietario del producto revisa la especificación contra la idea. ¿La especificación resuelve el problema planteado, y las preguntas abiertas de intent.md están respondidas o se trasladan?
4. Trabaja primero en las preocupaciones marcadas, ya que son los puntos que un analista habría escalado. El propietario del producto resuelve cada una con su propietario de política antes de que ingeniería vea la especificación.
5. Confirma spec.md junto con intent.md. El par de archivos registra lo que se pidió y lo que se decidió.
6. El propietario del producto decide si la especificación y la intención avanzan a la construcción, consultando a un líder técnico para cualquier cosa que la organización clasifique como de mayor riesgo. Un compañero humano siempre toma esta decisión, y aceptar la especificación es lo que inicia la jugada del modo de planificación en Etapa 3: Construir.

Cómo se ve

La indicación:

El intent.md detrás de este ejemplo proviene de una aseguradora que quiere que los clientes vean el estado de un reclamo en su portal. En él, claims-api es el backend del portal y claims-core es el sistema interno más antiguo que contiene los reclamos. La indicación anterior lo convierte en este spec.md:

# Spec: claims status self-service
From: intent.md (J. Ortiz, claims operations). Status: ready for product owner review.
Skills applied: secure-api-review, brand-voice, portal-ux.

## Requirements
- R1. A signed-in customer sees status, next step and expected date for each open claim.
- R2. Status is one of four states: received, in review, approved, paid.
- R3. The response carries those three fields and nothing else.
- R4. What the customer sees is at most 60 seconds old.

## Design
- New endpoint GET /claims/{id}/status in claims-api, behind the gateway JWT.
- claims-api reads the claim from claims-core. The portal never calls claims-core.
- New StatusPanel on the portal claims page. It caches each answer for 60 seconds.

## How each constraint in the intent is met
| Constraint | Met by |
| :---- | :---- |
| No new PII in the portal session | R3. None of the three fields is tagged pii in the schema. |
| Existing authentication only | The gateway JWT. No new login, token or role. |

## Open questions from the intent
- Do third-party loss adjusters need access too? Not answered. Carried forward as concern 1.

## Areas of concern
1. Loss adjusters have no portal account. Giving them access breaks "existing
   authentication only", so they are left out of this spec. Owner: security.
2. The portal-ux skill says every status shows a date. The brand-voice skill says
   never to state a payment date as a commitment. I cannot satisfy both as written.
   Proposed label: "Estimated date". Owner: compliance.
3. claims-core allows 50 requests a second. The 60-second cache should keep the
   portal under that, but nobody has load tested it. Owner: claims-core team.

Los requisitos están numerados para que el plan y la revisión puedan citarlos. La preocupación 2 enfrenta dos skills entre sí, el tipo de choque que la indicación le dice a Claude que marque.

Consideraciones de gobernanza

En lugar de que los conflictos de políticas se descubran en una revisión semanas después, la política vigente se lee y se aplica mientras se escribe la especificación. Las skills de la organización se aplican como restricciones sobre la especificación. La especificación, la indicación que la produjo y las versiones de las skills vigentes quedan todas registradas en el control de versiones. El propietario del producto da su aprobación a la especificación y dirige las preocupaciones marcadas a los propietarios de política designados.

Cómo medirlo

• Indicador adelantado: Tiempo transcurrido entre el commit de intent.md y el commit de spec.md para el mismo cambio (dos marcas de tiempo de Git), comparado con el antiguo ciclo de requisitos más diseño.
• Indicador rezagado: Retrabajo de requisitos después de que comienza la construcción. Cuenta los commits de spec.md fechados después del primer commit de plan.md para el mismo cambio. El registro de Git dará esto directamente.