Open-Source Pipeline

Open-Source Pipeline Skill

Öffnen Sie jedes Projekt sicher für Open-Source mit einer 3-stufigen Pipeline: Fork (Sekreten entfernen) → Bereinigen (Sauberkeit prüfen) → Verpacken (CLAUDE.md + setup.sh + README).

Wann aktivieren

• Benutzer sagt "dieses Projekt als Open-Source veröffentlichen" oder "öffentlich machen"
• Benutzer möchte ein privates Repository für die öffentliche Freigabe vorbereiten
• Benutzer muss Sekreten entfernen, bevor er zu GitHub pusht
• Benutzer ruft /opensource fork, /opensource verify oder /opensource package auf

Befehle

Befehl	Aktion
/opensource fork PROJEKT	Vollständige Pipeline: Fork + Bereinigen + Verpacken
/opensource verify PROJEKT	Sanitizer auf bestehendem Repo ausführen
/opensource package PROJEKT	CLAUDE.md + setup.sh + README generieren
/opensource list	Alle gestagten Projekte anzeigen
/opensource status PROJEKT	Berichte für ein gestagtes Projekt anzeigen

Protokoll

/opensource fork PROJEKT

Vollständige Pipeline — der Hauptworkflow.

Schritt 1: Parameter sammeln

Projektpfad auflösen. Wenn PROJEKT ein / enthält, als Pfad behandeln (absolut oder relativ). Andernfalls prüfen: aktuelles Arbeitsverzeichnis, $HOME/PROJEKT, dann Benutzer fragen.

SOURCE_PATH="<aufgelöster absoluter Pfad>"
STAGING_PATH="$HOME/opensource-staging/${PROJEKT_NAME}"

Benutzer fragen:

1. "Welches Projekt?" (falls nicht gefunden)
2. "Lizenz? (MIT / Apache-2.0 / GPL-3.0 / BSD-3-Clause)"
3. "GitHub-Organisation oder Benutzername?" (Standard: via gh api user -q .login erkennen)
4. "GitHub-Repo-Name?" (Standard: Projektname)
5. "Beschreibung für README?" (Projekt analysieren für Vorschlag)

Schritt 2: Staging-Verzeichnis erstellen

mkdir -p $HOME/opensource-staging/

Schritt 3: Forker-Agent ausführen

Den Agenten opensource-forker starten:

Agent(
  description="Fork {PROJEKT} für Open-Source",
  subagent_type="opensource-forker",
  prompt="""
Projekt für Open-Source-Veröffentlichung forken.

Quelle: {SOURCE_PATH}
Ziel: {STAGING_PATH}
Lizenz: {gewählte_lizenz}

Das vollständige Fork-Protokoll ausführen:
1. Dateien kopieren (ausgenommen .git, node_modules, __pycache__, .venv)
2. Alle Sekreten und Anmeldedaten entfernen
3. Interne Verweise durch Platzhalter ersetzen
4. .env.example generieren
5. Git-Verlauf bereinigen
6. FORK_REPORT.md in {STAGING_PATH}/FORK_REPORT.md generieren
"""
)

Auf Abschluss warten. {STAGING_PATH}/FORK_REPORT.md lesen.

Schritt 4: Sanitizer-Agent ausführen

Den Agenten opensource-sanitizer starten:

Agent(
  description="Bereinigung von {PROJEKT} überprüfen",
  subagent_type="opensource-sanitizer",
  prompt="""
Bereinigung des Open-Source-Forks überprüfen.

Projekt: {STAGING_PATH}
Quelle (als Referenz): {SOURCE_PATH}

ALLE Scan-Kategorien ausführen:
1. Sekreten-Scan (KRITISCH)
2. PII-Scan (KRITISCH)
3. Interne Verweise-Scan (KRITISCH)
4. Prüfung auf gefährliche Dateien (KRITISCH)
5. Konfigurationsvollständigkeit (WARNUNG)
6. Git-Verlaufsaudit

SANITIZATION_REPORT.md in {STAGING_PATH}/ mit PASS/FAIL-Ergebnis generieren.
"""
)

Auf Abschluss warten. {STAGING_PATH}/SANITIZATION_REPORT.md lesen.

Bei FAIL: Ergebnisse dem Benutzer anzeigen. Fragen: "Diese beheben und erneut scannen, oder abbrechen?"

• Bei beheben: Korrekturen anwenden, Sanitizer erneut ausführen (maximal 3 Wiederholungsversuche — nach 3 FAILs alle Ergebnisse präsentieren und Benutzer bitten, manuell zu korrigieren)
• Bei abbrechen: Staging-Verzeichnis bereinigen

