cc-prompt-builder

Name: cc-prompt-builder
Author: Svenja-dev

11installs5forks

How to install cc-prompt-builder?

svenja-dev/claude-code-skills/cc-prompt-builder

$npx -y skills add Svenja-dev/claude-code-skills --skill cc-prompt-builder

Installs into the current project.

Summary

Erstellt detaillierte, autonome Claude Code (CC) Prompts mit Self-Fix-Protokoll. Nutze diesen Skill IMMER wenn der User einen CC-Prompt, Claude Code Prompt oder Delegations-Prompt für eine mehrstufige Implementierung braucht. Trigger auch bei: "Prompt für CC", "lass CC das machen

Files · 1

View on GitHub

SKILL.md

1	# CC Prompt Builder
2
3	Du erstellst detaillierte Claude Code Prompts die CC autonom abarbeiten kann, inklusive Self-Fix bei Fehlern.
4
5	## Warum dieser Skill existiert
6
7	Ein gut strukturierter CC-Prompt mit exaktem Code, bekannten Fallstricken und Fix-Anweisungen spart massiv Tokens, weil CC weniger Erkundungs-Runden braucht. Das funktioniert besonders gut mit Sonnet (günstiger, folgt Anweisungen präzise, braucht aber Klarheit). Opus denkt besser selbstständig, kostet aber ein Vielfaches. Für die meisten Implementierungsaufgaben ist Sonnet + detaillierter Prompt die bessere Wahl.
8
9	## Wann NICHT verwenden
10
11	- Einzelne kleine Änderungen (1 Datei, <20 Zeilen) brauchen keinen Prompt, mach es direkt
12	- Reine Recherche-Aufgaben - CC braucht keinen Self-Fix-Loop für Recherche
13	- Der User will interaktiv mit CC arbeiten statt delegieren
14
15	## Prompt-Erstellung: Schritt für Schritt
16
17	### 1. Kontext sammeln (vor dem Schreiben)
18
19	Bevor du den Prompt schreibst, lies die relevanten Dateien im Projekt:
20	- Bestehenden Code der geändert wird (Importe, Exports, Konventionen)
21	- Config-Dateien (package.json, tsconfig, .env.example, CI-Workflows)
22	- Bestehende Tests als Referenz für Stil und Patterns
23
24	Das ist entscheidend: Der Prompt muss die richtigen Dateinamen, Imports, Selektoren und Konventionen enthalten. Sonnet rät nicht gut, es braucht exakte Angaben.
25
26	### 2. Prompt-Struktur (diese Reihenfolge einhalten)
27
28	Die Grundstruktur jedes CC-Prompts:
29
30	# [Aufgabe] - CC-Prompt für autonome Ausführung
31
32	## Kontext
33	- Was ist das Projekt (1-2 Sätze)
34	- Was wurde bereits gemacht (vorherige Phasen, Commits)
35	- Referenz-Dokumente die CC lesen soll
36
37	## Self-Fix-Protokoll (PFLICHT)
38	[Immer einfügen - siehe Template unten]
39
40	## Kritische Regeln
41	[Projektspezifische Fallen die CC kennen muss]
42
43	## Phase N: [Name]
44	### Datei: pfad/zur/datei.ts (NEU \| ERWEITERN)
45	[Exakter Code oder präzise Änderungsanweisungen]
46
47	### Ausführen und Fixen
48	[Konkreter Befehl + typische Fehler mit Lösungen]
49
50	## Abschluss: Commit
51	[git add + commit Befehl mit allen Dateien]
52
53	## Erwartete Ergebnisse
54	[Tabelle: Phase \| Datei \| Erwartung]
55
56	### 3. Self-Fix-Protokoll (immer einfügen)
57
58	Dieses Protokoll ist der Kern des Prompts. Es macht CC autonom:
59
60	## Self-Fix-Protokoll (PFLICHT für jede Phase)
61
62	Für JEDE Phase gilt dieser Loop:
63
64	1. Datei(en) erstellen/ändern
65	2. Ergebnis prüfen: [projektspezifischer Befehl, z.B. npm run build, pytest, npx playwright test]
66	3. WENN Fehler:
67	a. Fehlerausgabe lesen und analysieren
68	b. [projektspezifische Debug-Schritte]
69	c. Fix anwenden
70	d. Zurück zu Schritt 2
71	e. Max. 3 Fix-Versuche pro Teilaufgabe. Nach 3 Versuchen:
72	- Problem dokumentieren (Kommentar im Code oder TODO)
73	- Weiter zur nächsten Phase
74	4. WENN grün: Weiter zur nächsten Phase
75
76	Typische Fixes:
77	- [Liste projektspezifischer Fehler + Lösungen]
78
79	Am Ende ALLER Phasen: Zusammenfassung aller Ergebnisse zeigen.
80
81	### 4. Kritische Regeln formulieren
82
83	Sammle Fallen die CC in die Irre führen würden. Typische Kategorien:
84
85	- Namenskollisionen: Welche Funktion statt welcher verwenden
86	- Mock-Grenzen: Was Mocks können und was nicht
87	- Selektoren/Pfade: Tatsächliche Selektoren aus dem Code, nicht aus der Doku
88	- Env-Variablen: Welche nötig sind und wie Tests ohne sie übersprungen werden
89	- Bestehender Code: "ERWEITERN, nicht duplizieren" wenn Dateien existieren
90
91	### 5. Exakter Code vs. Prosa
92
93	Die Faustregel:
94	- Neue Dateien: Exakten, lauffähigen Code liefern. CC kopiert und passt an
95	- Erweiterte Dateien: Beschreibe WO der Code eingefügt wird und liefere den Code-Block
96	- Config-Änderungen: Zeige das Diff (vorher -> nachher) statt "ändere X"
97
98	Prosa-Beschreibungen wie "erstelle einen Test der X tut" funktionieren mit Opus, aber Sonnet braucht den konkreten Code.
99
100	### 6. Troubleshooting-Blöcke
101
102	Nach jeder Phase einen "Ausführen und Fixen"-Block mit dem exakten Testbefehl und projektspezifischen Symptomen + Lösungen:
103
104	- Selektor nicht gefunden -> DOM inspizieren, bestehende Tests als Referenz
105	- Timeout -> waitForLoadState statt waitForTimeout, Timeout erhöhen
106	- Import-Fehler -> exports prüfen, Pfade prüfen mit ls
107	- Feature existiert nicht -> graceful skip mit Begründung
108	- Build-Fehler -> TypeScript-Errors einzeln fixen, tsc --noEmit
109	- API-Fehler -> Mock prüfen, Route-Pattern vergleichen
110
111	### 7.

