gilde

← All craftbooks

Responsive HTML Email

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

Build a responsive HTML email template that renders across email clients — Outlook, Gmail, Apple Mail — using table-based layout, inline styles, and bulletproof buttons, for a newsletter, transactional, or promo send. Designs the visual structure and the client-safe constraints first, writes the copy, then builds the table-based HTML with all CSS inlined. Email is not the web: external CSS, flexbox, and modern selectors break, so the design phase locks the table layout and inline-only rule before any markup, the ordering that keeps a small model from producing a div-and-class email that renders broken in Outlook.

Steps

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

  1. Email designvisual-designerentry

    table layout, palette, client-safe constraints

    Show working prompt
    Design the email within email's constraints. (1) Pick a palette (hex) and a single web-safe font stack with fallbacks. (2) Lay out the structure as nested tables: a centered container (max ~600px), header/logo, hero, body sections, a bulletproof CTA button, and footer with unsubscribe. (3) State the hard rules: table-based layout, ALL CSS inline on elements, no external stylesheets, no flexbox/grid, images with width/alt and a text fallback. (4) Define the mobile behavior (single column, scalable text). (5) Write an acceptance-criteria checklist of 6-8 items, e.g. 'layout uses tables not divs', 'all styles are inline', 'container is max ~600px and centered', 'a bulletproof CTA button is present', 'a footer with unsubscribe exists', 'images have alt text', 'no external CSS or web fonts'. Write to notes/design.md and via write_task_note. No markup yet.
  2. Copywritingcopywriter

    subject, preheader, body copy, CTA label

    Show working prompt
    Write the email copy. (1) A subject line and a preheader (the preview snippet). (2) A headline and the body sections' copy, tight and scannable. (3) The CTA button label (action verb). (4) Footer text including an unsubscribe line and sender info. Match the send's purpose (newsletter, transactional, promo). Write the copy keyed by slot to notes/copy.md and via write_task_note.
  3. Builddeveloper

    implement email.html with table layout + inline CSS

    Show working prompt
    Implement email.html as a client-safe HTML email to the design and copy. (1) Use nested <table> layout with a centered max-600px container; NO divs-for-layout, NO external CSS, NO flexbox/grid. (2) Put every style inline on the element via style attributes. (3) Include the preheader as hidden preview text near the top. (4) Build a bulletproof CTA button (a styled table-cell anchor that survives Outlook). (5) Add alt text to images and a footer with an unsubscribe link. (6) Ensure it degrades to a single column on narrow widths. 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
    Evaluate the email for client-safety. Open/render email.html and inspect the source. Check EACH criterion from notes/design.md and write PASS/FAIL with a reason: is the layout table-based (grep for layout <div> — should be none), are ALL styles inline (no <style> block doing layout, no external <link>), is the container ~600px and centered, is there a bulletproof CTA button, a footer with unsubscribe, image alt text, and zero web fonts/external CSS? Any external CSS or div-based layout 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