Starter Harness Designer – Coding v1

„Was Agenten nicht geschafft haben, lag nicht an mangelnden Fähigkeiten, sondern an einer unzureichenden Umgebung.“

Für wen ist dieses Skill gedacht?

Personen, die zum ersten Mal ein Coding-Harness erstellen
Nicht-Entwickler / Junioren, die ein Entwicklungsteam aufbauen möchten
Personen, die schnell mit bewährten Fullstack-, API- oder ML-Templates starten möchten

Es behält die gleiche 3-Phasen-Philosophie (Planner → Generator → Evaluator) wie das Profi-Skill harness-designer-coding bei, verteilt aber die Eingabekomplexität und Ausgabepräzision auf Einsteiger-Niveau neu.

Phase	Profi-Skill	Starter (dieses Skill)
Planner	4-stufige Discovery, offene Fragen	3 Multiple-Choice-Fragen → Exemplar-Nummernzuordnung
Generator	Entwurf → Datei-/Strukturerzeugung	Exemplar klonen + ersetzen
Evaluator	8 Säulen unabhängige Prüfung	Leichte Checkliste – nur fehlende Ersetzungen und defekte Referenzen

Skill-Matrix

              │ Profi (freies Design)              │ Einsteiger (Exemplar klonen)
──────────────┼─────────────────────────────────────┼───────────────────────────────────
 Arbeitsbereich │ harness-designer-workspace        │ harness-starter-workspace
──────────────┼─────────────────────────────────────┼───────────────────────────────────
 Coding        │ harness-designer-coding           │ harness-starter-coding ★ (dieses Skill)

Wann dieses Skill NICHT verwendet werden sollte:

Dokumente, Analysen, Inhalte erstellen → harness-starter-workspace
Fortgeschrittene Benutzer mit hohem Architektur-Freiheitsgrad → harness-designer-coding
Enterprise-Microservices → enterprise-Skill

Ausführungsablauf (insgesamt 5–10 Minuten)

1. [Planner] 3 Multiple-Choice-Fragen (App-Typ, Datencharakter, Größe)
2. [Planner] Exemplar-Nummernzuordnung + Scale-Mode-Empfehlung + Preset-Empfehlung
3. [Generator] harness-100 Exemplar klonen
4. [Generator] Projektnamen, Technologie-Stack, Domänenbegriffe ersetzen
5. [Evaluator] Leichte Checkliste (10 Sekunden)
6. Fertigstellungshinweis („Jetzt kannst du so entwickeln“)

Phase 0: Pattern Match (Planner)

Frage 1 – Was möchtest du erstellen? (Multiple Choice)

Nr.	App-Typ	Repräsentatives Exemplar
1	🌐 Fullstack-Web-App (Frontend + Backend + DB)	#16-fullstack-webapp
2	🔌 Nur API-Server	#18-api-designer
3	📱 Mobile App (iOS/Android)	#17-mobile-app-builder
4	🗃️ Daten-Pipeline / ETL	#27-data-pipeline
5	🤖 AI/LLM-App / RAG	#41-llm-app-builder
6	🧪 ML-Experiment / Modell-Training	#31-ml-experiment
7	🎨 Design-System (basierend auf shadcn)	#36-design-system
8	🔐 Sicherheitsaudit / Penetrationstest	#28-security-audit
9	🚀 Nur CI/CD / Infrastruktur	#20-cicd-pipeline
10	♻️ Legacy-Modernisierung / Refactoring	#22-legacy-modernizer

Frage 2 – Welche Größenordnung? (Multiple Choice → Scale-Mode automatisch)

Größe	Scale Mode	Eingesetzte Agenten
1-Personen-MVP / Prototyp	Single	Nur der Kern-Agent
Kleines Team / < 1 Monat	Reduced	3 Personen (Architekt + Kernentwickler + QA)
Mittleres Team / Produktion	Full	5 Personen (Architekt + Frontend + Backend + QA + DevOps)

Frage 3 – Wie heißt das Projekt?

Basierend auf dem Ordnernamen. Nach dem Technologie-Stack wird nicht gefragt – der Standard-Stack des Exemplars wird unverändert übernommen (bei Bedarf kann der Benutzer später selbst tauschen).

Standard-Stacks (ohne Austausch):

