Classification: architectural. This is a new project with no existing code, so there's no flow to treat as a bounded change. I'll follow the full path: questions, approaches, design, written spec, then an implementation plan. I won't write code, scaffold or install anything until you've approved the spec and the plan. If you'd rather have something lighter, tell me and I'll adjust.
Project context: you said the folder is empty and it isn't a git repo, so there's nothing to read or follow. I'll set up git when I write the spec, because the process commits the spec.
My understanding so far
What you said:
- You want a small command-line tool.
- It converts CSV files to JSON.
- It's a brand-new project.
What I'm assuming (please correct any of these):
- It's a single-purpose tool: one CSV in, JSON out, with no server or UI.
- The default output is an array of objects, using the header row as keys.
- It reads a file path or stdin and writes to stdout or a file.
- Success means you can run it on a normal CSV and get correct, valid JSON, including quoted fields and embedded commas.
I don't yet know why you need it or who will use it, and that decides most of the design. So here is my first question:
What will this tool mainly be used for?
- A. Personal or ad-hoc use. You run it by hand on files and want it quick and simple.
- B. Part of scripts or pipelines. It needs stdin/stdout support, predictable exit codes and machine-friendly behavior.
- C. Something you'll share or publish as a package for others.
- D. Something else. Tell me what.
I'll ask about language, type handling (for example, whether "42" becomes a number) and large-file handling after your answer, one question at a time.
Real run in an isolated folder with only this skill installed. Only the Skill and Read tools were enabled, so no command was run and no file was written. The example is fictional. The model classified the request, said which path it would follow and asked its first question without writing any code. The optional visual companion (a local server) was not run.
Was es macht
Ein Ablauf für das Denken vor dem Bauen. Zuerst ordnet es die Anfrage laut einem von drei Pfaden zu: Spike (Machbarkeitsfrage), begrenzte Änderung (klar umrissene Änderung an vorhandenem Code) oder Architekturarbeit (neues Projekt, neues Subsystem oder Schnittstellenänderung). Danach gilt ein hartes Gate: Jede Implementierungshandlung (Produktcode schreiben, Gerüst anlegen, Abhängigkeiten installieren, ein externes Projekt erstellen) ist untersagt, bis Sie die tatsächlich vorgelegte Phase freigegeben haben. Es stellt Klärungsfragen einzeln, schreibt sein Verständnis zur Korrektur zurück, schlägt zwei oder drei Ansätze mit Empfehlung vor und legt den Entwurf abschnittsweise vor; bei Architekturarbeit schreibt es eine Spezifikation, prüft sie auf Lücken und wartet auf Ihre Durchsicht, bevor es an den Skill writing-plans übergibt.
Optionaler visueller Begleiter
Bei Fragen, die gezeigt klarer sind als beschrieben, kann es Mockups und Diagramme im Browser anbieten, aber nur als eigene Nachricht und erst nach Ihrem Ja.
Geeignet für
Neue Funktionen, neue Projekte und alles, wo Sie sich zuerst über den Entwurf einigen wollen.
Mittleres Risiko: Auf dem Architekturpfad schreibt es die Spezifikation nach `docs/superpowers/specs/<Datum>-<Thema>-design.md` in Ihrem Projekt und committet sie in git. Der optionale visuelle Begleiter (nur nach Ihrer Zustimmung) startet einen lokalen Node.js-Webserver auf 127.0.0.1 mit zufälligem Port, geheimem Schlüssel und Abschaltung nach 4 Stunden Leerlauf und öffnet Ihren Browser; für Remote-Umgebungen gibt es die Option `--host 0.0.0.0`, die ihn im Netzwerk erreichbar macht. Sitzungsdateien liegen unter `.superpowers/brainstorm/` im Projekt. Während er läuft, lädt die Seite ein Logo vom Server des Anbieters (primeradiant.com) samt Skill-Version, wodurch dieser Server Ihre IP-Adresse sieht; mit `DISABLE_TELEMETRY=1` schalten Sie das ab. Nur der Dialog wurde getestet, der Server nicht ausgeführt.