Mit dem Claude-Code-Harness gebauter Konfigurationsdatei-Generator – ConfigDeck

 (configdeck.dev)
3 Punkte von weedroot 28 일 전 | 1 Kommentare | Auf WhatsApp teilen

Ich habe ein kleines Tool namens ConfigDeck (https://configdeck.dev/ko) gebaut.
Generatoren für Konfigurationsdateien sind an sich kein seltenes Thema, aber die Art, wie ich es gebaut habe, war etwas experimentell, daher wollte ich meine Erfahrungen teilen.

Was ist das?

Da es lästig ist, beim Start jedes Projekts Konfigurationsdateien wie .eslintrc, prettier.config oder tsconfig aus früheren Projekten zu kopieren und einzufügen, habe ich es so umgesetzt, dass man Optionen auswählt und die Dateien anschließend herunterladen kann.

  • Unterstützung für 9 Konfigurationsdateitypen: ESLint, Prettier, TSConfig, Vite, Vitest, Next.js,
    .gitignore, .editorconfig, .env.example
  • Stack-Presets: React+Vite, Next.js, Astro, Node.js usw. erstellen mehrere Dateien auf einmal
  • Migration von .eslintrc → eslint.config.mjs (Flat-Config-Konvertierung)
  • Unterstützung für Koreanisch / Englisch
  • 100 % statische Website (Cloudflare Pages, 0 KB JS auf Inhaltsseiten)
  • Eingaben werden nur im Browser verarbeitet, keine externe Übertragung

Technologie-Stack: Astro 6 + Svelte 5 (Runes) + Tailwind 4 + TypeScript strict

Wie ich es gebaut habe — viel an AI delegiert

Diesmal habe ich versucht, mit Claude Code den Entwicklungsprozess selbst zu strukturieren.
Die grobe Ausrichtung der Planung und Zwischenchecks waren der menschliche Anteil; die Implementierung habe ich so weit wie möglich der AI überlassen. Es gab gelungene Teile, aber auch viele Umwege. Ich dachte, wenn ich den Prozess offenlege, könnte das für andere mit ähnlichen Versuchen nützlich sein.

Ich habe alle verwendeten Einstellungen im Verzeichnis .claude/ des Repositories offengelegt:
https://github.com/jsg3121/configDeck/tree/main/.claude

  • Harness-Dokumentation (CLAUDE.md, Konventionen, ADR usw.)
  • Domänenspezifische Agenten (config-maker, ui-publisher, ux-designer,
    qa-agent, seo-specialist usw.)
  • Slash-Skills (/lint-check, /code-review, /seo-audit, /research usw.)
  • Festgehaltene technische Entscheidungen per ADR
  • Automatisierungs-Hooks (Formatierung nach PostToolUse, Build-/Lint-Prüfung bei Stop)

Beim Schreiben habe ich vor allem auf „Why-First“ geachtet. Statt nur Regeln zu notieren, habe ich auch das Warum dazugeschrieben; dadurch hatte ich den Eindruck, dass die AI bei Edge Cases konsistenter entscheidet.

Die Agenten habe ich ungefähr für folgenden kollaborativen Ablauf aufgebaut:

product-planner → ux-designer → ui-publisher → qa-agent
(Planung) (Design) (Implementierung) (Validierung)

Für QA gibt es die Subagenten unit-tester, e2e-tester und static-analyzer; qa-agent sammelt deren Ergebnisse und erstellt daraus einen Report.

Versuch und Irrtum

Was gut war

  • Da Entscheidungen per ADR festgehalten wurden, war es auch später noch leicht nachzuvollziehen: „Warum wurde das so umgesetzt?“
  • Wenn Konventionen im Harness festgehalten sind, scheinen die Ergebnisse auch bei wechselnden Sessions vergleichsweise konsistent zu bleiben.
  • Durch die Aufteilung in domänenspezifische Agenten vermischen sich Planung und Implementierung nicht in einem einzigen Kontext, was das Nachvollziehen erleichtert.

Was schwierig war

  • Am Anfang gab es noch kein Harness, daher schwankte der Stil der Ergebnisse jedes Mal; bis zur jetzigen Form musste ich vieles mehrfach nachschärfen.
  • Die Token-Kosten waren belastender als gedacht, daher nutze ich zusätzlich einen separaten Leitfaden dafür, je nach Umfang zwischen Hauptdialog, Skills und Agenten zu wählen.
  • Da AI gelegentlich meldet, etwas sei gelungen, obwohl es das nicht ist, war es hilfreich, mit einem Stop-Hook Build und Lint automatisch prüfen zu lassen.

Ich würde noch nicht sagen, dass ich die richtige Antwort gefunden habe; vermutlich gibt es bessere Wege.

Links

Verwandte Beiträge

1 Kommentare

 
heycalmdown 27 일 전

Eine interessante Idee. Man arbeitet ja nicht immer nur an Greenfield-Projekten, daher wäre es umgekehrt auch spannend, wenn man eine bereits chaotisch gewordene config-Datei eingeben könnte und sie erklärt, welche Optionen was bedeuten, sodass man sie ein- und ausschalten kann.