Start with an app small enough to understand. A reading list lets you practise adding input, changing the page and saving data without setting up a server.
This tutorial guides you through asking for and checking a browser-only reading list. Allow 60–90 minutes. You need a text/code editor, a browser, a local HTTP preview offered by your code editor and an AI assistant. No paid API is required.
Read this example as text
Try this
- Add The Hobbit
- Submit spaces only
- Add the same title twice
- Refresh the page
Expect this
- One new entry
- Helpful message; no new entry
- Two independent entries
- Saved entries return
See the finished example
The embedded app works in memory. Open the complete example in its own tab to test saving and refreshing; the embedded version deliberately has no access to your site’s browser storage.
1. Agree the behaviour before requesting code
Use these requirements: add a non-empty title, mark an individual entry complete, remove an entry after confirmation and restore the list on reload. Duplicate titles are allowed. Changes that cannot be saved must produce a visible warning.
The implementation should use plain HTML, CSS and JavaScript. That is sufficient for this exercise; adding a framework would introduce setup work without being necessary to show the main behaviour.
2. Request the first increment
Build the first increment of a small browser reading-list app.
Use index.html, style.css and app.js, without libraries or a backend.
First implement only a labelled title input, submit button and list.
Reject blank/whitespace input, trim accepted titles, clear the input
after success and show status messages. Use textContent for user titles.
Return complete files and explain how to run them with a local HTTP preview.
Do not add storage, accounts or external services yet.Save the files with exactly those names and run them through your editor's preview. Confirm the page loads the stylesheet and script. Add two books and try spaces-only input.
3. Add completion and removal
Add a completion checkbox and a Remove button to each entry.
Give each entry a unique ID; duplicate titles must remain independent.
Use accessible labels and native controls. Ask for confirmation before
removing an entry. Keep input handling and status messages working.
Return the changed complete files and a short manual test checklist.Try two entries with the same title. Toggle and remove one. If both change together, the implementation is probably treating the title as an identifier. Show that reproduction to the assistant instead of accepting a cosmetic rewrite.
4. Save the list and show useful error messages
Persist the list in localStorage under the key helppromptai-reading-list-v1.
Save and load JSON. Validate loaded data before using it.
Handle unavailable storage and malformed saved data without silently
overwriting it. Show a visible warning and keep a usable in-memory list.
Do not claim cloud sync or permanent backup.Browser storage is tied to an origin and can raise errors. File-URL behaviour is not a reliable basis for a persistence tutorial, so use the same local HTTP address throughout. MDN localStorage documentation
5. Verify the complete app
Add, complete and remove entries, then refresh. Try keyboard-only operation. Enter markup-like text such as <b>example</b> and confirm it appears literally. Test a long title and a narrow viewport. Check the Console for errors.
Ask the assistant to explain each file and the storage format. If you cannot identify where data enters, changes and saves, request a simpler implementation before extending it.
Nothing happens: check file paths and the Console. List vanishes after refresh: verify the origin, save errors and chosen browser mode. Generated code replaces the whole app: supply the existing files and request one change at a time.
This is a guided build recipe; generated implementations need their own execution checks. It is not a claim that an unseen AI-generated app has already passed these tests.