Your build starts here
Replace bracketed details with your own goal, context, and checks. Keep the first build small enough to inspect.
Build [feature] as a complete user journey in the existing stack. A user should [action], receive [feedback], and see [confirmed result] after a reload.
Inspect the current interface, API contract, data model, and access rules. Define how drafts, optimistic feedback, and confirmed records differ. Keep request and response fields consistent, including missing values and date interpretation.
Verify the normal journey, a failed write, a repeated submission, and the intended ownership boundary. If the feature promises device sharing, check a separate client. Report configuration and migration needs, tests run, and what remains unverified in the assembled flow.Make this prompt yours
Replace bracketed fields with your goal, current behavior, and relevant evidence. Keep requirements that affect the task. Check the result against the acceptance criteria you supplied.
The docs behind it
These references explain the underlying concepts and APIs. The prompt templates and project plans are original examples to adapt to your own setup.
- MDN — Using Fetch and handling responses
- OWASP — Input validation
- SQLite — Transactions and commit behavior
Documentation links checked .
Editorial review · October 28, 2026
Supported: Original, unexecuted feature template. It appropriately asks for persisted state and failure tests rather than treating an optimistic interface as confirmed storage.