gilde

← All craftbooks

Embeddable Feedback Widget

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

Build a single-file embeddable feedback, contact, or rating widget — a floating button that opens a small panel with a rating, a message field, and validation, then shows a thank-you state and persists submissions to localStorage. Scopes the fields, validation, and submission behavior first, designs the floating launcher and panel, then implements an accessible, self-contained widget that drops into any page. Feedback widgets fail when submit does nothing, validation is missing, or the panel cannot be closed, so the scope phase locks the field set and the submit-and-thank-you flow before any markup.

Steps

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

  1. Scopeplannerentry

    fields, validation, submit + thank-you behavior

    Show working prompt
    Scope the widget. (1) Define the fields: a rating (e.g. 1-5 stars or emoji), a message textarea, and an optional email — with which are required. (2) Specify validation and the inline error messages. (3) Define the launcher (a floating button) and the panel open/close behavior (and Escape/overlay-click to close). (4) Define submission: on valid submit, store the entry in localStorage and show a thank-you state with a reset/close. (5) Write an acceptance-criteria checklist of 6-8 items, e.g. 'a floating button toggles the panel open and closed', 'the panel can be dismissed', 'required fields block submit with an inline error', 'a valid submit shows a thank-you state', 'the submission persists to localStorage', 'the widget is keyboard-accessible (focus, Escape)', 'no console errors'. Write to notes/scope.md and via write_task_note. No design or HTML yet.
  2. Designdesigner

    launcher button, panel layout, states

    Show working prompt
    Design the widget UI. (1) Pick a palette (hex) and a fixed-position floating launcher (corner button with an icon/label). (2) Lay out the panel: heading, rating control, message field, optional email, and submit button. (3) Design the states: closed, open, validation-error, submitting, and thank-you. (4) Specify focus styles and that it overlays page content without breaking it (high z-index, contained styles). (5) Self-contained CSS, responsive. Write the visual spec to notes/design.md and via write_task_note. No HTML yet.
  3. Builddeveloper

    implement the widget in index.html

    Show working prompt
    Implement the widget in index.html (inline CSS + JS) to the scope and design, dropped onto a minimal demo page. (1) Render the floating launcher; clicking it toggles the panel open/closed, and Escape or an overlay click closes it. (2) Build the rating control, message textarea, and optional email with the specified validation; block submit and show inline errors when invalid. (3) On valid submit, push the entry (with a timestamp) to a localStorage array and switch to the thank-you state with a reset/close. (4) Manage focus for accessibility (focus the panel on open, restore on close). (5) Keep styles contained (scoped class names, high z-index). 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 the widget. Open index.html if possible: open and close the panel (button, Escape, overlay), try to submit empty, then submit a valid entry, and RELOAD to confirm persistence. Check EACH criterion from notes/scope.md and write PASS/FAIL with a reason: does the floating button toggle the panel, can it be dismissed, do required fields block submit with an inline error, does a valid submit show the thank-you state, does the submission persist to localStorage across reload, is it keyboard-accessible (focus + Escape), zero console errors? A submit that does nothing, or a panel that will not close, is a FAIL — 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