Zum Hauptinhalt springen

to-spec: Das Gespräch zur Spec verdichten

Hauptfluss⌨️ Nur manuell (/name)🔧 Angepasst für unser SetupHerunterladen ↓

Verdichtet das aktuelle Gespräch und das Codebase-Verständnis zu einer Spec. Kein neues Interview, reine Synthese dessen, was schon besprochen wurde.

Wann brauche ich das?​

Nachdem eine Idee in grill-me ausreichend geschärft wurde und mehrere Sitzungen für die Umsetzung nötig sind.

Wie funktioniert das?​

  1. Codebase verstehen (falls noch nicht geschehen), Domain-Vokabular und ADRs berücksichtigen.
  2. Die Testnähte skizzieren, möglichst wenige, möglichst hoch im Stack, im Idealfall genau eine. Mit dir abstimmen, ob das passt.
  3. Die Spec nach dem Template unten schreiben.

Kein Auto-Publish. Im Original wird die Spec automatisch auf den Issue-Tracker publiziert und mit einem Label versehen, das geht ohne Jira-Anbindung nicht. Die Spec kommt stattdessen als fertiger Markdown-Block, den du selbst in Jira einfügst.

## Problemstellung

Das Problem aus Sicht des Nutzers.

## Lösung

Die Lösung aus Sicht des Nutzers.

## User Stories

Eine LANGE, nummerierte Liste: "Als <Rolle>, möchte ich <Fähigkeit>, damit <Nutzen>."

## Umsetzungsentscheidungen

Betroffene Module, geänderte Schnittstellen, technische Klärungen, Architekturentscheidungen,
Schema-Änderungen, API-Verträge. Keine konkreten Dateipfade oder Code, die veralten schnell.
Ausnahme: ein Prototyp-Snippet, das eine Entscheidung präziser kodiert als Prosa.

## Test-Entscheidungen

Was einen guten Test ausmacht, welche Module getestet werden, Vorbilder im Code.

## Außerhalb des Scopes

## Weitere Notizen

Wo passt das rein?​

Kettenschritt im Hauptfluss nach grill-me, mündet in to-tickets. Gesamtüberblick: ask-simon.

Was sich gegenüber dem Original geändert hat​

Kein automatisches Publizieren und Labeln auf dem Tracker, die fertige Spec kommt als Text zum manuellen Einfügen in Jira.