Wir leben in der Ära der persönlichen Software. Statt Standardprogramme zu kaufen, bauen sich immer mehr Menschen ihre eigenen kleinen Lösungen mit Claude Code, Codex oder ähnlichen Tools. Ich habe das für mich genauso gemacht: eine macOS-App, die meine Systemleistung überwacht, meinen Speicherplatz aufräumt und mir Shortcuts für den Alltag bereitstellt.
Der Auslöser war simpel. Über die Monate sammelt sich auf meiner Festplatte jede Menge Rohmaterial an, kleine Videoschnipsel, die ich kurz brauche und dann wegwerfen könnte. Die Speicherkapazität war immer wieder erschöpft. Es gibt zwar viele Aufräum-Tools, aber meist mit Abo oder Funktionen hinter einer Paywall. Also habe ich mir meine eigene App gebaut.
Dieser Artikel ist die schriftliche Begleitung zu meinem Video. Er zeigt dir den Weg, den ich dafür gegangen bin.
Der Prompt zum Mitnehmen
Wenn du alles nur in einen Chat wirfst, verliert der Coding Agent irgendwann den Überblick, vergisst Entscheidungen oder bricht Funktionen, die schon liefen. Deshalb zerlegen wir das Briefing zuerst in einzelne Features und beschreiben jedes Feature in einer Spec.
Der folgende Prompt macht genau das. Er enthält auch das Spec-Template, nach dem jedes Feature aufgebaut ist. Du kopierst ihn in deinen Coding Agent, sobald du dein Briefing geschrieben hast:
Ich habe ein Produkt-Briefing für eine macOS-App erstellt. Bitte zerlege es in einzelne Features und erstelle für jedes Feature eine Spec nach dem Template unten.
Vorgehen:
1. Lies das Briefing vollständig. Wenn etwas unklar oder nicht entschieden ist, stelle mir zuerst Rückfragen, bevor du weitermachst.
2. Zerlege das Briefing in einzelne, eigenständige Features. Jedes Feature soll für sich testbar und fachlich klar abgegrenzt sein.
3. Lege eine Datei features/INDEX.md an. Sie enthält für jedes Feature ID (PROJ-1, PROJ-2 ...), Name, Kurzbeschreibung, Abhängigkeiten und den Status "geplant".
4. Erstelle für jedes Feature die Datei features/PROJ-X-feature-name/spec.md nach dem Template unten. Halte dich strikt an die Struktur.
5. Beschreibe in der Spec nur das WAS, nicht das WIE. Die technische Umsetzung kommt später.
6. Was im Briefing fehlt (Größen, Verhalten, Grenzen), erfindest du nicht. Notiere es unter "Open Questions".
7. Lege für jedes Feature fest, was es NICHT tut (Out of Scope), damit nichts stillschweigend dazukommt.
8. Ändere in dieser Phase keinen Code.
Zeige mir danach die Feature-Liste und alle Open Questions, bevor wir mit der Umsetzung beginnen.
Template für jede spec.md:
# PROJ-X: Feature Name
<!-- This file (spec.md) is the stable CONTRACT — it defines WHAT, not HOW.
Written once when the feature is specified. Changed only deliberately, when the
requirements change. During implementation this file stays unchanged.
Technical design lives in design.md, QA results in qa-report.md.
No status or date fields here: the feature's status lives ONLY in features/INDEX.md,
and git records when this file changed. A contract that changes during
implementation cannot be trusted as a contract. -->
## Dependencies
- None
## User Stories
- As a [user type], I want to [action] so that [goal]
## Out of Scope
<!-- What this feature explicitly does NOT cover. Critical for developer handoffs. -->
- *Example: Bulk operations (deferred to P1 — PROJ-X)*
- *Example: Admin view of other users' data (separate admin feature)*
## Acceptance Criteria
<!-- Write these in the project's working language (CLAUDE.md → Key Conventions).
Deutsch: Angenommen [Vorbedingung], wenn [Aktion], dann [Ergebnis]
English: Given [precondition], when [action], then [outcome]
Use one of the two for every AC and EC in this file — never both.
Each AC gets a stable ID (AC-1, AC-2, …). Tasks reference these IDs;
qa-report.md reports per AC-ID. Chain: AC → Task → Test. -->
- [ ] **AC-1** — [Given/Angenommen …], [when/wenn …], [then/dann …]
- [ ] **AC-2** — [Given/Angenommen …], [when/wenn …], [then/dann …]
## Edge Cases
<!-- Each edge case gets a stable ID (EC-1, EC-2, …) so tasks and tests can reference it. -->
- **EC-1** — What happens when...?
- **EC-2** — How do we handle...?
## Technical Requirements (optional)
- Performance: < 200ms response time
- Security: Authentication required
- Browser Support: Chrome, Firefox, Safari
## Open Questions
<!-- Unresolved questions. Remove each one once it is answered and reflect the answer in the spec. -->
- [ ] Question 1
## Decision Log
<!-- Record of conscious decisions made and why. Add a row whenever a product decision is made. -->
### Product Decisions
| Decision | Rationale | Date |
|----------|-----------|------|
| *Example: Limit to 3 tags per item* | *Keeps UI simple for MVP; can be raised later* | YYYY-MM-DD |
Ein Hinweis zum Prompt: Ob die Acceptance Criteria auf Deutsch oder Englisch sind, legst du am besten einmal in der CLAUDE.md deines Projekts fest. Dann bleibt es über alle Features gleich.
Die Tools für eine macOS-App
Du brauchst drei Dinge:
- Einen Coding Agent. Claude Code, Codex oder Cursor funktionieren alle. Im Video nutze ich Claude Code und ChatGPT, wobei ein Pro-Abo je nach Umfang der App schon reichen kann.
- Xcode. Apples Entwicklungsumgebung, kostenlos im Mac App Store. Damit baust du native macOS- und iOS-Apps.
- Swift. Die Programmiersprache für native Apps. Electron ginge auch, aber sobald du Systemfunktionen brauchst, etwa zum Auslesen der Systemleistung, wird es umständlich. Mit Swift bleibt die App schlank und die Zugriffe sind direkt verfügbar.
Ein Coding Agent wie Cursor oder Claude Code kann Xcode-Projekte bearbeiten, die App selbst starten und testen. Du musst Xcode dafür nicht ständig offen haben.
Schritt 1: Das Produkt-Briefing
Bevor du den ersten Code schreibst, hältst du in einem Dokument fest:
- Für wen ist das Produkt?
- Für welche Plattform? Native App, Web-App oder etwas anderes?
- Welche Funktionen soll es abdecken?
- Was soll es nicht können? Das ist genauso wichtig, denn Coding Agents neigen zum Overengineering und bauen gern mehr, als du brauchst.
Du musst das nicht alles aus dem Kopf wissen. Ich habe dafür den Grill-Me-Skill von Matt Pocock genutzt. Er stellt dir Fragen, bis ein gemeinsames Bild entsteht, und zieht dir so die nötigen Antworten heraus.
Schritt 2: Prototyp mit Claude Design
Bevor du die echte App baust, entwirfst du das Aussehen. Wenn du Claude nutzt, ist Claude Design im Abo enthalten, erreichbar unter claude.ai/design. Im Prototyp geht es um Optik und Grundfunktionen. Den Code dahinter kannst du dabei vernachlässigen.
Der Grund: Wenn du erst die echte App entwickelst und später das Design änderst, musst du die bestehende Struktur umbauen. Das ist fehleranfällig. Mit dem Prototyp klärst du vorher, wie die App aussehen soll.
Schritt 3: Briefing in Features zerlegen
Jetzt hast du Briefing und Design. Der Prompt aus dem Anfang des Artikels zerlegt das Briefing in Features und schreibt für jedes eine Spec. Du prüfst die Specs selbst, denn sie sind der Vertrag mit dem Coding Agent. Achte besonders auf:
- Acceptance Criteria: Beschreiben sie genau, wann ein Feature fertig ist?
- Edge Cases: Sind Sonderfälle bedacht, die im normalen Betrieb nicht auftreten, aber trotzdem passieren können?
- Out of Scope: Steht drin, was nicht gebaut wird?
- Open Questions: Hat der Agent Lücken gefunden und gemeldet, statt sie zu raten?
Der Vergleich mit einem Hausbau hilft: Im Briefing steht „Ich möchte eine Stadtvilla mit fünf Zimmern und 150 Quadratmetern“. Die Spec legt fest, wie groß jedes Zimmer ist und wo Türen und Steckdosen sitzen. Ohne diese Details trifft der Agent Annahmen, die vielleicht nicht zu deinen Vorstellungen passen.
Schritt 4: Umsetzung
Erst wenn Specs und Open Questions geklärt sind, lässt du den Agent implementieren, Feature für Feature. Die Architektur und die Reihenfolge der Aufgaben plant der Agent auf Basis der Specs. Jede Aufgabe verweist auf die AC-IDs, die sie erfüllt. So bleibt nachvollziehbar, wofür welcher Code geschrieben wurde.
Für eine App, die nur du selbst nutzt, kann es reichen, den Agent einfach loslegen zu lassen. Sobald andere Menschen die App nutzen oder ihre Daten verarbeitet werden, brauchst du aber klarere Vorgaben und Kontrolle, besonders beim Löschen von Dateien.
Eine unabhängige Qualitätssicherung ist optional, aber hilfreich. Dabei prüft ein zweiter Agent die Ergebnisse gegen die Acceptance Criteria und schreibt einen Testbericht mit Fehlern.
Mein Fazit
Das Prinzip hinter dem Ganzen ist Spec-Driven Development. Die Spec ist das, was du selbst prüfst. Den Rest kann der Coding Agent übernehmen.
Wenn du den Workflow ausprobieren möchtest, schau dir auch meinen kostenlosen AI Engineering Blueprint an. Dort steht Schritt für Schritt, was du dafür brauchst.
