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.
Qué hace
Un flujo de trabajo con aprobaciones en cuatro fases: Especificar, Planificar, Tareas e Implementar; cada una la revisa una persona antes de pasar a la siguiente. Cuando una solicitud agrupa varias capacidades que se pueden probar de forma independiente, primero se prepara un mapa breve de capacidades (IDs de módulo, dirección de dependencias, orden de compilación). En la fase de especificación, el agente enumera en voz alta sus suposiciones, formula preguntas de aclaración y escribe una especificación con seis áreas fundamentales: objetivo, comandos, estructura del proyecto, estilo de código (un fragmento real), estrategia de pruebas y límites en tres niveles (siempre / preguntar primero / nunca), además de criterios de éxito y preguntas abiertas. Las peticiones vagas, como «hazlo más rápido», se reformulan como objetivos concretos. El turno termina una vez guardada la especificación, y la planificación solo comienza tras la aprobación. La especificación se mantiene como un documento vivo en el control de versiones.
Resultado
Un archivo de especificación guardado (y un mapa de capacidades cuando sea necesario), un resumen de las suposiciones y las preguntas abiertas, y una solicitud de aprobación.
Adecuado para
Iniciar una funcionalidad o un proyecto cuando los requisitos son difusos, y redactar un PRD con un alcance claro. Hace referencia a Skills hermanas para los pasos de planificación y de tareas; la parte de especificación funciona por sí sola.
Riesgo bajo: instrucciones puras, sin scripts. Escribe archivos Markdown (la especificación y, más adelante, un plan y una lista de tareas) en tu proyecto. Menciona Skills hermanas como planning-and-task-breakdown, que no forman parte de este paquete; el paso de especificación funciona sin ellas. Se probó una vez con una idea de una línea para una aplicación de listas de compras: enumeró las suposiciones, guardó SPEC.md en una carpeta temporal y se detuvo para pedir aprobación y respuestas a ocho preguntas, tal como se había diseñado. No se escribió código. Por Addy Osmani, MIT.