Fullstack: Next.js + Prisma + SQLite
API: FastAPI oder Express
Mobile: React Native (Expo)
Data/ML: Python + pandas + scikit-learn
RAG: Next.js + Vercel AI SDK + pgvector

Frage 4 – Soll ein Änderungsverlauf angelegt werden? (optional, ja/nein)

„Soll ein Bereich geschaffen werden, um festzuhalten, was sich geändert hat und warum, wenn dieses Harness später verbessert wird?“

ja → 05-flow-history/-Wiki + 00-system/protocols/flow-change-protocol.md automatisch erstellen (initialer Build als change 0001). Referenz: ~/.claude/skills/harness-designer-workspace/references/flow-history-template.md
nein → nicht erstellen (später manuell möglich)

Zweck: Retrospektive zu Flow-Verbesserungen, Grundlage für Rollbacks, Referenz beim Erstellen ähnlicher Harnesses. Für 1–2 Wochen Prototypen wird „nein“ empfohlen.

Verwaltungsprinzip: Dieses Log zeichnet nur Änderungen am Workflow-System (Prompts, Protokolle, Templates, Befehle, CLAUDE.md) auf. Ergebnisse, die das System produziert (Code, Build-Ergebnisse, Deployment-Logs), werden nicht erfasst. Abgrenzungskriterium: „Würde das nächste Ausführungsergebnis anders ausfallen, wenn diese Änderung nicht vorgenommen worden wäre?“ → Ja = Systemänderung = protokollieren / Nein = Ergebnis = nicht protokollieren. Details: 00-system/protocols/flow-change-protocol.md

Phase 1: Preset auswählen (Bewertungsgewichtung)

Preset	Beschreibung	Automatische Empfehlung
[Ausgewogen] (Standard)	Alle Qualitätskriterien gleich	Standard
[Qualität zuerst]	OWASP, Tests, Reviewer mit doppeltem Gewicht	Sicherheitsaudits, Zahlungs-, Medizin-, Finanzsysteme
[Geschwindigkeit zuerst]	Scale=Single, Tests minimieren	Hackathon, 1-Personen-Prototyp

Die Auswahl wird in _workspace/00_input.md protokolliert.

Phase 2: Generator – Exemplar klonen und ersetzen

Klon-Schritte (automatischer Fallback)

Die Verfügbarkeit von gh wird automatisch erkannt, um die optimale Download-Methode zu wählen. Auch mit nur git funktioniert es genauso.

EXEMPLAR="{NN}-{exemplar-name}"   # Planner-Matching-Ergebnis (z. B. 16-fullstack-webapp)
BASE="ko/$EXEMPLAR/.claude"

if command -v gh &>/dev/null && gh auth status &>/dev/null 2>&1; then
  # ── Methode A: GitHub CLI (gh) ──────────────────────────────
  echo "📡 Download via gh api..."
  FILES=$(gh api "repos/revfactory/harness-100/git/trees/main?recursive=1" \
    --jq ".tree[] | select(.path | startswith(\"$BASE/\")) | select(.type==\"blob\") | .path")
  mkdir -p .claude/agents .claude/skills
  while IFS= read -r filepath; do
    rel="${filepath#$BASE/}"
    dest=".claude/$rel"
    mkdir -p "$(dirname "$dest")"
    gh api "repos/revfactory/harness-100/contents/$filepath" \
      --jq '.content' | base64 -d > "$dest"
    echo "  ✅ $dest"
  done <<< "$FILES"
else
  # ── Methode B: git sparse checkout (wenn gh nicht verfügbar) ─────────────
  echo "📡 Download via git sparse checkout..."
  TMP=$(mktemp -d)
  git clone --depth 1 --filter=blob:none --sparse \
    https://github.com/revfactory/harness-100.git "$TMP"
  git -C "$TMP" sparse-checkout set "$BASE"
  mkdir -p .claude
  cp -r "$TMP/$BASE/." .claude/
  rm -rf "$TMP"
  echo "  ✅ Sparse Checkout abgeschlossen"
fi

Bedingung	Verwendete Methode	Benötigtes Tool
`gh` installiert + eingeloggt	Methode A (gh api)	gh
Nur `git` verfügbar	Methode B (sparse checkout)	git
Beide nicht verfügbar oder fehlgeschlagen	Methode C (Benutzerbestätigung, dann Claude erstellt direkt)	Keines

Wenn sowohl Methode A als auch B fehlschlagen, weist Claude den Benutzer direkt hin:

