Ein offenes Format für Arbeit, die jemand baut, der nicht fragen kann.

Warum ein Standard

Zwanzig Jahre lang wurden Tickets von Menschen gelesen, die das Produkt kannten. Stand in einer Story „Berichte exportieren“, wusste die Entwicklerin, welche Berichte gemeint waren, fragte kurz nach dem Format und fing die Rechtefrage im Review ab. Das Ticket war die Erinnerung an ein Gespräch.

Agenten führen dieses Gespräch nicht. Sie lesen, was dasteht, füllen jede Lücke mit der plausibelsten Antwort und liefern sie mit voller Überzeugung. Das Problem ist kein schlechter Code. Es ist eine gute Umsetzung einer Vermutung.

Der Brief-Standard ist ein kleines, offenes Format für Arbeit, die so geschrieben ist, dass jemand sie bauen kann, der nicht nachfragen kann: ein Agent, eine Freelancerin, ein neues Teammitglied oder Sie selbst in sechs Monaten. Er ist reines Markdown und funktioniert in jedem Tool. NEWWORK Projects bewertet ihn, aber Sie brauchen NEWWORK Projects nicht, um ihn zu nutzen.

Fünf Prinzipien

1. Schreiben Sie für jemanden, der nicht nachfragen kann. Alles, was gebraucht wird, steht im Brief oder ist dort verlinkt.
2. Fragen statt raten. Was die Autorin nicht weiß, wird eine offene Frage oder eine Annahme zum Behalten oder Streichen, nie eine selbstsichere Antwort.
3. Kontext ist ein Link, keine Erinnerung. Nennen Sie Repository, Datei, Dokument, Bildschirm.
4. Fertig wird bewiesen. Jedes Akzeptanzkriterium ist beobachtbar und wird mit dem Nachweis abgehakt, der es belegt.
5. Klein genug zum Beweisen. Passen die Kriterien nicht auf einen Bildschirm, ist es ein Epic.

Das Format

Ein Brief ist Markdown mit ##-Abschnitten. Die Überschriften sind in jeder Sprache englisch, damit Tools sie finden; der Text ist in der Sprache, in der das Team schreibt. Abschnitte, die nicht passen, fallen weg, statt mit „k. A.“ gefüllt zu werden. Die deutschen Überschriften unten werden ebenfalls erkannt.

Stories und Features

Andere Typen

• Bugs: Steps to reproduce, Expected, Actual, dazu Context (Version, Browser, Konto) und Akzeptanzkriterien. „Behoben wenn“ funktioniert als Überschrift für die Kriterien.
• Tasks: What to do, konkret genug, um sofort anzufangen, dazu Kontext und Kriterien.
• Epics: Intent, Scope und Capabilities; die Stories darunter tragen die Kriterien.
• Initiativen: Intent, Success measures, Milestones und Risks.
• Change Requests: eine Story mit Auftraggeber, dessen Referenz und Preis, entschieden bevor die Arbeit beginnt.

Akzeptanzkriterien

Ein Kriterium ist eine Aussage, deren Erfüllung jemand anderes beobachten kann. Es ist keine Aufgabe („Export-Button hinzufügen“) und kein Wunsch („soll schnell sein“).

• Ein Kriterium pro Zeile, unter einer Überschrift wie ## Acceptance checks oder ## Akzeptanzkriterien.
• Konkret und beobachtbar: „10.000 Zeilen in unter 2 Sekunden exportiert“, nicht „performant“.
• Given / when / then ist willkommen, aber keine Pflicht.
• Nehmen Sie die Rechteprüfung auf. Sie wird am häufigsten vergessen, und Agenten raten sie nie richtig.

Tools erkennen ein Kriterium, das nicht beobachtbar ist, an seiner Formulierung. Ein Kriterium, das wie eine Anweisung beginnt (Füge, Implementiere, Erstelle, Baue, Behebe, Schreibe; Add, Implement, Create, Fix …), ist eine Aufgabe. Ein Kriterium, das das Ergebnis dem Geschmack überlässt (schnell, benutzerfreundlich, intuitiv, korrekt, sauber, wie erwartet, besser, „funktioniert“), ist ein Wunsch, außer eine Zahl macht es fest. „Der Export ist schnell“ ist ein Wunsch; „Der Export ist schnell: 10.000 Zeilen in unter 2 Sekunden“ ist ein Kriterium.

Ein Kriterium ist nur mit Nachweis bestanden:

Agenten müssen einen Nachweis anhängen, um ein Kriterium zu bestehen. Ein nicht bestandenes Kriterium sagt, was fehlschlug.

Testen

Jedes Akzeptanzkriterium ist ein Testfall: Es sagt, was wahr sein muss. Eine zweite Liste mit Testfällen neben den Kriterien gibt es nicht, denn zwei Listen laufen auseinander. Wie ein Kriterium bewiesen wird, hängt von seiner Art ab.

