Das hast du am Ende dieses Moduls
Am Ende dieses Moduls hast du ein Briefing, aus dem Claude bauen kann: jede Tatsache bestätigt, jede Annahme als Annahme markiert, jede Lücke benannt statt stillschweigend gefüllt.
Der Kurs begleitet Tool Scout: ein fiktives Produktteam, das fünf AI-App-Builder für seinen nächsten Prototyp vergleicht. Dateien und Review-Ergebnisse stammen aus einem echten Build und wurden angepasst; Geschäftskontext und Gespräche sind für den Kurs neu geschrieben.
Was dieses Modul vermittelt
Sechs Ideen, in der Reihenfolge ihrer Bedeutung. Die Erklärung zum Kontextfenster zieht sich durch jedes spätere Modul: In The Operating Brain siehst du, wie dieselbe Idee im Maßstab eines Unternehmens aussieht statt im Maßstab einer Session.
- Das Harness: du, die Steuerung, der Motor
Claude Code besteht aus drei Teilen, die zusammenarbeiten, nicht aus einem. Du hältst die Absicht: was tatsächlich entstehen soll. Der Motor ist das Modell, das liest, schreibt und denkt. Die Steuerung sitzt dazwischen: Berechtigungen, Hooks, welche Tools es anfassen darf. Eine vage Anfrage springt direkt zum Motor und gibt der Steuerung nichts, woran sie lenken kann. - Das Kontextfenster als Arbeitsspeicher
Stell dir das Kontextfenster als RAM vor, nicht als Chatverlauf. Es füllt sich mit deinem System-Prompt, geladenen Skills, Memory-Dateien und dem Gespräch selbst. Das meiste davon hast du nie getippt. Ab 60–70 % Füllstand verlieren Antworten Details und vergessen frühere Entscheidungen, ohne dass es auffällt. Das ist der Moment zum Komprimieren oder Übergeben, nicht erst der Moment, in dem es sichtbar kaputtgeht. - Die drei Inputs: Skills, Kontext, Rohdaten
Jede Antwort von Claude entsteht aus drei Arten von Input, und bei einer falschen Antwort lohnt der Blick, welcher fehlt. Skills sind das Wie: eine aufgeschriebene Methode, die Claude laden und befolgen kann. Kontext ist das, was schon feststeht: dein Briefing, deine CLAUDE.md, deine früheren Entscheidungen. Rohdaten sind die Fakten für genau diese Aufgabe. Ein vages Briefing lässt alle drei verhungern: keine Methode benannt, nichts vereinbart, keine Fakten geliefert. - Prompten in der richtigen Reihenfolge, die sechs Schritte
Die Reihenfolge ist die Lektion, nicht der einzelne Prompt. Erst der Kontext, damit Claude nicht raten muss, was wichtig ist. Dann ein Play-back, damit du ein Missverständnis erkennst, bevor es sich aufschaukelt. Dann die direkte Frage, welche Daten seine Annahmen ersetzen würden. Dann fragt es dich zurück, eine Frage nach der anderen, bis es sich zu 95 % sicher ist. Dann eine Bandbreite an Optionen statt eines einzigen Plans. Zuletzt die bewusste Gegenprobe zur eigenen Antwort. Wer einen Schritt überspringt, vererbt die Lücke an alle folgenden. - Fragen, bevor gebaut wird
Der vierte der sechs Schritte, und der, den man am liebsten überspringt. Eine Frage kostet einen Satz. Ein Build auf einer falschen Annahme kostet den Nachmittag, und welche Annahme falsch war, merkst du erst, wenn du vor dem Falschen stehst. Claude ausdrücklich zu sagen, dass es nichts annehmen und immer nur eine Frage stellen soll, macht aus einer Idee in einem Absatz ein Briefing ohne stille Lücken. - Das Ergebnis hinterfragen
Der sechste Schritt, und der, der findet, was reine Zustimmung nicht findet. Sobald ein Plan steht, deckt die Bitte an Claude, gegen die eigene Antwort zu argumentieren (mit einem evidenzbasierten Skill, nicht mit einem vagen „Irgendwelche Bedenken?“), Mängel auf, die ein freundliches Durchlesen übersieht. Bei Tool Scout fand allein dieser Schritt zwei Launch-Blocker und fünf operative Risiken, bevor es eine einzige Zeile Code gab.
Die Aufgabe
Ausgangspunkt
Ein leerer Ordner und ein bewusst vages Briefing in einem Absatz für dein Projekt. (Die Version des Referenzprojekts Tool Scout siehst du unten.)
Ergebnis
docs/brief.md: bestätigte Fakten, Lücken ausdrücklich als Lücken markiert, vereinbarte Erfolgskriterien.
Bestanden, wenn
Das Briefing trennt Bekanntes von Angenommenem, und zu jeder Annahme gibt es entweder eine Quelle oder eine offene Frage. Nichts wird stillschweigend ergänzt.
Hier das Briefing, mit dem Tool Scout tatsächlich gestartet ist: ein Absatz, keine Struktur, genau so klingt eine echte Idee, bevor sie jemand hinterfragt.
Our product team is choosing an AI app builder for its next prototype. I want a simple page we can open during a planning meeting to compare the main tools. It should be quick to keep up to date and something we can actually trust.Die sechs Claude-Code-Prompts, in Reihenfolge
Die Reihenfolge ist die Lektion, nicht ein einzelner Prompt. Kopiere sie nacheinander und wende sie auf dein eigenes Briefing an.
Use the <skill> skill. Read docs/brief.md and dev-docs/pt1-<name>.md first.Verweist auf den Skill und die wichtigen Dateien, bevor die Arbeit beginnt.
Summarise the brief, the problem and where the work stands today.Stimmt das Play-back nicht, seid ihr noch nicht auf demselben Stand.
What data can I give you that removes every assumption you are making, so you answer me with facts only?Wo Daten fehlen, füllt Claude die Lücke mit einer plausiblen Vermutung. Frag, was die Vermutungen ersetzen würde.
Ask me questions, one at a time, until you are 95% confident you understand exactly what I need. Do not make assumptions.Fragen sind billig; ein Build auf einer falschen Annahme kostet den Nachmittag.
How can we <problem>? Three options: a fix for today, a bigger fix that still hurts, and the proper one. Two short paragraphs each.Eine benannte Bandbreite verhindert den Sprung zum kompletten Neubau. Jetzt, als Nächstes und später, nebeneinander.
Play devil's advocate on this. Where does it break?Kein Fehler gefunden? Bitte um einen neuen Plan aus dem ursprünglichen Briefing, behalte beide und gib sie an einen frischen Agent.
Wie das Gespräch aussah
Drei angepasste Wortwechsel aus Schritt 4, eine Frage nach der anderen, mit dem Briefing des fiktiven Teams.
Owner
1. We haven't interviewed the team about its requirements yet. That's a gap, mark it as one.
2 and 3. Leave a final recommendation out for now. Version one compares the five tools only...
Ask me questions, one at a time, until you are 95% confident you understand exactly what I need. Do not make assumptions.
Claude
Saved your answers. Missing requirements interviews are marked as a gap.
Question 1: What kind of prototype does the team want to build? For example: a marketing website, a customer app, an internal dashboard, or something else?Owner
Four points, no more: 1. Cost for a small team... 2. Real app parts... 3. Leaving... 4. Security and data...
Claude
Saved: four points, with security and data done last.
Question 3: What counts as a trusted source?
A. Tool's own site only
B. A + third parties (reviews, forums, YouTube tests)
C. A + our own hands-on test
Which one: A, B or C?Owner
Yes, data.js.
Claude
I'm now at 95%. Here's what you need, in one line:
One internal web page that compares Lovable, Bolt.new, v0, Replit and Figma Make on 4 points. It uses only each tool's own pages, with a link, a date and "Not stated" where they say nothing. The facts live in data.js, which the product lead re-checks by hand every month.
Did I get it right, and should I start with step 1?Das Projekt zu diesem Zeitpunkt
Dieselbe Datei, vor den sechs Prompts und danach. Für dieses Beispiel angepasst und zur besseren Lesbarkeit gekürzt.
Vorher
Our product team is choosing an AI app builder for its next prototype. I want a simple page we can open during a planning meeting to compare the main tools. It should be quick to keep up to date and something we can actually trust.Nachher
# Tool Scout: brief
## Starting brief
Our product team is choosing an AI app builder for its next prototype. I want a simple page we can open during a planning meeting to compare the main tools. It should be quick to keep up to date and something we can actually trust.
## Confirmed facts
Agreed on 2026-09-17.
### Scope of version one
- Compare five tools: Lovable, Bolt.new, v0, Replit, Figma Make. These form the initial shortlist for this exercise.
- Compare the five tools only. Do not recommend a winner yet. The team will decide after reviewing the evidence.
- No deadline. Keep version one small instead.
### The four comparison points (no more)
1. Cost for a small team. Monthly price of the cheapest plan a team of three could actually ship on.
2. Real app parts. Logins, database and payments, each labelled Built in / One-click link to outside service / Client wires it up.
3. Leaving. Can you export the code and run it somewhere else?
4. Security and data. Where the data lives and which security claims the tool publishes. Needs the most careful sourcing, so it's done last.
### Sourcing rules
- Use only the tool's own public pages: pricing page, docs, security or trust page. No third-party sources and no hands-on tests.
- Every claim carries the link and the date it was checked.
- If the tool's own pages don't say, the cell reads "Not stated". Never a guess.
### Trust rules
- Price only when confirmed. Otherwise the cell reads "Can't confirm: [requirement] not stated".
- "Not stated" is its own label, and looks different from "No".
- Security claims quote the exact wording, then add "Covers builder: stated / not stated".
## Assumptions
| Assumption | Source or open question |
|---|---|
| These five tools cover the team's needs | Open question: the shortlist has not been checked against team requirements (see Gaps). |
| These four points are enough to choose a prototype tool | Open question: not checked with the people who will build the prototype (see Gaps). |
| A security certification held by the company covers its AI builder | Open question: not verified. This is why claims show "Covers builder". |
| A monthly check by hand keeps the facts accurate enough to trust | Open question: not tested. |
## Gaps
- GAP: requirements interviews have not been run. The comparison points need confirmation from the team. Owner: the product lead.
- GAP: none of the shortlisted tools has been tested on the planned prototype. Owner: not assigned.
## Success criteria
- The team can open the page before a planning meeting.
- It covers all five tools on all four points.
- Every claim has a link and a check date, or reads "Not stated".
- No cell holds a guess.
- The product lead updates it by editing data.js only.Hier setzt Core 2 an: Diese Datei und alles, was danach entschieden wird, soll nicht nur in einem Chat leben.
Gib deinem Team Feedback, mit dem es arbeiten kann
Mit diesem kostenlosen Claude Skill machst du aus groben Review-Notizen klare Anweisungen: was sich ändern muss, warum, und woran dein Team erkennt, dass es behoben ist.
Vorher
Die Seite könnte am Ende sagen, ein Tool könne etwas nicht, obwohl die Seite des Tools es schlicht nie erwähnt. Fühlt sich riskant an für ein Planungsmeeting. Vor dem Launch einen Blick wert.
Nachher
| Was der Skill geschrieben hat | |
|---|---|
| Auftrag | Schweigen auf den eigenen Seiten eines Tools darf nie als „Nein“ angezeigt werden. |
| Warum | Ein Team, das Schweigen als „keine Zahlungsunterstützung“ liest, lehnt womöglich ein passendes Tool wegen einer Aussage ab, die die Quelle nie getroffen hat. |
| Beleg | Die vereinbarten Labels für Punkt 2 und 3 sind „Built in“, „One-click link“, „Client wires it up“ und „No“. Keines davon ist „Not stated“, obwohl die Quellenregel in docs/brief.md es verlangt. |
| Änderung | „Not stated“ als eigenes Label für Punkt 2, 3 und 4 ergänzen, optisch anders als „No“. Eine „No“-Zelle braucht einen Link, der das tatsächlich belegt. |
| Nachweis | Jede „No“-Zelle in data.js trägt einen Link, und eine zweite Person prüft fünf davon stichprobenartig gegen die Live-Seiten. |