⚠️ Das Template konnte nicht von GitHub bezogen werden.

Ursache: Weder gh noch git sind verfügbar, oder es besteht keine Internetverbindung.

In diesem Fall kann Claude die Harness-Dateien direkt erstellen, basierend auf der Exemplar-Indexbeschreibung. Beachte: Es handelt sich dann nicht um das tatsächlich geprüfte Template, sondern um eine Rekonstruktion durch Claude, daher kann die Qualität abweichen.

Möchtest du fortfahren?

Ja → Claude erstellt die .claude/-Dateien direkt (basierend auf exemplar-index.md)

Nein → Abbruch. Bitte erneut versuchen, nachdem du eine Internetverbindung hergestellt oder git installiert hast.

Wählt der Benutzer Ja: Claude liest die Exemplar-Beschreibung in references/exemplar-index.md und erstellt direkt die Struktur aus CLAUDE.md, agents/ und skills/. Wählt der Benutzer Nein: Sofortiger Abbruch, Hinweis zur Wiederholung.

Nach Abschluss sieht die Struktur wie folgt aus:

.claude/
├── CLAUDE.md
├── agents/
│   ├── architect.md        – Anforderungen, Architektur, DB, API-Design
│   ├── frontend-dev.md     – React/Next.js (wird je nach Scale entfernt)
│   ├── backend-dev.md      – API, DB, Auth
│   ├── qa-engineer.md      – Tests, Code-Review (Reviewer)
│   └── devops-engineer.md  – CI/CD, Infrastruktur (wird je nach Scale entfernt)
└── skills/
    ├── {orchestrator}/skill.md
    ├── component-patterns/skill.md
    └── api-security-checklist/skill.md

Abhängig vom Scale-Mode werden Agenten-Dateien gelöscht:
- Single → nur architect (oder der relevanteste Agent)
- Reduced → architect + Kernentwickler + qa
- Full → alle 5 Agenten
_workspace/-Ordner erstellen. Nummerierungskonvention für Artefakte:
- 00_input.md – organisierte Benutzereingabe
- 01_architecture.md – Architekturentwurf
- 02_api_spec.md – API-Spezifikation
- 03_db_schema.md – DB-Schema
- 04_test_plan.md – Testplan
- 05_deploy_guide.md – Deployment-Anleitung
- 06_review_report.md – Review-Bericht

Ersetzungsregeln

Original	Ersetzung	Hinweis
Harness-Name	Benutzerprojektname	`16-fullstack-webapp` → `my-todo-app`
Technologie-Stack (Next.js/Prisma etc.)	Standard beibehalten	Nur ersetzen, wenn vom Benutzer explizit angegeben
Trigger-Keywords	Domänen-Keywords	„todo app“ → Projekt-Keywords
`_workspace/NN_*.md`	Beibehalten	Nummerierungskonvention niemals ändern
OWASP, SOLID, DORA-Injection	Unbedingt beibehalten	Kern der Domänenexpertise
Scale-Modes-Tabelle	Beibehalten	Definitionen von Full/Reduced/Single erhalten
`SendMessage`-Protokoll	Beibehalten	Kommunikationsmechanismus zwischen Agenten

Coding Agent Behavior Principles (Karpathy-inspiriert, obligatorisch einzufügen)

Nach dem Klonen des Exemplars muss unbedingt der folgende Abschnitt am Ende von .claude/CLAUDE.md hinzugefügt werden (nicht ersetzen, bewahren):

## Coding Agent Behavior Principles (Karpathy-inspiriert)

Alle Coding-Agenten befolgen bei ihrer Arbeit die folgenden 4 Prinzipien.
Details siehe Skill karpathy-guidelines (automatischer Trigger).

1. Think Before Coding – Annahmen explizit machen, bei Unklarheit nachfragen, Alternativen vorschlagen
2. Simplicity First – Nur das umsetzen, was angefordert wurde. Keine spekulativen Abstraktionen oder Funktionen
3. Surgical Changes – Nur die angeforderten Zeilen ändern. Keine Verbesserungen am umgebenden Code
4. Goal-Driven Execution – Überprüfbare Erfolgskriterien → Loop → Bestätigung

Füge zur leichten Evaluator-Checkliste den Punkt „CLAUDE.md enthält den Abschnitt mit den 4 Karpathy-Prinzipien“ hinzu.

