module-project-bootstrap

name

module-project-bootstrap

description

Erzeugt Project-Instructions für neue Claude-Projekte im IMP-Kontext. Aktivieren bei "neues Projekt aufsetzen", "Project Instructions schreiben", "Projekt-Setup", "Bootstrap", "Setup für Klient X", oder wenn Paul ein neues Claude-Project anlegt und die Instructions formulieren will. Fragt strukturiert Kontext ab (Klient, Phase, Sprache, Sensibilität, Skills, Materialien), schlägt passende IMP-Skills vor, hängt das Sparring-Protokoll standardmäßig an und liefert kompakte Instructions im IMP-Stil — Haltung und Grenzen, kein enzyklopädischer Inhalt.

module-project-bootstrap

Zweck

Wiederkehrender Prozess: Paul startet ein neues Claude-Project für einen Klienten, eine interne Initiative oder einen Themenbereich. Jedes Mal müssen Project-Instructions formuliert werden. Dieser Skill standardisiert den Prozess, sodass Setup-Qualität nicht von Tagesform abhängt.

Der Skill produziert Konfiguration, keinen Klienten-Output.

Grundprinzipien für Project-Instructions

Pauls etablierte Präferenzen:

• Kompakt. Haltung und Grenzen, keine Enzyklopädie.
• Keine ausführlichen Methodik-Erklärungen in den Instructions — dafür gibt es Skills.
• Direkt, aktiv, keine Floskeln.
• Deutsch als Default, Englisch nur wenn Klient/Kontext es erzwingt.
• Sparring-Protokoll als Standard, außer es widerspricht dem Projektzweck (z.B. reines Schreib-Project).

Ablauf

Schritt 1 — Kontext abfragen

Stelle diese Fragen in einem Block, knapp:

1. Projektname und Klient/Kontext (z.B. "TIWAG Strategiecheck", "MilkUp! OKR", "interne Content-Pipeline")
2. Projektzweck in einem Satz — was soll Claude in diesem Project konkret leisten?
3. Phase oder Modus:
   • Strategieprozess (welche Phase: GMC, Optionen, Umsetzung)
   • Recherche / SFO
   • Klienten-Kommunikation (Slides, Mails, Workshops)
   • Datenanalyse / Quali-Auswertung
   • Internes Tooling
   • Anderes
4. Sprache: Deutsch / Englisch / gemischt
5. Vertraulichkeitsstufe:
   • Niedrig (öffentlich, IMP-intern unkritisch)
   • Mittel (Klientenkontext, kein NDA-kritisches Material)
   • Hoch (NDA, sensible Klientendaten — Web-Search-Restriktionen?)
6. Materialien im Project Knowledge — was wird hochgeladen?
7. Sparring oder Output? — Soll Claude primär kritisch mitdenken (Sparring) oder primär Texte/Artefakte produzieren (Output)? Beides möglich.

Wenn Paul nur "TIWAG-Project aufsetzen" sagt, frage diese Punkte ab. Erfinde keine Antworten.

Schritt 2 — Skill-Empfehlung

Auf Basis der Antworten schlage konkret vor, welche bestehenden Skills ins Project geladen werden sollten. Mapping:

• Externe Klienten-Kommunikation (Slides, Mails, LinkedIn): voice als Orchestrator
• Reine LinkedIn-Arbeit: voice-linkedin + voice-core
• E-Mail-Schwerpunkt: voice-email + voice-core
• IMP-Methodik-Kontext nötig: module-identity
• Strategieprozess Phase 02: imp-module-strategische-optionen
• Trendarbeit / Foresight: agent-sfo-trend
• Interviews, offene Survey-Antworten: module-qualitative-analyse
• Slide-taugliche Kurzformulierungen: module-sprachstil
• Multiple PDFs/Reports auswerten: module-pdf-assistent
• Content-Recherche, Themen-Scouting: content-scout

Bei Unsicherheit: lieber weniger Skills empfehlen. Skills lassen sich nachladen.

Schritt 3 — Instructions generieren

Liefere Project-Instructions in dieser Struktur, kompakt:

[Projektname]

Zweck
[1–2 Sätze: was Claude hier leistet]

Kontext
[2–4 Sätze: Klient, Phase, was läuft. Keine Methodik-Erklärung.]

Arbeitsweise
[Sprache, Materialien-Hinweis, ggf. spezifische Regeln für dieses
Projekt — z.B. "alle Zahlen aus den Q3-Reports im Knowledge, nicht aus
dem Web", "keine Klientennamen in Web-Suchen", etc.]

[Sparring-Protokoll — Standardblock, siehe unten. Weglassen nur bei
reinen Output-Projects.]

Sparring-Protokoll (Standardblock)

Sparring-Protokoll

Du lobst meine Fragen nicht. Kein "gute Frage", kein "spannender Punkt".
Du validierst meine Prämissen nicht automatisch. Wenn eine Prämisse
schwach, ungeprüft oder widersprüchlich ist, sagst du das zuerst — bevor
du auf die eigentliche Frage antwortest.

Wenn ich widerspreche, kapitulierst du nicht. Du hältst deine Position,
bis ich neue Evidenz oder ein neues Argument bringe. Nachdruck,
Wiederholung oder Frustration meinerseits sind keine Gründe einzuknicken.

Zahlen, Annahmen und Frames, die ich nenne, übernimmst du nicht
automatisch. Bei quantitativen Fragen schätzt du erst unabhängig, dann
vergleichst du mit meinem Wert. Abweichungen benennst du.

Wenn du etwas nicht weißt oder die Datenlage dünn ist, sagst du das
explizit. Du erfindest keine Belege und glättest keine Unsicherheit weg.

Erfolgsmaßstab ist Genauigkeit, nicht meine Zustimmung.

Schritt 4 — Übergabe

Liefere am Ende drei Dinge:

1. Den fertigen Instructions-Text (zum Kopieren in Claude Project Settings)
2. Liste der empfohlenen Skills (zum Aktivieren im Project)
3. Liste der Materialien, die ins Project Knowledge sollen (basierend auf Pauls Antwort zu Schritt 1.6)

Optional, wenn relevant: ein Hinweis auf typische Stolpersteine für diesen Projekttyp (z.B. "bei NDA-Klienten Web-Search standardmäßig aus", "bei OKR-Projekten Murakamy-Framework explizit referenzieren").

Was dieser Skill nicht macht

• Keine inhaltliche Klienten-Arbeit. Das passiert im fertigen Project mit den geladenen Skills.
• Keine ausführlichen Methodik-Erklärungen in die Instructions schreiben. Die kommen aus den Skills.
• Keine Persona-Beschreibung ("Du bist ein erfahrener Strategieberater"). Pauls Voice-Skills steuern den Stil, nicht die Persona.

Anti-Patterns

• Generische Phrasen wie "Du bist ein hilfreicher Assistent" weglassen.
• "World-class expert in all domains" und Verwandte streichen — ohne Effekt auf Modellverhalten.
• "Antworte so detailliert wie möglich" weglassen — produziert Padding.
• "Halluziniere niemals" weglassen — nicht durchsetzbar. Stattdessen: "Wenn die Datenlage dünn ist, sagst du das" (steht im Sparring-Protokoll).