• Automatisiert, im Normalfall. Wer baut, schreibt für jedes Kriterium einen Test im Repository, wo er auch nach dem Schließen des Tickets weiterläuft. Der Test trägt den Namen des Kriteriums mit dem Ticket-Schlüssel und der Nummer des Kriteriums. So zeigt ein fehlschlagender Test auf das, was er schützt, und jeder findet die Tests eines Tickets: test('PROJ-42 check 2: the totals match the monthly overview', …).
• Mit dem Test abgehakt. Das Kriterium wird mit seinem Test als Nachweis bestanden: der Test und sein Ergebnis, etwa src/reports/hours.test.ts › PROJ-42 check 2: passed, und der CI-Lauf, wenn es einen gibt. Schlägt der Test fehl, ist das Kriterium nicht bestanden, mit dem, was fehlschlug.
• Manuell, wenn es sich nicht automatisieren lässt. Wie eine E-Mail in Outlook aussieht oder ob ein Ablauf für Neue verständlich ist. Das Kriterium endet auf (manual) oder (manuell) und sagt, worauf eine Person schaut: „Die Erinnerung sieht in Outlook und Gmail richtig aus (manuell)“. Ein Agent darf einen Screenshot oder eine Aufnahme vorbereiten; bestanden wird das Kriterium von einer Person.
• Weitere Tests sind willkommen. Tests für Randfälle und Regressionen über die Kriterien hinaus sind gute Praxis. Sie ersetzen kein Kriterium, und ein Kriterium wird nicht durch den Test von etwas anderem bestanden.

Offene Fragen und Annahmen

Offene Fragen sind der wichtigste Teil eines Briefs, denn jede ist eine Vermutung, die nicht passiert ist.

## Open questions
- Which separator should the file use: comma or semicolon?
- [x] Do managers see their team's hours? Yes, team only.

• Jeder Punkt unter Open questions zählt als offen, außer er ist abgehakt (- [x]) oder lautet „None“ bzw. „Keine“.
• Ein Brief mit einer offenen Frage ist nicht bereit, egal was sonst drinsteht.
• Annahmen werden aufgelistet, nicht im Text versteckt. Behalten heißt, sie gehört zum Brief; streichen heißt, sie fällt heraus.
• Namen, Zahlen, Grenzen und exakte Formulierungen werden nie angenommen. Sie sind Fragen oder ein Platzhalter [to confirm].

Readiness

Readiness ist ein Wert von 0 bis 100, der sagt, ob ein Brief an einen Agenten übergeben werden kann. Er prüft die Form des Briefs, nicht ob er inhaltlich stimmt.

Ein Brief ist bei 100 bereit für einen Agenten: alle vier Teile. Ab 50 ist er nah dran; darunter wird ein Agent raten.

Überschriften, die zählen

**Fette Zeilen** allein auf einer Zeile gelten ebenfalls als Überschrift. Eine einfache Zeile wie „Akzeptanzkriterien:“ nicht: Tools können sie nicht von einem Satz unterscheiden.

Verifiziert fertig

Ein Ticket auf Fertig zu schieben ist eine Behauptung. Verifiziert ist der Beweis:

1. Jedes Akzeptanzkriterium ist mit Nachweis bestanden.
2. Kein mit dem Ticket verknüpfter Pull Request ist noch offen.
3. Keine Dokumentationsänderung dazu wartet noch auf Prüfung, wo das Team sie nutzt.

Was fehlt, wird aufgelistet, sodass „Not verified“ immer sagt, was als Nächstes zu tun ist.

Ein Beispiel

## Intent
As a finance manager, I want to export one month of logged hours as a CSV,
so that payroll closes without retyping numbers.

## Context
- Report page: `src/reports/HoursReport.tsx`
- Totals come from `time_entries`; the monthly overview already sums them

## Behaviour
1. A manager picks a month and chooses **Export CSV**.
2. One row per person and day: date, person, project, ticket, hours, billable.
3. Members export only their own hours.

## Constraints
- The monthly overview and its totals stay exactly as they are.

## Out of scope
- Scheduled exports, email delivery, Excel (XLSX) files.

## Open questions
- [x] Separator? Semicolon: finance uses German Excel.

## Acceptance checks
- Given a manager, when they export March, then the file has one row per person and day
- The totals match the monthly overview
- A member cannot export someone else's hours
- 10,000 rows export in under 2 seconds

Readiness 100: ein Intent, Kontext mit Dateipfaden, vier Kriterien und keine offene Frage.

Anwenden

• In jedem Tool: Übernehmen Sie die Überschriften in Ihre Ticket-Vorlage. Fügen Sie ein Ticket in den Brief Checker ein, um es zu bewerten.
• In NEWWORK Projects: Write with Nova, Entwürfe aus Notizen und Brainstorming-Pläne schreiben Briefs in diesem Format, jedes Ticket zeigt seine Readiness, und Agenten lesen den Brief, schreiben für jedes Kriterium einen Test und haken es per MCP ab (pm-item-get, pm-brief-check, pm-check-tick).
• In Ihren eigenen Tools: Der Referenz-Scorer, eine Kommandozeile, JSON-Schemas und Konformitätsfälle sind als @newwork/brief-standard unter der MIT-Lizenz veröffentlicht. npx @newwork/brief-standard TICKET.md bewertet einen Brief und endet mit einem Fehler, wenn er nicht bereit ist, sodass er eine Pipeline anhalten kann. Ein anderes Tool ist konform, wenn es für jeden Fall dieselben Antworten gibt.
• Vorlagen: Die Brief-Bibliothek hat einen Brief für jede häufige Art von Arbeit.

Version und Lizenz

Version 1.1, Oktober 2026. Der Brief-Standard steht unter Creative Commons Namensnennung 4.0: Nutzen Sie ihn, ändern Sie ihn und bauen Sie Tools dafür, mit einem Hinweis auf NEWWORK Projects. Vorschläge gern an hello@newworkprojects.com.

Änderungen

• 1.1: Akzeptanzkriterien, die Aufgaben oder Wünsche sind, zählen 15 statt 30 Punkte, und der Brief ist erst bereit, wenn sie umformuliert sind. Kriterien können als (manuell) markiert werden; bestanden werden sie von einer Person. Neu: Testen, mit einem Test pro Kriterium, nach ihm benannt, als Nachweis, der es besteht.
• 1.0: Erste Version.