| name | bootstrap |
| version | 3.0.0 |
| description | Setzt ein neues Projekt mit Governance-Framework auf โ interaktiver Block-Interview-Flow in 4 Schritten, Doku-Architektur mit Hub-Auto-Verlinkung, optionaler Learning-Loop L1/L2/L3. Verwenden wenn der Operator ein neues Projekt aufsetzen will oder "/bootstrap" sagt. |
| tools | ["Read","Write","Edit","Bash","Glob","Grep"] |
Bootstrap โ Neues Projekt aufsetzen (v3.0)
Setzt ein neues Projekt mit Governance-Framework auf. Der Flow ist in 4 Bloecke (A-D) strukturiert โ jeder Block mit klarem Fokus, keine Fragen-Batches.
Referenzen:
references/info-gathering.md โ Kern-Fragen (Block A)references/existing-infra-check.md โ Bestehende Infrastruktur (Block B)references/doc-architecture-proposal.md โ Doku-Architektur (Block C)references/optional-components.md โ Self-Healing / DocSync / Daemon / Learning-Loop (Block D)references/learning-loop.md โ L1/L2/L3 Designreferences/file-templates.md โ Dateischablonenreferences/skills-setup.md โ Skills aus GitHub ziehenreferences/global-registry-update.md โ SecondBrain-Integrationreferences/hooks-setup.md โ Governance-Hooks
Phase 0: Briefing (vor allen Fragen)
Den Operator zuerst informieren, dann starten:
Bootstrap v3.0 โ ich fuehre dich durch 4 Bloecke:
Block A โ Projekt-Kern (8 Fragen, ~3 min)
Block B โ Bestehende Infra (5 Fragen, ~3 min)
Block C โ Doku-Architektur (Vorschlag + Review)
Block D โ Optional-Komponenten (4 Ja/Nein-Fragen am Ende)
Danach lege ich das Projekt an. Gesamt ~15 min.
Bereit? [ja / spaeter]
Warte auf ja.
Phase 1: Block A โ Projekt-Kern
Lies references/info-gathering.md fuer die vollstaendige Fragenliste. Stelle die Fragen einzeln oder in kleinen Gruppen (max 3 pro Rueckfrage), nicht als Batch.
A.1 Stack-Frage (zuerst)
Was moechtest du entwickeln?
a) Node.js / JavaScript Backend (API, CLI, Daemon)
b) Frontend (React, Vue, Vanilla JS)
c) Full-Stack (Backend + Frontend)
d) Python (KI/ML, Scripts, FastAPI, Django)
e) Anderes / Noch nicht klar
Antwort als STACK_CHOICE merken โ bestimmt welche Linting-Tools angelegt werden:
| Wahl | Linter-Config | Formatter |
|---|
| a) Node.js | eslint.config.mjs | โ |
| b) Frontend | eslint.config.mjs + .prettierrc | Prettier |
| c) Full-Stack | beide | Prettier |
| d) Python | pyproject.toml (Ruff + Black) | Black |
| e) Anderes | eslint.config.mjs (generisch) | โ |
A.2 Projekt-Identitaet (3 Fragen)
1. Projektname? (z.B. MyAnalytics)
2. Ein-Satz-Beschreibung: Was macht das System?
3. Start-Version? (default 0.1.0)
A.3 Backlog (2 Fragen)
4. Issue-Prefix? (default aus Projektname abgeleitet, z.B. "MA-" fuer MyAnalytics)
5. Primaere Sprache fuer Doku? (de / en, default: de)
A.4 Architektur-Dimensionen + Add-ons (1 Frage)
6. Standard-Dimensionen (immer aktiv): Reliability, Data Integrity, Security,
Performance, Observability, Maintainability.
Zusaetzliche Add-ons aktivieren (Multi-Select)?
[ ] Privacy / DSGVO โ fuer Voice-Assistants, personenbezogene Daten, Tier-Modelle
[ ] Cost Efficiency โ bei LLM-lastigen / SaaS-Subscription-Projekten
[ ] Signal Quality โ bei ML / Analytics / Signal-Systemen
[ ] Compliance โ fuer regulierte Branchen (Gesundheit, Finanz, Legal)
Jedes aktivierte Add-on ergaenzt die Architektur-Dimensionen in ARCHITECTURE_DESIGN.md + entsprechende Sektion in SECURITY.md / GOVERNANCE.md.
Merken: ADDONS = [...aktivierte]
Phase-1-Checkpoint: Kurze Bestaetigung der Antworten ausgeben.
Phase 2: Block B โ Bestehende Infrastruktur
Lies references/existing-infra-check.md fuer den vollstaendigen Dialog-Flow.
Der Skill respektiert bereits vorhandene Infrastruktur โ nicht alles neu anlegen.
Hast du bereits folgendes eingerichtet? (jede Frage einzeln beantworten)
1. Projekt-Verzeichnis?
[a] Ja + absoluter Pfad
[b] Nein, neu anlegen โ wo? (absoluter Pfad)
2. GitHub-Repo?
[a] Ja + URL
[b] Nein, spaeter anlegen (keine Remote jetzt)
[c] Kein GitHub gewuenscht
3. Obsidian-Vault fuer Doku?
[a] Ja + absoluter Pfad
[b] Nein, nur im Repo dokumentieren
4. Backlog-System?
[a] Linear + Team-Slug
[b] Microsoft 365 Planner
[c] GitHub Issues
[d] Keines
5. API-Keys fuer das Projekt?
[a] Existieren bereits in .env
[b] .env.example reicht, Keys spaeter
Merge-Modus: Wenn ein Ordner/Repo/Vault existiert und Dateien enthaelt, vor dem Ueberschreiben fragen:
Warnung: {PROJECT_PATH} enthaelt bereits Dateien.
[a] Backup anlegen + Bootstrap fortsetzen
[b] Nur fehlende Governance-Dateien ergaenzen (merge)
[c] Abbruch
Merken: EXISTING_INFRA = {...} fuer weitere Phasen.
Phase-2-Checkpoint: Zusammenfassung ausgeben.
Phase 3: Block C โ Doku-Architektur-Vorschlag
Lies references/doc-architecture-proposal.md fuer die vollstaendige Begruendung.
Basierend auf Stack-Wahl (A.1) und Infra-Status (Block B) einen konkreten Doku-Struktur-Vorschlag praesentieren:
Vorschlag: 3-Schichten-Doku mit ARCHITECTURE_DESIGN.md als zentralem Hub
Schicht 1 โ Story-Specs (Repo)
Pfad: {PROJECT_PATH}/specs/<PREFIX>XXX.md
Zweck: Pro Story ein Spec, git-versioniert
Trigger: Pflicht vor jeder Code-Aenderung (spec-gate.sh)
Schicht 2 โ Component-Docs (Obsidian)
Pfad: {OBSIDIAN_VAULT}/02 Projekte/{PROJECT_NAME}/Components/*.md
Zweck: Lebende Doku pro Komponente (Stack, Status, offene Fragen)
Trigger: Update bei jedem /implement (T_last-Pflicht)
Komponenten-Vorschlag (basierend auf Stack): {STACK_SUGGESTION}
Schicht 3 โ Architektur-Vorgaben (Obsidian)
Pfad: {OBSIDIAN_VAULT}/02 Projekte/{PROJECT_NAME}/Architektur-Vorgaben.md
Zweck: Konsolidierte Leitprinzipien, Stack-Entscheidungen, verworfene Alternativen
Trigger: Update bei ADR-Aenderungen
Hub (Repo)
Pfad: {PROJECT_PATH}/ARCHITECTURE_DESIGN.md
Zweck: Einstiegspunkt fuer /ideation, /architecture-review, /implement
ยง9 Referenzen verlinkt automatisch auf alle obigen Dateien
Passt das? [ja / anpassen / skip Obsidian-Schicht]
Komponenten-Vorschlag (STACK_SUGGESTION) je nach A.1:
- Node.js Backend โ
api.md, db.md, background-jobs.md, auth.md
- Frontend โ
ui.md, state.md, routing.md, api-client.md
- Full-Stack โ
frontend.md, backend.md, api.md, db.md
- Python โ
cli.md, core.md, integrations.md, data.md
- Anderes โ fragt den Operator nach Komponenten-Namen
Operator kann Komponenten anpassen oder eigene eingeben.
Bei ja:
- Components-Skelette werden in Phase 4 angelegt
ARCHITECTURE_DESIGN.md ยง9 Referenzen wird initial befuellt- Optional
orphan-check.sh Hook wird in Phase 4 installiert (fragt explizit: "Hook, der prueft ob jede neue *.md im Hub registriert ist? [ja, empfohlen / nein]")
Bei anpassen: Dialog fragt welche Schichten + Pfade gewuenscht sind.
Bei skip Obsidian-Schicht: Alle Docs im Repo (docs/components/), kein SecondBrain-Anteil.
Phase-3-Checkpoint: Doku-Struktur bestaetigen.
Phase 4: Grundstruktur anlegen
4.1 Verzeichnisstruktur
mkdir -p {PROJECT_PATH}/{lib,agents,.claude/skills,.claude/hooks,specs,docs,journal}
4.2 Git-Repo initialisieren (falls noch nicht vorhanden)
cd {PROJECT_PATH}
git init
git remote add origin {GITHUB_REPO}
.gitignore aus references/file-templates.md anlegen.
4.3 Kern-Dateien aus Templates rendern
Aus references/file-templates.md mit Block-A-Angaben befuellen:
| Datei | Template-Sektion |
|---|
lib/config.js | config.js |
CLAUDE.md | CLAUDE.md (mit Hub-Regel) |
SYSTEM_ARCHITECTURE.md | SYSTEM_ARCHITECTURE.md |
ARCHITECTURE_DESIGN.md | ARCHITECTURE_DESIGN.md (Hub mit ยง9 Referenzen) |
INDEX.md | INDEX.md |
COMPONENT_INVENTORY.md | COMPONENT_INVENTORY.md |
.env.example | .env.example |
CHANGELOG.md | CHANGELOG.md |
specs/TEMPLATE.md | specs/TEMPLATE.md |
Aus references/governance-template.md:
GOVERNANCE.md mit Projektname + Prefix + aktivierten Add-ons
Aus references/issue-writing-guidelines-template.md:
.claude/ISSUE_WRITING_GUIDELINES.md mit ISSUE_PREFIX
Zusaetzlich Skelette:
DEVELOPMENT_PROCESS.md โ Verweis auf GOVERNANCE.mdSECURITY.md โ Minimales Skelett (Add-on-Sektionen: Privacy/Compliance falls aktiviert)
KERN-REGEL in CLAUDE.md: Jede neue Datei MUSS sofort in ARCHITECTURE_DESIGN.md ยง9 Referenzen UND INDEX.md eingetragen werden โ vor dem git commit.
4.4 Linting-Konfiguration
Basierend auf STACK_CHOICE โ siehe references/file-templates.md:
- Node.js / Full-Stack / Anderes โ
eslint.config.mjs (ESLint v9 Flat Config)
- Frontend / Full-Stack โ zusaetzlich
.prettierrc
- Python โ
pyproject.toml (Ruff + Black)
4.5 Component-Skelette (wenn Block C = ja)
Fuer jede Komponente aus dem Doku-Architektur-Vorschlag:
- Wenn Obsidian-Schicht:
{OBSIDIAN_VAULT}/02 Projekte/{PROJECT_NAME}/Components/{component}.md
- Wenn Obsidian geskipped:
{PROJECT_PATH}/docs/components/{component}.md
Skelett-Struktur siehe references/doc-architecture-proposal.md (Frontmatter + Zweck + Stack + Architektur + Konfiguration + Phase-Status + Verbundene Stories + Offene Fragen + Referenzen).
Alle Component-Docs werden in ARCHITECTURE_DESIGN.md ยง9 Referenzen eingetragen.
4.6 Governance-Hooks installieren
Siehe references/hooks-setup.md fuer Details.
Hooks:
spec-gate.sh โ blockiert git commit mit <PREFIX>XXX wenn Spec-File fehltdoc-version-sync.sh โ blockiert wenn lib/config.js VERSION erhoeht aber DOC_FILES nicht synchron- Optional (bei Block C = ja, orphan-check = ja):
orphan-check.sh โ blockiert wenn neue *.md nicht im Hub ยง9 registriert
Registrierung:
{
"hooks": {
"PreToolUse": [{
"matcher": "Bash",
"hooks": [
{ "type": "command", "command": "bash {PROJECT_PATH}/.claude/hooks/spec-gate.sh" },
{ "type": "command", "command": "bash {PROJECT_PATH}/.claude/hooks/doc-version-sync.sh" }
]
}]
}
}
Hinweis: Der Claude-Code-Harness kann .claude/settings.json bei Permission-Grants auto-regenerieren und Hook-Sektionen stripppen. Als robusten Fallback: Hooks zusaetzlich in .claude/settings.local.json (gitignored) registrieren.
Hook-Test (probeweise):
cd {PROJECT_PATH}
echo "test" > test.txt && git add test.txt
git commit -m "test: {ISSUE_PREFIX}1 โ should be blocked"
git restore --staged test.txt && rm test.txt
4.7 .env anlegen
Wenn B.5 == Ja (existiert): Operator setzt .env selbst โ Skill referenziert nur.
Wenn B.5 == Nein:
Ich habe .env.example angelegt. Bitte trage deine Keys in {PROJECT_PATH}/.env ein.
Variablen-Namen stehen in .env.example.
NIEMALS echte Keys im Chat nennen.
Warte auf Bestaetigung done bevor weiter.
4.8 Backlog-Labels einrichten
Wenn B.4 == Linear: Skill bietet an, Standard-Labels via Linear-MCP anzulegen:
architecture, bug, feature, refactor, docs, infra- Plus Add-on-Labels:
privacy (wenn Privacy aktiviert), compliance (wenn Compliance aktiviert)
Wenn B.4 == M365 Planner / GitHub Issues: Operator bekommt Label-Liste zum manuellen Anlegen.
Wenn B.4 == Keines: Skip.
4.9 Erster Git-Commit
cd {PROJECT_PATH}
git add -A
git commit -m "v{VERSION_START} โ Initial Governance Setup"
git push -u origin main
Phase-4-Checkpoint: Zusammenfassung der angelegten Dateien.
Phase 5: Skills installieren
Lies references/skills-setup.md fuer Details.
Skills werden aus dem offiziellen GitHub-Repo via git clone in einen Temp-Ordner geholt und in {PROJECT_PATH}/.claude/skills/ kopiert.
SKILL_SRC=$(mktemp -d)
git clone --depth 1 https://github.com/vibercoder79/KI-Masterclass-Koerting- "$SKILL_SRC"
Skill-Auswahl
Welche Skills installieren?
a) Minimum (ideation, implement, backlog)
b) Standard (+ architecture-review, sprint-review, research, security-architect, skill-creator)
c) Voll (alle verfuegbaren: + grafana, cloud-system-engineer, visualize, design-md-generator)
d) Manuell auswaehlen
Kopieren
Fuer jeden gewaehlten Skill:
cp -R "$SKILL_SRC/{skill}" "{PROJECT_PATH}/.claude/skills/{skill}"
Projekt-spezifische Anpassung (generisch, nicht trading-spezifisch)
.claude/ISSUE_WRITING_GUIDELINES.md wird aus references/issue-writing-guidelines-template.md gerendert (Issue-Prefix eingesetzt)implement/references/change-checklist.md enthaelt generische Change-Typen โ keine projekt-spezifische Anpassung noetig. Projekt-spezifische Spezial-Checklisten koennen spaeter via /skill-creator ergaenzt werden.
Aufraeumen
rm -rf "$SKILL_SRC"
Phase-5-Checkpoint: Installierte Skills auflisten.
Phase 6: Block D โ Optional-Komponenten
Lies references/optional-components.md fuer die Implementation-Details.
Jede Frage einzeln mit klarer Empfehlung und Default:
D.1 Self-Healing-Agent
Self-Healing-Agent einrichten?
(Cron alle 15 min: prueft Dok-Versionen, Datei-Integritaet, sendet Alerts)
Empfohlen: ab mehreren Mitwirkenden oder wenn Doku-Drift kritisch ist.
[ja / nein (default)]
Wenn ja: agents/self-healing.js aus references/self-healing-template.js rendern + Cron-Eintrag generieren.
D.2 DocSync zum Obsidian-Vault
DocSync zum Obsidian-Vault?
(Bei jedem /implement werden Component-Docs im Vault mit-aktualisiert)
Kein Cron โ laeuft als Manuelle-Aufforderung via implement-Skill T_last.
Empfohlen wenn Obsidian-Vault angegeben.
[ja (default wenn Vault) / nein]
Wenn ja: lib/doc-sync.js aus references/doc-sync-template.js rendern + Mapping Repo โ Vault.
D.3 Automation-Daemon (Linear-Webhook-Listener)
Automation-Daemon?
(Vollautomatische Story-Umsetzung ohne Operator-Freigabe โ Linear Webhook triggert /implement)
Nur fuer fortgeschrittene Setups mit Linear. Sicherheits-Implikationen beachten.
[ja / nein (default)]
Wenn ja: Setup-Schritte fuer Linear-Webhook + Daemon.
D.4 Learning-Loop-Level
Lies references/learning-loop.md fuer das vollstaendige Design.
Learning-Loop aktivieren?
Der Loop erfasst systematisch: was funktioniert hat, was nicht, naechste Experimente.
Trigger: /sprint-review. Speicherort: journal/ + optional Obsidian.
L1 โ Einfach (learnings.md, Bullet-Points โ empfohlen fuer Solo-Projekte)
L2 โ Strukturiert (Sprint-Journal mit Frontmatter โ empfohlen ab 10+ Sprints)
L3 โ SQLite (quantitative Metriken โ empfohlen ab 50+ Sprints)
nein (keine Lessons-Learned dokumentieren)
Default: L1. Welches Level?
Wenn L1/L2/L3 gewaehlt:
journal/-Struktur entsprechend anlegen.learning-loop-Config im Repo (Level speichern)- Wenn Obsidian aktiv:
04 Ressourcen/{PROJECT_NAME}/learnings.md als Cross-Link vom PMO-Hub
Learning-Loop wird von sprint-review gefuettert (Pflicht-Schritt am Ende des Reviews) und von ideation bei Story-Erstellung gelesen (Anti-Pattern-Warnung).
Phase-6-Checkpoint: Optional-Komponenten-Status.
Phase 7: Finalisierung
Lies references/global-registry-update.md fuer die genaue Pfad-Liste.
7.1 SecondBrain-Integration (wenn B.3 == Obsidian aktiv)
{OBSIDIAN_VAULT}/02 Projekte/{PROJECT_NAME}/ anlegen{PROJECT_NAME} - PMO HUB.md mit Projekt-Frontmatter, Phase-Tabelle, Backlog-Link, Referenzen-BlockComponents/, Decisions/, Meetings/, Research/ Ordner anlegenArchitektur-Vorgaben.md Skelett (wird bei /ideation mit Research-Konsolidierung gefuellt)- Eintrag in
{OBSIDIAN_VAULT}/00 Kontext/Projekte.md (Projekt-Index)
7.2 Globale Registry (~/.claude/)
Wenn der Operator in ~/.claude/CLAUDE.md eine Projekt-Tabelle hat:
- Projekt-Zeile ergaenzen (Name, Pfad, GitHub, Obsidian-Pfad, Sprint-Review-Frequenz)
- Skill listet Operator die Zeile vor, der bestaetigt den Einfuegepunkt
7.3 Finaler Commit
cd {PROJECT_PATH}
git add -A
git commit -m "v{VERSION_START} โ Complete Governance Bootstrap"
git push
7.4 Abschluss-Tabelle
| Phase | Was | Status |
|---|
| Block A | Projekt-Kern + Stack + Add-ons | done |
| Block B | Bestehende Infrastruktur | done |
| Block C | Doku-Architektur (3 Schichten + Hub) | done |
| Phase 4 | Grundstruktur (Dateien, Git, Linting, Hooks, Labels) | done |
| Phase 5 | Skills installiert ({skill_count}) | done |
| Block D | Optional-Komponenten | {D-Status} |
| Phase 7 | SecondBrain + Registry + Final-Commit | done |
7.5 VS Code Extensions (optional, basierend auf STACK_CHOICE)
Fuer alle Stacks:
- ESLint
dbaeumer.vscode-eslint
- SonarLint
SonarSource.sonarlint-vscode
- Error Lens
usernamehw.errorlens
- Claude Code
anthropic.claude-code
Node.js: REST Client humao.rest-client
Frontend / Full-Stack: Prettier esbenp.prettier-vscode, Auto Rename Tag formulahendry.auto-rename-tag, CSS Peek pranaygp.vscode-css-peek
Python: Python ms-python.python, Black Formatter ms-python.black-formatter, Ruff charliermarsh.ruff
7.6 Naechste Schritte
Bootstrap fertig. Weiter mit:
1. VS Code Extensions installieren (Liste oben)
2. cd {PROJECT_PATH} && claude
3. /ideation โ erste Story erstellen
4. Wenn Learning-Loop aktiv: nach 1-2 Sprints /sprint-review laufen lassen
Fehlerbehandlung
| Problem | Loesung |
|---|
| git push schlaegt fehl | SSH Key pruefen: ssh -T git@github.com |
| Linear API Fehler | Linear-API-Key in .env pruefen, Team-Slug validieren |
| Obsidian-Pfad nicht erreichbar | Pfad mit ls verifizieren, ggf. iCloud-Sync aktiv |
| Hook blockiert Commit | Spec-File anlegen aus specs/TEMPLATE.md, Agent-Pattern ausfuellen |
| doc-version-sync blockiert | Alle DOC_FILES auf neue VERSION setzen, dann git add |
| Harness strippt Hooks aus settings.json | Hook-Registrierung in .claude/settings.local.json (gitignored) als Fallback |
| Component-Doc fehlt nach /implement | T_last-Task im specs/TEMPLATE.md pruefen โ muss Component-Update enthalten |
| Learning-Loop-Eintrag vergessen | /sprint-review erneut aufrufen, Schritt 7 ausfuehren |
