Anforderungen und Design

Sobald der Product Owner die intent.md genehmigt, nimmt Claude sie und erstellt eine Anforderungs- und Design-Spezifikation. Dies wird durch die Skills der Organisation für Marke, Sicherheit, Compliance und UX geleitet.

Der Product Owner prüft diese Spezifikation, schreibt sie aber nicht. Das Ziel dieses Prozesses ist es, eine Spezifikation zu erstellen, gegen die das Engineering-Team planen kann, mit markierten Problembereichen.

Front-End-Arbeit ist das klarste Beispiel. Sobald die intent.md akzeptiert ist, entwirft der Product Owner das Design in Claude Design ausgehend von der intent.md, iteriert am Entwurf und exportiert ihn dann zum Bauen an Claude Code.

Was sich ändert

Erste Schritte

• Voraussetzungen: Schreibe eine intent.md-Datei, mit Marken-, Sicherheits-, Compliance- und UX-Richtlinien, die als Skills geschrieben sind.
• Infrastruktur: Ein Product Owner mit Claude-Zugang. Es ist keine Engineering-Kenntnis erforderlich.

Wie man es ausführt

1. Der Product Owner öffnet eine Session mit den verfügbaren Skills der Organisation und hängt die intent.md an.
2. Der Prompt des Product Owners verweist auf die Intent, benennt die Einschränkungen und fordert markierte Bedenken. Führe es zunächst manuell aus, kodifiziere es dann als organisationsweiten Slash-Befehl. Mache von dort aus die Annahme der intent.md im Intent-Home zum Auslöser, mit einem nicht-interaktiven Job, der beim Merge ausgelöst wird, den Durchlauf mit den geladenen Skills der Organisation ausführt und spec.md als Pull Request committet (der CI/CD-Ablauf in Stufe 5: Deploy behandelt die Verkabelung). Von diesem Punkt an ist die erste Beteiligung des Product Owners die Überprüfung.
3. Derselbe Product Owner prüft die Spezifikation gegen die Idee. Löst die Spezifikation das genannte Problem, und sind die offenen Fragen aus intent.md beantwortet oder weitergetragen?
4. Arbeite zuerst die markierten Bedenken durch, da dies die Punkte sind, die ein Analyst eskaliert hätte. Der Product Owner löst jeden davon mit dem jeweiligen Richtlinienverantwortlichen, bevor das Engineering die Spezifikation sieht.
5. Committe spec.md zusammen mit intent.md. Das Dateipaar hält fest, was angefragt und was entschieden wurde.
6. Der Product Owner entscheidet, ob Spezifikation und Intent zum Bau übergehen, und konsultiert dabei einen technischen Lead für alles, was die Organisation als höheres Risiko einstuft. Ein menschliches Teammitglied trifft diese Entscheidung immer, und die Annahme der Spezifikation ist das, was den Plan-Mode-Ablauf in Stufe 3: Build startet.

Wie es aussieht

Der Prompt:

Die intent.md hinter diesem Beispiel stammt von einem Versicherer, der möchte, dass Kunden den Status eines Schadensfalls in seinem Portal sehen können. Darin ist claims-api das Backend des Portals und claims-core das ältere interne System, das die Schadensfälle verwaltet. Der obige Prompt verwandelt sie in diese 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.

Die Anforderungen sind nummeriert, damit der Plan und die Überprüfung sie zitieren können. Bedenken 2 stellt zwei Skills gegeneinander, die Art von Konflikt, den der Prompt Claude anweist zu markieren.

Governance-Überlegungen

Anstatt dass Richtlinienkonflikte Wochen später in einer Überprüfung entdeckt werden, wird die aktuelle Richtlinie gelesen und angewendet, während die Spezifikation geschrieben wird. Die Skills der Organisation werden als Einschränkungen auf die Spezifikation angewendet. Die Spezifikation, der Prompt, der sie erzeugt hat, und die geltenden Skill-Versionen werden alle in der Versionskontrolle protokolliert. Der Product Owner zeichnet die Spezifikation ab und leitet markierte Bedenken an die benannten Richtlinienverantwortlichen weiter.

Wie man es misst

• Frühindikator: Verstrichene Zeit zwischen dem intent.md-Commit und dem spec.md-Commit für dieselbe Änderung (zwei Git-Zeitstempel), verglichen mit dem alten Anforderungs-plus-Design-Zyklus.
• Spätindikator: Anforderungs-Nacharbeit nach Baubeginn. Zähle spec.md-Commits, die nach dem ersten plan.md-Commit für dieselbe Änderung datiert sind. Das Git-Log liefert dies direkt.