Eine eigene Notion Chrome Extension zu bauen bedeutete früher: einen Entwickler beauftragen oder selbst programmieren lernen – und heute nicht mehr. Mit KI-Coding-Agenten wie Claude Code und Codex kannst du beschreiben, was du willst, und eine funktionierende Browser-Extension liefern, die deinen Notion-Workspace liest und beschreibt – auch wenn du noch nie eine einzige Zeile Code geschrieben hast. Die eigentliche Kompetenz ist nicht mehr das Programmieren, sondern die KI so zu steuern, wie du ein Engineering-Team steuern würdest. Diese Anleitung zeigt den genauen Fünf-Phasen-Workflow, den wir nutzen, um Notion Chrome Extensions für Kunden zu bauen – von der groben Idee bis zum fertigen Tool, das direkt in dein Notion-CRM eingebunden ist.
Was Kann Eine Notion Chrome Extension Eigentlich?
Eine Notion Chrome Extension bringt deine Notion-Daten auf die Websites, auf denen du tatsächlich arbeitest.
Stell dir vor, du browst LinkedIn und siehst auf einen Blick, ob die Person auf deinem Bildschirm schon in deinem Notion-CRM ist – inklusive Deal-Status – und kannst einen neuen Kontakt mit einem einzigen Klick speichern. Das ist das Beispiel, das wir hier bauen: eine LinkedIn-to-Notion-Bridge auf Basis eines einfachen Unternehmen-und-Kontakte-CRM.
Das gleiche Muster eröffnet noch viel mehr: ein Save-to-Notion-Clipper für dein Marketing-Team, ein Kampagnen-Erfassungstool oder jede andere Bridge, die externe Daten in deinen Single Source of Truth schiebt.
Was Ist Der Fünf-Phasen-Workflow Für KI-gestütztes Engineering?
Jedes KI-Build – nicht nur Chrome Extensions – durchläuft fünf Phasen: Feasibility, PRD, Grill Me, Plan und Build.
Die entscheidende Verschiebung liegt darin, wo deine Zeit hingeht. Früher floss der Großteil des Aufwands in den Build selbst. Heute ist der Build schnell und günstig – dein Hebel liegt in den vier Phasen davor: das Denken richtig aufzusetzen, damit die KI klar ausführen kann.
| Phase | Was passiert | Wer führt | Ergebnis |
|---|---|---|---|
| 1. Feasibility | Brainstorme die Idee mit KI und prüfe, wie schwer sie wirklich ist | Du + KI | Sicherheit, dass es gebaut werden kann |
| 2. PRD | Schreibe auf, was passieren soll – auf Deutsch, aus Sicht des Nutzers | Du (Product) | Ein Product Requirement Document |
| 3. Grill Me | Die KI interviewt dich, um Product-Entscheidungen aufzudecken, die du noch nicht getroffen hast | KI fragt, du antwortest | Geklärter Scope und Edge Cases |
| 4. Plan | Die KI wandelt das PRD in einen schrittweisen Implementierungsplan um | KI (Engineering) | Ein Plan, den eine neue Session ausführen könnte |
| 5. Build | Die KI schreibt den Code – eine Scheibe nach der anderen – während du reviewst | KI (Engineering) | Eine funktionierende Extension |
Stell es dir als Rollentrennung vor, die du aus jedem Unternehmen kennst: Es gibt Product (was gebaut wird und warum) und Engineering (wie es gebaut wird). Du bist Product. Claude oder Codex ist dein Engineering-Team – und die gleichen Kommunikationsprobleme, die du zwischen Menschen hattest, bestehen jetzt zwischen dir und der KI.
Wie Prüfst Du, Ob Eine Idee Überhaupt Machbar Ist?
Beginne damit, die Idee mit der KI zu brainstormen und zu prüfen, wie schwer sie wirklich ist.
Öffne dein KI-Tool der Wahl auf dem klügsten Denkmodell, schalte die Diktierfunktion ein und beschreibe einfach, was du willst. Diktat ist hier wichtig – Sprechen gibt dem Modell viel mehr Kontext, als du jemals tippen würdest.
Frag direkt: Ist das ein gelöstes Problem im Code? Gibt es große Engpässe, die ich übersehe? Was für ein Projekt ist das eigentlich? Gerade am Anfang brauchst du einen Denkpartner, der deine Intuition schärft – für das, was heute einfach ist, und was noch schwierig.
💡 Pro-Tipp: Wenn es das erste Mal ist, nimm dir hier richtig Zeit. Sobald du ein paar Dinge gebaut hast, weißt du oft schon, ob eine Idee machbar ist, und kannst direkt zur nächsten Phase springen.
Was Ist Ein PRD Und Warum Solltest Du Eines Schreiben?
Ein PRD – Product Requirement Document – ist eine Beschreibung dessen, was passieren soll, aus Sicht des Nutzers.
Es vermeidet bewusst das Wie. Du legst keine Libraries oder Architektur fest; du beschreibst die Erfahrung. Für unsere Extension läuft das gesamte PRD auf: „Wenn ich auf einem LinkedIn-Profil lande, will ich sehen, ob diese Person in meinem CRM ist, ihren Deal-Status sehen – falls ja –, und sie mit einem Klick speichern – falls nicht.”
Übergib dein Feasibility-Gespräch an die KI und bitte sie, das PRD zu entwerfen. Wenn du das ein paar Mal gemacht hast, verpacke es als wiederverwendbaren Skill, damit du beim nächsten Mal einfach „schreib das PRD” sagen kannst und sie weiß, was du meinst.
Was Ist Der „Grill Me”-Skill?
Grill Me ist ein Skill, der das Skript umdreht: Statt du der KI Anweisungen gibst, interviewt die KI dich, um jede Entscheidung aufzudecken, die du vergessen hast zu treffen.
Credit where it’s due – dieses Konzept stammt von Matt Pocock, der brillante Arbeit zur KI-Entwicklung teilt. Wir haben es für nicht-technische Builder adaptiert.
Der Schlüssel: Eine gute Grill-Me-Session stellt Product-Fragen, keine Engineering-Fragen. Wenn die KI anfängt zu fragen, welche Library du nutzen willst, und du dich dabei ertappst, immer wieder „was du empfiehlst” zu sagen – stop. Das ist das Signal, dass dein Skill nachgebessert werden muss.
Mach es explizit: Du bist Product, die KI ist Engineering. Die KI trifft die technischen Entscheidungen; was du von ihr willst, sind Trade-offs in verständlicher Sprache, über die du wirklich urteilen kannst. Statt „welchen Storage-Ansatz sollen wir nutzen?” willst du: „Wenn wir es so machen, kann nur eine Person die Extension nutzen. Wenn wir es so machen, kann deine ganze Organisation sie nutzen – aber es ist komplexer. Was ist wichtiger?” Das ist eine Frage, die du beantworten kannst.
Hier ist eine vereinfachte Version des Grill-Me-Skills:
---
name: grill-me
description: >
A relentless interview that stress-tests a plan, PRD, or feature idea
before any code gets written. Use it whenever you're about to plan or
build something and want to surface the decisions you haven't made yet.
---
# Grill Me
Interview me relentlessly about this plan until we reach a shared
understanding. Walk down each branch of the design tree, resolving
dependencies between decisions one at a time.
## Rules
- Ask **one question at a time**. Wait for my answer before the next one.
- For every question, give your **recommended answer** so I can just say
"yes" when you're right.
- If a question can be answered by reading the codebase or the existing
docs, go and check instead of asking me.
## Decision zones
- **Product zone — grill me hard.** The user story, the outcomes, what the
user sees, priorities, edge cases, what counts as "done". These are my
calls.
- **Engineering zone — don't grill me.** Architecture, libraries, file
layout, test strategy, trade-offs. These are yours. Decide them and
record the rationale.
If you catch yourself asking me something I can't evaluate, stop. Either
make the call yourself, or reframe it as a product trade-off I *can*
weigh in on (e.g. "single user vs. whole organisation").Welche Entscheidungen Sind Deine – Und Welche Gehören Der KI?
Die sauberste Art, eine Grill-Me-Session zu führen, ist, die Zuständigkeiten vorher zu kennen.
| Deine Entscheidung – Product Zone | Entscheidung der KI – Engineering Zone |
|---|---|
| Was der Nutzer sieht und erlebt | Welche Libraries und Dependencies genutzt werden |
| Welche Features wichtig sind und in welcher Reihenfolge | Wie der Code strukturiert ist |
| Was bei Edge Cases passiert (z. B. mehrere Deals) | Test-Strategie und Error Handling |
| Wie „fertig” wirklich aussieht | Technische Trade-offs (in verständlicher Sprache für dich aufbereitet) |
Wie Plant Die KI Die Arbeit?
Sobald die Fragen geklärt sind, bitte die KI, einen Plan zu schreiben, bevor sie Code anfasst.
Komplexe, längere Builds laufen deutlich besser, wenn die KI erst plant und dann Schritt für Schritt ausführt, anstatt direkt zum Ziel zu springen. Der Plan sollte detailliert genug sein, dass eine neue KI-Session ihn aufgreifen und das Feature bauen kann, ohne dir auch nur eine Frage zu stellen.
Hier ist eine vereinfachte Version des Plan-Skills:
---
name: plan
description: >
Turn a PRD or feature brief into an implementation plan detailed enough
that a fresh AI session could execute it without asking questions.
---
# /plan
Produce a plan file in `docs/plans/<slug>.md`. The bar: a brand-new
session could pick it up and build the feature with no further context.
## Order of operations
1. **Research, then verify reality.** Map the files, patterns, and
conventions relevant to this feature. Then check anything external the
plan depends on — the real shape of an API, a live schema, how the data
actually behaves. Never plan against an assumption you could have
checked.
2. **Grill me on the product decisions.** Use the grill-me discipline:
interview me on the user story and outcomes. Make the engineering calls
yourself and write them into the plan with a one-line rationale.
3. **Write the plan.** Break the work into thin vertical slices, each one
independently testable. List the files touched, the acceptance check
for each slice, and any open questions.
Stop and hand the plan back for review before any code is written.💡 Pro-Tipp: Führe das Grilling und das Planning in der gleichen Session durch, um den Kontext zu schützen. Starte dann eine neue Session für den eigentlichen Build.
Wie Bringst Du Die KI Dazu, Es Zu Bauen?
In der Build-Phase ist deine Aufgabe, der KI aus dem Weg zu gehen und sie arbeiten zu lassen.
Übergib ihr den Plan und lass sie Schritt für Schritt implementieren, mit Verifikation nach jedem Schritt. Das ist der Teil, der früher deine gesamte Zeit gefressen hat und heute schnell geht – gerade weil du das Denken vorher investiert hast.
Hier ist eine vereinfachte Version des Work-Skills:
---
name: work
description: >
Execute an approved plan one vertical slice at a time, verifying after
each slice before moving on.
---
# /work
Implement the plan in `docs/plans/<slug>.md`. If no plan is named, list the
plans, pick the most recent, and confirm with me before starting.
## Order of operations
1. Take the **next unfinished slice** from the plan.
2. Build just that slice — nothing further down the plan.
3. **Verify it** (run it, test it, or show me the result) before moving on.
4. Log a one-line rationale for any engineering decision to
`docs/decision-log.md`.
5. Repeat until the plan is done.
Engineering calls are yours. Anything that touches a live system, or that's
a genuine product decision, comes back to me first.Weil du in den früheren Phasen investiert hast, kannst du die Ausführung getrost übergeben – genauso wie du einem Engineer vertrauen würdest, den du ordentlich eingearbeitet hast, anstatt jeden Tastenanschlag zu genehmigen.
Wie Richtest Du Ein Neues KI-Projekt Ein?
Bevor du baust, lege eine saubere Projektstruktur an, damit jeder Build auf der gleichen Basis startet.
Erstelle einen übergeordneten Ordner für alle deine KI-Projekte, dann einen Unterordner pro Projekt. Darin richtest du vier Standard-Dokumente ein: eine CLAUDE.md (Agent-Anweisungen für dieses Projekt), eine README (der Gesamtzweck), eine Learnings-Datei und ein Changelog. Ein „Bootstrap”-Skill automatisiert das alles, sodass du nie auf einem leeren Blatt anfängst.
Hier ist eine vereinfachte Version des Bootstrap-Skills:
---
name: bootstrap
description: >
Scaffold a brand-new AI engineering project with a consistent folder
structure and the four default docs every project should start with.
---
# /bootstrap
Set up a fresh project folder so every build starts from the same clean
baseline. Ask me for the project name, then scaffold it.
## What to create
Inside `~/projects/<project-name>/`:
- `CLAUDE.md` — agent instructions specific to this project (the root
context the agent reads first).
- `README.md` — the human-readable purpose and overview.
- `learnings.md` — things we discover as we build, captured as we go.
- `CHANGELOG.md` — what changed, so a future session can catch up fast.
## Then
1. Run `git init` and make a first scaffolding commit.
2. (Optional) Register the project in Notion — create a Projects row and
add a first task — so the build is tracked from day one.
## Rules
- Ask one section at a time — don't dump every question on me at once.
- Leave tech-stack choices open until planning, unless I've already decided.
- If I hand you a PRD, move it into `docs/` as part of setup.Wie Verhinderst Du, Dass KI-Gespräche Zu Teuer Werden?
Beobachte dein Context-Window und wechsle zu einer neuen Session an natürlichen Übergangspunkten.
Je länger ein Gespräch läuft, desto voller wird das Context-Window – und desto teurer wird jede Anfrage. Außerdem sinkt die Modellqualität langsam. Eine gute Faustregel: Sobald du etwa 150K Tokens überschreitest, wechsle zur nächsten Session am nächsten natürlichen Übergangspunkt.
Wie Gehst Du Mit Sicherheit Um, Wenn Du Mit KI Baust?
KI zu nutzen bedeutet nicht, gute Sicherheitspraktiken aufzugeben – sondern sie vernünftig anzuwenden. Drei Dinge sind am wichtigsten für einen internen Build wie diesen:
- ✅ Distribution. Diese Extension ist nur intern – du lädst sie direkt in deinem Browser, sie wird nie im Web Store veröffentlicht. Sobald du unbekannte Nutzende hast, ändert sich die Komplexität komplett.
- ✅ Secrets. Deine Extension braucht einen Notion-Integrations-Token, um deinen Workspace zu lesen und zu schreiben. Füge Secrets niemals in den KI-Chat ein – sobald du das tust, werden sie Teil des Kontexts dieser Session.
- ✅ Nutze eine .env-Datei. Speichere Secrets in einer
.env-Datei (eine spezielle versteckte Datei mit deinen Umgebungsvariablen), damit die KI sie in den Code einbindet, ohne sie jemals in das Gespräch zu lesen. Bewahre die Master-Kopie in deinem Passwort-Manager auf.
Um deinen Token zu erhalten, öffne das Notion Developer Portal, gehe zu Connections und erstelle eine neue Integration im Workspace, in dem dein CRM liegt. Du kannst genau einstellen, welche Fähigkeiten sie erhält – für unsere Extension lässt du Lesen und Schreiben aktiviert. Wichtig: Du musst der Integration dann Zugriff auf die spezifischen Datenbanken geben, die sie braucht – über das •••-Menü auf jeder Seite oder Datenbank.
💡 Pro-Tipp: Bei diesen Freigabe-Prompts: Wenn du bei jedem Befehl einfach „Ja” klicken würdest, weil du ihn nicht wirklich beurteilen kannst, ist das nur Scheinsicherheit. Du fährst viel besser, wenn du in klares Planning investierst, auf einem leistungsstarken Modell arbeitest und in einer Umgebung, in der die KI nichts Wichtiges kaputtmachen kann.
Wie Testest Und Verbesserst Du Deine Extension?
Lade die Extension in Chrome und teste sie live – Fehler gibst du direkt an die KI zurück.
Öffne in Chrome deine Extensions-Seite, aktiviere den Entwicklermodus, klicke auf Entpackte Extension laden und wähle den Ordner, den die KI gebaut hat. Dann geh zu LinkedIn und schau, ob es funktioniert.
Beim ersten Versuch wird es fast sicher nicht perfekt sein – das ist völlig normal, auch nach einer gründlichen Grill-Me-Session. Wenn etwas nicht stimmt, mach einen Screenshot und gib ihn an die KI zurück mit einem einfachen „Hier ist der Fehler, kannst du mir bei der Fehlersuche helfen?” Die KI zu fragen, wie du ihr helfen kannst, dir zu helfen, bringt oft überraschend schnell die Lösung.
💡 Pro-Tipp: Schick zuerst die einfachste nützliche Version, dann erweitere. Die gleiche Philosophie nutzen wir für Notion-Builds bei Kunden – bring ein grundlegendes System in den täglichen Einsatz und verbessere es dann aus echtem Feedback. Es ist wirklich schwer, im Vakuum gut zu designen.
📬 Möchtest du auf dem Laufenden bleiben, was es Neues bei Notion und KI gibt? Trag dich in den Newsletter ein und erhalte 41 kostenlose Notion-Ressourcen.
Häufig Gestellte Fragen
Muss Ich Programmieren Können, Um Eine Notion Chrome Extension Zu Bauen?
Nein. Der ganze Punkt dieses Workflows ist, dass die KI den Code schreibt. Deine Aufgabe ist es, als Product Owner zu agieren – klar zu beschreiben, was du willst, die richtigen Fragen zu beantworten und das Ergebnis zu prüfen. Du steuerst ein KI-Engineering-Team, anstatt selbst zum Engineer zu werden.
Welche Tools Brauche Ich, Um Anzufangen?
Du brauchst einen KI-Coding-Agenten (Claude Code oder Codex funktionieren beide gut), einen Code-Editor wie VS Code (hilfreich für die Erstellung der .env-Datei und das Durchsuchen deines Projektordners) und einen Notion-Integrations-Token aus dem Notion Developer Portal. Eine Diktat-App macht die Brainstorming-Phasen außerdem deutlich flüssiger.
Ist Es Sicher, Eine Chrome Extension Mit Meinem Notion Workspace Zu Verbinden?
Ja, solange du es vernünftig handhabst. Halte die Extension intern, statt sie zu veröffentlichen, speichere deinen Notion-Token in einer .env-Datei statt ihn in den Chat einzufügen, und gewähre deiner Integration nur Zugriff auf die spezifischen Datenbanken, die sie braucht. Du kannst die Integration auch auf Lesen beschränken, wenn sie nie zurückschreiben muss.
Wie Lange Dauert Der Build?
Der eigentliche Build ist schnell – für eine einfache Extension oft ein einziger Nachmittag. Den Großteil deiner Zeit investierst du in die vorgelagerten Phasen: Feasibility, PRD, Grill-Me-Session und Planning. Das ist so gewollt. Bring das richtig hin, und der Build selbst kann in nur 15–20 Minuten KI-Arbeitszeit laufen.
Was Sollte Ich Zuerst Bauen?
Starte mit der einfachsten nützlichen Version. Für eine CRM-Extension könnte das einfach „sag mir, ob diese Person schon ein Kontakt ist” sein. Bring sie zum Laufen und in den täglichen Einsatz, dann erweitere sie mit zusätzlichen Features wie dem Speichern von Unternehmen oder der Anzeige des Deal-Werts – jedes neue Feature läuft wieder durch den gleichen Fünf-Phasen-Loop.
💼 Benötigst du die Unterstützung zertifizierter Notion Berater? Mein Team und ich helfen dir gerne! → matthiasfrank.de/en/notion-consulting