People who liked this also viewed

6 picks

Type

cc-prompt-builder

11installs5forks

View on GitHub

How to install cc-prompt-builder?

svenja-dev/claude-code-skills/cc-prompt-builder

$npx -y skills add Svenja-dev/claude-code-skills --skill cc-prompt-builder

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# CC Prompt Builder
2
3	Du erstellst detaillierte Claude Code Prompts die CC autonom abarbeiten kann, inklusive Self-Fix bei Fehlern.
4
5	## Warum dieser Skill existiert
6
7	Ein gut strukturierter CC-Prompt mit exaktem Code, bekannten Fallstricken und Fix-Anweisungen spart massiv Tokens, weil CC weniger Erkundungs-Runden braucht. Das funktioniert besonders gut mit Sonnet (günstiger, folgt Anweisungen präzise, braucht aber Klarheit). Opus denkt besser selbstständig, kostet aber ein Vielfaches. Für die meisten Implementierungsaufgaben ist Sonnet + detaillierter Prompt die bessere Wahl.
8
9	## Wann NICHT verwenden
10
11	- Einzelne kleine Änderungen (1 Datei, <20 Zeilen) brauchen keinen Prompt, mach es direkt
12	- Reine Recherche-Aufgaben - CC braucht keinen Self-Fix-Loop für Recherche
13	- Der User will interaktiv mit CC arbeiten statt delegieren
14
15	## Prompt-Erstellung: Schritt für Schritt
16
17	### 1. Kontext sammeln (vor dem Schreiben)
18
19	Bevor du den Prompt schreibst, lies die relevanten Dateien im Projekt:
20	- Bestehenden Code der geändert wird (Importe, Exports, Konventionen)
21	- Config-Dateien (package.json, tsconfig, .env.example, CI-Workflows)
22	- Bestehende Tests als Referenz für Stil und Patterns
23
24	Das ist entscheidend: Der Prompt muss die richtigen Dateinamen, Imports, Selektoren und Konventionen enthalten. Sonnet rät nicht gut, es braucht exakte Angaben.
25
26	### 2. Prompt-Struktur (diese Reihenfolge einhalten)
27
28	Die Grundstruktur jedes CC-Prompts:
29
30	# [Aufgabe] - CC-Prompt für autonome Ausführung
31
32	## Kontext
33	- Was ist das Projekt (1-2 Sätze)
34	- Was wurde bereits gemacht (vorherige Phasen, Commits)
35	- Referenz-Dokumente die CC lesen soll
36
37	## Self-Fix-Protokoll (PFLICHT)
38	[Immer einfügen - siehe Template unten]
39
40	## Kritische Regeln
41	[Projektspezifische Fallen die CC kennen muss]
42
43	## Phase N: [Name]
44	### Datei: pfad/zur/datei.ts (NEU \| ERWEITERN)
45	[Exakter Code oder präzise Änderungsanweisungen]
46
47	### Ausführen und Fixen
48	[Konkreter Befehl + typische Fehler mit Lösungen]
49
50	## Abschluss: Commit
51	[git add + commit Befehl mit allen Dateien]
52
53	## Erwartete Ergebnisse
54	[Tabelle: Phase \| Datei \| Erwartung]
55
56	### 3. Self-Fix-Protokoll (immer einfügen)
57
58	Dieses Protokoll ist der Kern des Prompts. Es macht CC autonom:
59
60	## Self-Fix-Protokoll (PFLICHT für jede Phase)
61
62	Für JEDE Phase gilt dieser Loop:
63
64	1. Datei(en) erstellen/ändern
65	2. Ergebnis prüfen: [projektspezifischer Befehl, z.B. npm run build, pytest, npx playwright test]
66	3. WENN Fehler:
67	a. Fehlerausgabe lesen und analysieren
68	b. [projektspezifische Debug-Schritte]
69	c. Fix anwenden
70	d. Zurück zu Schritt 2
71	e. Max. 3 Fix-Versuche pro Teilaufgabe. Nach 3 Versuchen:
72	- Problem dokumentieren (Kommentar im Code oder TODO)
73	- Weiter zur nächsten Phase
74	4. WENN grün: Weiter zur nächsten Phase
75
76	Typische Fixes:
77	- [Liste projektspezifischer Fehler + Lösungen]
78
79	Am Ende ALLER Phasen: Zusammenfassung aller Ergebnisse zeigen.
80
81	### 4. Kritische Regeln formulieren
82
83	Sammle Fallen die CC in die Irre führen würden. Typische Kategorien:
84
85	- Namenskollisionen: Welche Funktion statt welcher verwenden
86	- Mock-Grenzen: Was Mocks können und was nicht
87	- Selektoren/Pfade: Tatsächliche Selektoren aus dem Code, nicht aus der Doku
88	- Env-Variablen: Welche nötig sind und wie Tests ohne sie übersprungen werden
89	- Bestehender Code: "ERWEITERN, nicht duplizieren" wenn Dateien existieren
90
91	### 5. Exakter Code vs. Prosa
92
93	Die Faustregel:
94	- Neue Dateien: Exakten, lauffähigen Code liefern. CC kopiert und passt an
95	- Erweiterte Dateien: Beschreibe WO der Code eingefügt wird und liefere den Code-Block
96	- Config-Änderungen: Zeige das Diff (vorher -> nachher) statt "ändere X"
97
98	Prosa-Beschreibungen wie "erstelle einen Test der X tut" funktionieren mit Opus, aber Sonnet braucht den konkreten Code.
99
100	### 6. Troubleshooting-Blöcke
101
102	Nach jeder Phase einen "Ausführen und Fixen"-Block mit dem exakten Testbefehl und projektspezifischen Symptomen + Lösungen:
103
104	- Selektor nicht gefunden -> DOM inspizieren, bestehende Tests als Referenz
105	- Timeout -> waitForLoadState statt waitForTimeout, Timeout erhöhen
106	- Import-Fehler -> exports prüfen, Pfade prüfen mit ls
107	- Feature existiert nicht -> graceful skip mit Begründung
108	- Build-Fehler -> TypeScript-Errors einzeln fixen, tsc --noEmit
109	- API-Fehler -> Mock prüfen, Route-Pattern vergleichen
110
111	### 7.

People who liked this also viewed

6 picks

Type