I've saved the draft spec to SPEC.md in the current folder. I haven't started planning or coding.
You hadn't decided anything else, so the spec rests on a set of assumptions, listed at the top of the file. The main ones:
- Platform: a mobile-first web app that can be installed as a PWA.
- Households: one household per user, with 2–10 people sharing one list.
- Sign-in: email magic links (no passwords), with invite links to join a household.
- Stack: TypeScript with React and Vite on the front end, and Fastify with WebSockets and SQLite on the back end.
- Sync: the server is the source of truth. Clients apply changes immediately and queue them while offline. Conflicts resolve as last write wins per item.
- Offline: the app has to keep working when reception drops in the shop.
The spec covers the six areas (objective with user stories and non-goals, tech stack, commands, project structure, code style, testing strategy), plus a boundaries section. It also has a data model sketch, the realtime behaviour, and eight testable success criteria. One example is changes showing up on another device within 1 second. Another is that one household can never see another's data.
Eight open questions need your input, and these matter most:
- Is a PWA acceptable, or do you want native apps?
- Are magic links OK for sign-in? They need an email provider.
- Where will it be hosted? This decides between SQLite and Postgres.
- Do you need more than one list per household?
- Is this just for your family, or a public product? A public product adds rate limiting, account deletion and privacy work.
The other three questions are in the file. They cover how deep offline support should go, whether last write wins is acceptable, and which extras (such as push notifications) belong in v1.
Please approve the spec or tell me what to change. Once you approve it, I'll move on to the implementation plan and task breakdown.
Test run: a one-line idea for a family shopping-list app. The model listed its assumptions, saved a draft SPEC.md in a temporary folder and stopped to ask for approval and answers to eight open questions, as the Skill requires. No plan or code was written.
它做什麼
一個有關卡的四階段流程：明確規格、制定計畫、拆分任務、實作，每一階段結束都要由人審閱才能進入下一階段。如果一個需求打包了好幾個可以獨立測試的能力，會先出一張簡短的能力地圖（模組 id、相依方向、建置順序）。在「明確規格」階段，智能體會先把自己的假設說出來，提出釐清問題，再寫出包含六個核心部分的規格：目標、指令、專案結構、程式風格（一段真實程式碼）、測試策略與三層邊界（一律 / 先問再做 / 絕不），外加成功標準與未決問題。像「讓它更快」這樣模糊的要求，會被改寫成具體目標。規格儲存後本回合就結束，只有獲准之後才開始規劃。規格是放在版本控制裡的活文件。
輸出
儲存好的規格檔（需要時還有能力地圖）、假設與未決問題的摘要，以及請你核准的請求。
適合什麼場景
需求還模糊時開始一個功能或專案，以及起草範圍清楚的 PRD。計畫與任務這兩步它會引用同系列的其他 Skill，規格部分可以單獨使用。
低風險：純指令檔，沒有腳本。它會在你的專案裡寫 Markdown 檔案（規格，之後還有計畫與任務清單）。它提到了本套件沒有包含的同系列 Skill（如 planning-and-task-breakdown），沒有它們，明確規格這一步也能用。已用一個購物清單應用的一句話想法試用一次：列出了假設，把 SPEC.md 儲存在暫存資料夾，並依設計停下來等你核准與回答八個問題，沒有寫任何程式碼。作者 Addy Osmani，MIT 授權。