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.
它做什麼
一套「動手之前先想清楚」的流程。它先大聲把請求歸為三條路徑之一:探索驗證(可行性問題)、有邊界的改動(對既有程式碼範圍明確的修改)或架構級工作(新專案、新子系統或介面變更)。隨後有一道硬性門檻:在你批准目前階段之前,禁止任何實作動作(撰寫產品程式碼、建立腳手架、安裝相依套件、建立外部專案)。它一次只問一個釐清問題,把自己的理解寫回給你來更正,提出兩三種方案並給出建議,分段呈現設計;架構級工作還會寫一份規格文件、自查缺漏,等你審閱後再交給 writing-plans Skill。
選用的視覺化助手
遇到「展示比描述更清楚」的問題,它可以提出用瀏覽器展示草圖與圖表,但這一條必須單獨發一則訊息,且只有你同意之後才會啟動。
適合什麼場景
新功能、新專案,以及希望先就設計達成共識的任何工作。
中風險:走架構級路徑時,它會把規格文件寫到你專案中的 `docs/superpowers/specs/<日期>-<主題>-design.md`,並提交到 git。選用的視覺化助手(只有你同意後才啟動)會在本機 127.0.0.1 以隨機連接埠啟動一個 Node.js 網頁服務,帶金鑰、閒置 4 小時自動關閉,並開啟你的瀏覽器;它還有一個 `--host 0.0.0.0` 選項用於遠端環境,那樣會暴露給網路。工作階段檔案存放在專案的 `.superpowers/brainstorm/` 下。執行期間,頁面會向廠商的伺服器(primeradiant.com)請求一張帶 Skill 版本號的 logo,對方因此能看到你的 IP;設定 `DISABLE_TELEMETRY=1` 可關閉。試用只涵蓋對話部分,沒有執行服務。