Exigences et conception

Une fois que le product owner approuve le fichier intent.md, Claude le prend en charge et produit une spécification d'exigences et de conception. Ce processus est guidé par les Compétences de l'organisation en matière de marque, de sécurité, de conformité et d'UX.

Le product owner examine cette spécification, mais ne la rédige pas. L'objectif de ce processus est de créer une spécification sur laquelle l'équipe d'ingénierie peut planifier, avec les points de préoccupation signalés.

Le travail front-end en est l'exemple le plus clair. Une fois le fichier intent.md accepté, le product owner élabore la maquette de conception dans Claude Design à partir de intent.md, itère sur la maquette, puis l'exporte vers Claude Code pour la construction.

Ce qui change

Pour commencer

• Prérequis : Rédiger un fichier intent.md, avec les politiques de marque, de sécurité, de conformité et d'UX rédigées sous forme de Compétences.
• Infrastructure : Un product owner ayant accès à Claude. Aucune compétence en ingénierie n'est requise.

Comment l'exécuter

1. Le product owner ouvre une session avec les Compétences de l'organisation disponibles et joint le fichier intent.md.
2. Le prompt du product owner pointe vers l'intention, nomme les contraintes et exige que les préoccupations soient signalées. Exécutez-le d'abord manuellement, puis codifiez-le en tant que commande slash au niveau de l'organisation. À partir de là, faites de l'acceptation de intent.md dans le dépôt d'intentions le déclencheur, avec une tâche non interactive qui se déclenche lors de la fusion, exécute la passe avec les Compétences de l'organisation chargées, et valide spec.md sous forme de pull request (le scénario CI/CD dans Étape 5 : Déployer couvre la plomberie). À partir de ce moment, la première implication du product owner est la revue.
3. Le même product owner examine la spécification par rapport à l'idée. La spécification résout-elle le problème énoncé, et les questions ouvertes de intent.md sont-elles répondues ou reportées ?
4. Traitez d'abord les préoccupations signalées, car ce sont les points qu'un analyste aurait escaladés. Le product owner résout chacune d'elles avec le responsable de la politique concernée avant que l'équipe d'ingénierie ne voie la spécification.
5. Validez spec.md aux côtés de intent.md. Cette paire de fichiers enregistre ce qui a été demandé et ce qui a été décidé.
6. Le product owner décide si la spécification et l'intention passent à la construction, en consultant un responsable technique pour tout ce que l'organisation classe comme à risque plus élevé. Un coéquipier humain prend toujours cette décision, et l'acceptation de la spécification est ce qui déclenche le scénario du mode plan dans Étape 3 : Construire.

À quoi cela ressemble

Le prompt :

Le fichier intent.md à l'origine de cet exemple provient d'un assureur qui souhaite que ses clients puissent consulter le statut d'une réclamation dans son portail. Dans ce cas, claims-api est le backend du portail et claims-core est l'ancien système interne qui détient les réclamations. Le prompt ci-dessus le transforme en ce 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.

Les exigences sont numérotées afin que le plan et la revue puissent les citer. La préoccupation 2 met deux Compétences en opposition, le type de conflit que le prompt demande à Claude de signaler.

Considérations de gouvernance

Plutôt que de découvrir des conflits de politiques lors d'une revue des semaines plus tard, la politique en vigueur est lue et appliquée au moment même où la spécification est rédigée. Les Compétences de l'organisation sont appliquées comme contraintes sur la spécification. La spécification, le prompt qui l'a produite, et les versions des Compétences en vigueur sont tous enregistrés dans le contrôle de version. Le product owner approuve la spécification et achemine les préoccupations signalées vers les responsables de politique désignés.

Comment le mesurer

• Indicateur avancé : Temps écoulé entre la validation de intent.md et la validation de spec.md pour le même changement (deux horodatages Git), comparé à l'ancien cycle exigences-plus-conception.
• Indicateur retardé : Retravail des exigences après le début de la construction. Comptez les validations de spec.md datées après la première validation de plan.md pour le même changement. Le journal Git fournira cette information directement.