Open-Source Pipeline

Open-Source Pipeline Skill

Jedes Projekt sicher als Open Source veröffentlichen durch eine 3-stufige Pipeline: Fork (Secrets entfernen) → Sanitize (auf Sauberkeit prüfen) → Package (CLAUDE.md + setup.sh + README).

Wann aktivieren

• Benutzer sagt "Mach dieses Projekt Open Source" oder "Veröffentliche es öffentlich"
• Benutzer möchte ein privates Repository für die öffentliche Veröffentlichung vorbereiten
• Benutzer muss Secrets entfernen, bevor er nach GitHub pusht
• Benutzer ruft /opensource fork, /opensource verify oder /opensource package auf

Befehle

Befehl	Aktion
/opensource fork PROJEKT	Vollständige Pipeline: Fork + Sanitize + Package
/opensource verify PROJEKT	Sanitizer auf bestehendem Repository ausführen
/opensource package PROJEKT	CLAUDE.md + setup.sh + README generieren
/opensource list	Alle bereitgestellten Projekte anzeigen
/opensource status PROJEKT	Berichte für ein bereitgestelltes Projekt anzeigen

Protokoll

/opensource fork PROJEKT

Vollständige Pipeline – der Hauptworkflow.

Schritt 1: Parameter sammeln

Projektpfad auflösen. Enthält PROJEKT einen /, als Pfad behandeln (absolut oder relativ). Sonst 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-Repository-Name?" (Standard: Projektname)
5. "Beschreibung für README?" (Projekt für Vorschlag analysieren)

Schritt 2: Staging-Verzeichnis erstellen

mkdir -p $HOME/opensource-staging/

Schritt 3: Forker-Agent ausführen

Den opensource-forker-Agent starten:

Agent(
  description="Fork {PROJEKT} für Open Source",
  subagent_type="opensource-forker",
  prompt="""
Projekt für Open Source fork

Quelle: {SOURCE_PATH}
Ziel: {STAGING_PATH}
Lizenz: {chosen_license}

Das vollständige Fork-Protokoll ausführen:
1. Dateien kopieren (ausschließen: .git, node_modules, __pycache__, .venv)
2. Alle Secrets und Anmeldeinformationen entfernen
3. Interne Referenzen durch Platzhalter ersetzen
4. .env.example generieren
5. Git-Historie bereinigen
6. FORK_REPORT.md in {STAGING_PATH}/FORK_REPORT.md generieren
"""
)

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

Schritt 4: Sanitizer-Agent ausführen

Den opensource-sanitizer-Agent 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. Secrets-Scan (KRITISCH)
2. PII-Scan (KRITISCH)
3. Scan interner Referenzen (KRITISCH)
4. Prüfung auf gefährliche Dateien (KRITISCH)
5. Konfigurationsvollständigkeit (WARNUNG)
6. Git-Historie-Audit

SANITIZATION_REPORT.md in {STAGING_PATH}/ mit BESTANDEN/FEHLGESCHLAGEN-Urteil generieren.
"""
)

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

Bei FEHLGESCHLAGEN: Ergebnisse dem Benutzer zeigen. Fragen: "Diese beheben und erneut prüfen, oder abbrechen?"

• Bei Behebung: Korrekturen anwenden, Sanitizer erneut ausführen (maximal 3 Versuche – nach 3 Fehlschlägen alle Ergebnisse präsentieren und Benutzer bitten, manuell zu korrigieren)
• Bei Abbruch: Staging-Verzeichnis bereinigen

Bei BESTANDEN oder BESTANDEN MIT WARNUNGEN: Mit Schritt 5 fortfahren.

Schritt 5: Packager-Agent ausführen

Den opensource-packager-Agent starten:

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

Projekt: {STAGING_PATH}
Lizenz: {chosen_license}
Projektname: {PROJEKT_NAME}
Beschreibung: {description}
GitHub-Repo: {github_repo}

Generieren:
1. CLAUDE.md (Befehle, Architektur, wichtige Dateien)
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: {license}
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? (ja/nein/zuerst überprüfen)

Schritt 7: GitHub-Veröffentlichung (nach Benutzerzustimmung)

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

---

/opensource verify PROJEKT

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

Agent(
  subagent_type="opensource-sanitizer",
  prompt="Bereinigung von {resolved_path} überprüfen. 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="Paketieren: {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 Layout

$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

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

Best Practices

• Für neue Versionen immer die vollständige Pipeline (Fork → Sanitize → Package) ausführen
• Das Staging-Verzeichnis bleibt bis zur expliziten Bereinigung bestehen – zur Überprüfung nutzen
• Vor der Veröffentlichung nach manuellen Korrekturen den Sanitizer erneut ausführen
• Secrets parametrisieren statt löschen – Projektfunktionalität erhalten

Verwandte Skills

Siehe security-review für die vom Sanitizer verwendeten Erkennungsmuster für Secrets.