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.
What it does
A gated workflow in four phases: Specify, Plan, Tasks, Implement, each reviewed by a human before the next. When a request bundles several independently testable capabilities, a short capability map comes first (module ids, dependency direction, build order). In the Specify phase the agent lists its assumptions out loud, asks clarifying questions and writes a spec with six core areas: objective, commands, project structure, code style (one real snippet), testing strategy and a three-tier boundary (always / ask first / never), plus success criteria and open questions. Vague asks such as "make it faster" are reframed into concrete targets. The turn ends after the spec is saved, and planning starts only after approval. The spec stays a living document in version control.
Output
A saved spec file (and a capability map when needed), a summary of assumptions and open questions, and a request for approval.
Good for
Starting a feature or project when requirements are fuzzy, and drafting a PRD with clear scope. It refers to sibling skills for the plan and task steps; the specification part works on its own.
Low risk: pure instructions with no scripts. It writes markdown files (the spec, and later a plan and task list) into your project. It mentions sibling Skills such as planning-and-task-breakdown that are not part of this package; the specify step works without them. Test-run once on a one-line idea for a shopping-list app: it listed assumptions, saved SPEC.md in a temporary folder and stopped to ask for approval and answers to eight questions, as designed. No code was written. By Addy Osmani, MIT.