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.
What it does
A workflow for the thinking that comes before building. It first classifies the request out loud as one of three paths: a spike (a feasibility question), a bounded change (a well-scoped edit to code that already exists) or architectural work (a new project, subsystem or interface change). A hard gate then forbids any implementation action (writing product code, scaffolding, installing dependencies, creating an external project) until you approve the stage that was actually presented. It asks clarifying questions one at a time, writes back its understanding for you to correct, proposes two or three approaches with a recommendation, presents the design in sections, and for architectural work writes a spec, checks it for gaps and waits for your review before handing off to the writing-plans skill.
Optional visual companion
For questions that are clearer shown than described, it can offer browser mockups and diagrams, but only as its own message and only after you say yes.
Good for
New features, new projects and anything where you want agreement on the design first.
Medium risk: on the architectural path it writes the spec to `docs/superpowers/specs/<date>-<topic>-design.md` in your project and commits it to git. The optional visual companion (only after you agree) starts a local Node.js web server on 127.0.0.1 with a random port, a secret key and a 4-hour idle shutdown, and opens your browser; a `--host 0.0.0.0` option exists for remote setups, which exposes it to the network. It stores session files under `.superpowers/brainstorm/` in your project. While it runs, the page loads a logo from the vendor's server (primeradiant.com) together with the skill version, which lets that server see your IP address; set `DISABLE_TELEMETRY=1` to switch this off. Trialled on the dialogue only; the server was not run.