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단계 흐름입니다. 명세 작성, 계획, 작업 분해, 구현의 각 단계를 사람이 검토한 뒤에야 다음으로 넘어갑니다. 요청 하나에 독립적으로 테스트할 수 있는 여러 기능이 묶여 있으면 먼저 짧은 기능 지도(모듈 id, 의존 방향, 빌드 순서)를 만듭니다. 명세 작성 단계에서 에이전트는 가정을 소리 내어 나열하고, 확인 질문을 한 뒤, 여섯 가지 핵심 영역이 담긴 명세를 씁니다. 목표, 명령, 프로젝트 구조, 코드 스타일(실제 코드 조각 하나), 테스트 전략, 3단계 경계(항상 / 먼저 묻기 / 절대 안 함)에 성공 기준과 미해결 질문이 더해집니다. '더 빠르게 해 줘' 같은 모호한 요청은 구체적인 목표로 바꿉니다. 명세를 저장하면 그 턴은 끝나고, 승인된 뒤에야 계획이 시작됩니다. 명세는 버전 관리에 두는 살아 있는 문서입니다.
결과물
저장된 명세 파일(필요하면 기능 지도도), 가정과 미해결 질문 요약, 승인 요청.
이런 때 좋습니다
요구 사항이 아직 흐릿할 때 기능이나 프로젝트를 시작하는 경우, 범위가 분명한 PRD 초안을 쓰는 경우. 계획과 작업 단계는 같은 시리즈의 다른 Skill을 참조하지만 명세 작성 부분은 혼자서도 됩니다.
낮은 위험：지침만 있는 파일로 스크립트가 없습니다. 프로젝트에 Markdown 파일(명세, 이후 계획과 작업 목록)을 씁니다. 이 패키지에 없는 같은 시리즈 Skill(planning-and-task-breakdown 등)을 언급하지만 명세 작성 단계는 그것 없이도 동작합니다. 장보기 목록 앱에 대한 한 줄 아이디어로 한 번 시험했고, 가정을 나열한 뒤 SPEC.md를 임시 폴더에 저장하고 설계대로 승인과 여덟 가지 질문의 답을 기다리며 멈췄습니다. 코드는 쓰지 않았습니다. 작성자 Addy Osmani, MIT.