Liste der nicht ersetzbaren Elemente

Framework-Namen: OWASP Top 10, SOLID, DDD, Test Pyramid, DORA Metrics, CWE Top 25, Star/Snowflake Schema, SHAP/LIME, Great Expectations
Protokolle: SendMessage, TaskCreate, TaskUpdate
Ordnerkonventionen: _workspace/, src/, Nummernpräfixe
Definitionen der Scale-Modes
3-Testszenarien-Struktur (Normal / Existing / Error)
Bkit-Autokorrektur: Karpathy-4-Prinzipien, OWASP Top 10, DORA Metrics, Scale-Modes dürfen NICHT durch bkit-Agenten (code-analyzer, pdca-iterator etc.) korrigiert werden
Loop-Elemente: Abschlusskriterien (Exit-Bedingungen), Reviewer-Reihenfolge (qa-engineer), Bewertungsformat des review_report – nicht ersetzen oder löschen (ein Loop benötigt Goal + Check + Exit-Bedingung, um gültig zu sein)

Begriffsklärung (für Benutzer)

Fachbegriff	Einfache Erklärung
architect	Planer / Architekt
frontend-dev	Frontend-Entwickler
backend-dev	Backend-Entwickler
qa-engineer	Qualitätsprüfer
devops-engineer	Bereitsteller / DevOps
Dependency DAG	Aufgaben-Reihenfolge
Scale Mode	Teamgröße

Interne Dateien behalten die Fachbegriffe, nur die Benutzerkommunikation verwendet die einfachen Erklärungen.

Phase 3: Evaluator – Leichte Checkliste

Automatische Prüfung (10 Sekunden)

Bei Fehlschlag

Fehlende Ersetzung → Planner erneut fragen
Verlust von Frameworks → Exemplar erneut klonen und ersetzen
Nach 3 Fehlversuchen → Hinweis auf Profi-Skill harness-designer-coding wechseln

Phase 4: Abschlusshinweis (einfacher Report für Nicht-Entwickler)

✅ Das Coding-Harness ist bereit!

📁 Speicherort: /my-todo-app/.claude/
👥 Entwicklerteam (Reduced-Modus, 3 Personen):
   - Planer (architect): DB- und API-Struktur entwerfen
   - Backend-Entwickler: Next.js-API + Prisma umsetzen
   - Qualitätsprüfer (qa): Tests und Code-Review durchführen

🛠️ Standard-Stack: Next.js + Prisma + SQLite (austauschbar)

🚀 So verwenden:
   1. Sage in Claude Code z. B. „Erstelle eine Login-Funktion für die Todo-App“
   2. Das Team arbeitet nacheinander:
      Planer → Backend-Entwickler → Qualitätsprüfer
   3. Ergebnisse: _workspace/01_architecture.md bis 06_review_report.md
   4. Quellcode wird im src/-Ordner erstellt

🔒 Sicherheit und Qualität vorinstalliert:
   - OWASP Top 10-Checkliste automatisch angewendet
   - Code-Review nach SOLID-Prinzipien
   - 3 Testszenarien (Normal, Vorhandene Datei, Fehler)

🔄 So arbeitet das Team (Loop):
   Das Team durchläuft einen Loop aus „Ziel (Goal) → Umsetzung → Check → Bei Bestehen fertig“.
   Der letzte Qualitätspruefer-Bericht (06_review_report.md) zeigt das Prüfergebnis.
   Falls dir das Ergebnis nicht gefällt, fordere einfach konkrete Nachbesserungen an –
   diese finale Entscheidung ist deine Aufgabe (äußerer Loop).

📘 Nächste Schritte:
   - Möchtest du das Team auf 5 Personen erweitern? Füge Frontend- und DevOps-Rollen hinzu (Full-Modus)
   - Für fortgeschrittene Anpassungen nutze das Skill harness-designer-coding

Referenzen

exemplar-index.md – 27 Coding-Exemplare + Scale-Modes + Framework-Index
Original: https://github.com/revfactory/harness-100 (Apache-2.0)
Profi-Variante: harness-designer-coding
Arbeitsbereichs-Variante: harness-starter-workspace

Starter Harness Designer – Coding v1 (für Einsteiger)

Was ist Starter Harness Designer – Coding v1 (für Einsteiger)?

In Ihrer bevorzugten KI fragen

Dokumentation