gilde

← All craftbooks

CRUD Web App

Build: interactive and webevalv1.0.0released 2026-06-05workflow: build-loop

Build a small single-file CRUD web app — a todo list, notes, contacts, or inventory manager — with create, read, update, and delete plus localStorage persistence so data survives a reload. Locks the data model and the four operations first, then a clean list-plus-form UI design, then builds vanilla JS with real state and persistence. CRUD apps fail when delete or edit silently does nothing or data vanishes on reload, so the model phase pins every operation's behavior before coding, the ordering that gets a small model to a genuinely working app.

Steps

Entry step: model-scope. Each step names the specialist role it wants; the full working prompt is expandable.

  1. Model scopeplannerentry

    entity fields + the four CRUD operations

    Show working prompt
    Pin the data model and operations. (1) Define the entity and its fields (e.g. todo: id, text, done, createdAt) and any validation (required fields). (2) Specify each operation precisely: Create (form -> new record), Read (list/render, any sort/filter), Update (edit in place or via form), Delete (with confirm?). (3) Decide persistence: localStorage key and shape; data must survive reload. (4) Note empty-state behavior. (5) Write an acceptance-criteria checklist of 6-8 items, e.g. 'adding creates a visible item', 'editing updates the item', 'deleting removes it', 'data persists across reload', 'invalid input is rejected', 'an empty-state message shows when there are no items', 'no console errors'. Write to notes/model-scope.md and via write_task_note. No design or HTML yet.
  2. UI designdesigner

    list + form layout, item states, empty state

    Show working prompt
    Design the app UI. (1) Pick a clean palette (hex) and type. (2) Lay out the input/add form and the item list; specify how each item renders with its edit and delete affordances. (3) Design the editing state (inline field or modal) and the confirm-delete interaction. (4) Design the empty state and any filter/sort controls. (5) Self-contained CSS, responsive, no external assets. Write the visual spec to notes/ui-design.md and via write_task_note. No HTML yet.
  3. Builddeveloper

    implement index.html with full CRUD + persistence

    Show working prompt
    Implement index.html with inline CSS/JS to the model and UI spec. (1) Keep an in-memory array of records, hydrated from localStorage on load. (2) Create: validate then push and re-render. (3) Read: render the list (with empty state) and any sort/filter. (4) Update: edit a record in place and re-render. (5) Delete: remove (with confirm if specified) and re-render. (6) Persist to localStorage on every mutation so a reload restores state. Vanilla JS, no CDN. On a loop-back, fix only the named gaps without regressing passing criteria. write_task_note the path and passing criteria.
  4. Evaluatereviewer

    Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.

    Show working prompt
    Exercise every operation. Open index.html if possible, add/edit/delete items, then RELOAD the page. Check EACH criterion from notes/model-scope.md and write PASS/FAIL with a reason: does add create a visible item, does edit update it, does delete remove it, does data persist across reload, is invalid input rejected, does the empty state show, zero console errors? The reload-persistence and the delete are the make-or-break checks — if either fails, FAIL and loop back to build.

Then route — this is the whole point of the loop:

- **Every criterion PASSES →** call `advance_task_step({ ref, stepId: "evaluate", next: "finish" })`.
- **Any criterion FAILS →** write the specific gaps to notes, then call `advance_task_step({ ref, stepId: "evaluate", next: "build" })` to loop back. The builder fixes exactly those gaps.

Never route to `finish` while any criterion is unmet. The build phase's completion gate already blocked a grossly-incomplete deliverable; your job is the judgment an automated check cannot make (does it actually work, read well, look right). After ~3 unproductive loops, stop and report DONE_WITH_CONCERNS so the user can step in.
  5. Finishdeveloper

    All acceptance criteria met. Stamp a short summary and report DONE.

    Show working prompt
    Every acceptance criterion passed. Write a one-paragraph DONE summary to task notes via `write_task_note`: what was built, the deliverable path(s), and a one-line confirmation that each criterion is met. Then report DONE.

Triggers

Phrases that suggest this craftbook to a crew.

Source

View this craftbook on GitHub · MIT license