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 协议。