Bei PASS oder PASS WITH WARNINGS: Mit Schritt 5 fortfahren.

Schritt 5: Packager-Agent ausführen

Den Agenten opensource-packager starten:

Agent(
  description="Verpackung von {PROJEKT} für Open-Source",
  subagent_type="opensource-packager",
  prompt="""
Open-Source-Verpackung für Projekt generieren.

Projekt: {STAGING_PATH}
Lizenz: {gewählte_lizenz}
Projektname: {PROJEKT_NAME}
Beschreibung: {beschreibung}
GitHub-Repo: {github_repo}

Generieren:
1. CLAUDE.md (Befehle, Architektur, Schlüsseldateien)
2. setup.sh (Ein-Befehl-Bootstrap, ausführbar machen)
3. README.md (oder vorhandene erweitern)
4. LICENSE
5. CONTRIBUTING.md
6. .github/ISSUE_TEMPLATE/ (bug_report.md, feature_request.md)
"""
)

Schritt 6: Abschließende Prüfung

Dem Benutzer präsentieren:

Open-Source-Fork bereit: {PROJEKT_NAME}

Ort: {STAGING_PATH}
Lizenz: {lizenz}
Generierte Dateien:
  - CLAUDE.md
  - setup.sh (ausführbar)
  - README.md
  - LICENSE
  - CONTRIBUTING.md
  - .env.example ({N} Variablen)

Bereinigung: {sanitization_verdict}

Nächste Schritte:
  1. Überprüfen: cd {STAGING_PATH}
  2. Repo erstellen: gh repo create {github_org}/{github_repo} --public
  3. Pushen: git remote add origin ... && git push -u origin main

Mit GitHub-Erstellung fortfahren? (yes/no/review first)

Schritt 7: GitHub-Veröffentlichung (bei Zustimmung des Benutzers)

cd "{STAGING_PATH}"
gh repo create "{github_org}/{github_repo}" --public --source=. --push --description "{beschreibung}"

---

/opensource verify PROJEKT

Sanitizer unabhängig ausführen. Pfad auflösen: Wenn PROJEKT ein / enthält, als Pfad behandeln. Andernfalls $HOME/opensource-staging/PROJEKT, dann $HOME/PROJEKT, dann aktuelles Verzeichnis prüfen.

Agent(
  subagent_type="opensource-sanitizer",
  prompt="Bereinigung überprüfen von: {resolved_path}. Alle 6 Scan-Kategorien ausführen und SANITIZATION_REPORT.md generieren."
)

---

/opensource package PROJEKT

Packager unabhängig ausführen. Nach "Lizenz?" und "Beschreibung?" fragen, dann:

Agent(
  subagent_type="opensource-packager",
  prompt="Verpacken: {resolved_path} ..."
)

---

/opensource list

ls -d $HOME/opensource-staging/*/

Jedes Projekt mit Pipeline-Fortschritt anzeigen (Vorhandensein von FORK_REPORT.md, SANITIZATION_REPORT.md, CLAUDE.md).

---

/opensource status PROJEKT

cat $HOME/opensource-staging/${PROJEKT}/SANITIZATION_REPORT.md
cat $HOME/opensource-staging/${PROJEKT}/FORK_REPORT.md

Staging-Struktur

$HOME/opensource-staging/
  mein-projekt/
    FORK_REPORT.md           # Vom Forker-Agent
    SANITIZATION_REPORT.md   # Vom Sanitizer-Agent
    CLAUDE.md                # Vom Packager-Agent
    setup.sh                 # Vom Packager-Agent
    README.md                # Vom Packager-Agent
    .env.example             # Vom Forker-Agent
    ...                      # Bereinigte Projektdateien

Anti-Patterns

• Nie ohne Benutzerzustimmung zu GitHub pushen
• Nie den Sanitizer überspringen — er ist das Sicherheitstor
• Nie nach einem Sanitizer-FAIL fortfahren, ohne alle kritischen Befunde zu beheben
• Nie .env, *.pem oder credentials.json im Staging-Verzeichnis belassen

Best Practices

• Für neue Veröffentlichungen immer die vollständige Pipeline ausführen (Fork → Bereinigen → Verpacken)
• Das Staging-Verzeichnis bleibt erhalten, bis es explizit bereinigt wird — zur Überprüfung nutzen
• Nach manuellen Korrekturen vor der Veröffentlichung den Sanitizer erneut ausführen
• Sekreten parametrisieren statt löschen — Projektfunktionalität erhalten

Verwandte Skills

Siehe security-review für die vom Sanitizer verwendeten Muster zur Sekretenerkennung.