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.
できること
関門のある4段階のワークフローです。仕様化、計画、タスク分解、実装の各段階を人がレビューしてから次に進みます。1つの依頼に独立してテストできる複数の機能が含まれるときは、先に短い機能マップ（モジュール id、依存の向き、構築順）を作ります。仕様化の段階では、エージェントが前提を口に出して挙げ、確認の質問をしたうえで、6つの中核項目を含む仕様を書きます。目的、コマンド、プロジェクト構成、コードスタイル（実際のコード片1つ）、テスト方針、三層の境界（必ずする / 先に確認 / 決してしない）に加え、成功基準と未解決の問いです。「もっと速くして」のようなあいまいな依頼は具体的な目標に言い換えます。仕様を保存したらそのターンは終わり、承認されてから計画に入ります。仕様はバージョン管理に置く生きた文書です。
出力
保存された仕様ファイル（必要なら機能マップも）、前提と未解決の問いの要約、承認のお願い。
こんな場面に
要件がまだ固まっていないときの機能やプロジェクトの開始、範囲の明確な PRD の下書き。計画とタスクの段階は同シリーズの他の Skill を参照しますが、仕様化の部分は単独で使えます。
低リスク：指示のみのファイルでスクリプトはありません。プロジェクト内に Markdown ファイル（仕様、のちに計画とタスクリスト）を書き込みます。このパッケージに含まれない同シリーズの Skill（planning-and-task-breakdown など）に言及していますが、仕様化のステップはそれなしでも動きます。買い物リストアプリの一行のアイデアで一度試用し、前提を挙げ、SPEC.md を一時フォルダーに保存して、設計どおり承認と8つの質問への回答を待って止まりました。コードは書いていません。作者 Addy Osmani、MIT。