Claude Academy
Wird geladen

Als intent.md erfassen

Lektion 24 Min.

Die intent.md, die den Softwareentwicklungsprozess einleitet, kann über verschiedene Wege entstehen. Eine Person hat eine Idee, ein Ticket wird eingereicht, oder ein Vorfall wird über eine Warnmeldung sichtbar (siehe Stage 6: Maintain).

Wenn eine Person eine Idee hat, brainstormt sie mit Claude und erstellt eine Markdown-Proto-Spezifikation. Im traditionellen SDLC muss dieselbe Person dann ein Mitglied des Produktteams überzeugen, die Idee gemeinsam mit ihr oder an ihrer Stelle aufzuschreiben.

Die von Claude erstellte Proto-Spezifikation ist menschenlesbar, versionskontrolliert und sofort von der nächsten Stage nutzbar. Die Proto-Spezifikation wird als intent.md gespeichert.

Unabhängig davon, ob die Intent von einem Ereignis-Trigger oder einer Person ausgeht, gelten dieselben Schritte: Der Product Owner überprüft und korrigiert die vom Agenten geschriebene intent.md, bevor sie committet wird.

Was sich ändert

TraditionellKI-nativ
Eine Idee durchläuft Backlog-Einträge, User Stories, Story Points und Refinement-Meetings, bevor jemand darauf reagieren kann. Die Eigentümerschaft wechselt bei jeder Übergabe, sodass das, was das Engineering erreicht, mehrere Schritte von dem entfernt ist, was der Urheber gemeint hat.Der Urheber brainstormt mit Claude und schreibt das Ergebnis als intent.md nieder, eine Proto-Spezifikation in den eigenen Worten des Urhebers. Das Artefakt enthält, was gewünscht wird, warum, und unter welchen Einschränkungen. Wiederkehrende Prozesse werden über Skills kodiert.

Erste Schritte

  • Voraussetzungen: Keine.
  • Infrastruktur: Claude-Zugang für Personen, die keine Engineers sind (claude.ai oder Cowork); eine vereinbarte intent.md-Vorlage; ein gemeinsam genutztes, versionskontrolliertes Zuhause für Intents, das der Product Owner beobachtet. Für ein einzelnes Produkt ist der einfachste Ort ein intent/-Ordner im Produkt-Repo. Dieses Setup hält die Artefaktkette in der Nähe des daraus abgeleiteten Codes. Ein dediziertes Intent-Repo lohnt sich nur, wenn Intent über viele Repositories hinweg reicht, und in einem Monorepo ist es ein Verzeichnis. Der Abschnitt zu veralteten Systemen in Stage 3: Build behandelt, wie dieses Zuhause mit einem Jira- oder Requirements-Tool zusammenhängt, das den Datensatz bereits führt.

Das Einrichten ist eine einmalige Aufgabe für das Platform- oder Engineering-Team. Ein technisches Teammitglied muss das Intent-Zuhause aufbauen und entscheiden, wer darauf schreiben darf, da viele Mitwirkende aus der gesamten Organisation kommen werden.

Sobald das Repository existiert, müssen Mitwirkende ohne Git-Erfahrung Git nicht direkt verwenden. Stattdessen ermöglicht ein Konnektor zum Versionskontrollsystem (z. B. GitHub) Claude, Markdown-Dateien in ihrem Namen von claude.ai oder Cowork aus zu committen.

So wird es umgesetzt

  1. Der Urheber beschreibt Claude das Problem in eigenen Worten. Der Urheber kann beschreiben, was er heute nicht tun kann, wer von der Idee betroffen ist, wie eine Verbesserung aussieht oder was außerhalb des Rahmens liegt. Es ist keine formale Sprache erforderlich.
  2. Brainstorme, bis die Idee konkret ist. Claude stellt die Fragen, die ein Analyst stellen würde: Umfang, Nutzer, Einschränkungen und wie Erfolg aussieht.
  3. Bitte Claude, das Ergebnis als intent.md unter Verwendung der Vorlage der Organisation zu schreiben, die als Skill kodiert werden kann, das von einem technischen Teammitglied eingerichtet und von einer Führungskraft abgesegnet wird. Dies kann das Problem, das vorgeschlagene Ergebnis, betroffene Nutzer und Systeme, Einschränkungen und offene Fragen abdecken.
  4. Der Urheber korrigiert alles, was Claude missverstanden hat.
  5. Committe intent.md in das gemeinsame Zuhause. Autor und Zeitstempel werden dem Datensatz hinzugefügt, und der Product Owner übernimmt die Idee von dort aus.

So sieht es aus

intent.md:

markdown
# 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?

Governance-Überlegungen

Der Nachweis ist die committete intent.md, die den Autor, den Zeitstempel und die vollständige Revisionshistorie aufführt. Sie wird in der Git-Historie des Intent-Zuhauses protokolliert. Der Product Owner genehmigt, und die Annahme- oder Ablehnungsentscheidung, die die Intent in Stage 2: Design überführt, wird als Merge oder als abschließender Review erfasst.

So wird es gemessen

  • Frühindikator: Zeit vom ersten Gespräch bis zu einer committeten intent.md, abgelesen aus der Git-Historie des Intent-Zuhauses, die Autor und Zeitstempel erfasst. Die Erwartung ist, dass dies von einem mehrwöchigen Erhebungs- und Verfeinerungszyklus auf Stunden sinkt.
  • Spätindikator: Die Überlebensrate, also der Anteil der intent.md-Dateien, die der Product Owner in Stage 2: Design übernimmt, anstatt sie zu schließen. Die Annahme- oder Ablehnungsentscheidung wird als Merge des Artefakts oder als geschlossener Review erfasst. Zähle zusätzlich die Änderungen an intent.md, die nach dem ersten spec.md-Commit für dieselbe Änderung vorgenommen wurden.