gilde

← All craftbooks

Pricing Page

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

Build a single pricing or plan-comparison page with tiered plan cards, a feature comparison, a highlighted recommended plan, and optionally a monthly/annual toggle that updates prices. Scopes the plans, features, and pricing model first, designs a comparison layout that makes the recommended tier obvious, writes the plan copy, then builds responsive HTML with a working billing toggle. Pricing pages fail when the toggle does not update prices or the tiers are not genuinely comparable, so the offer-scope phase locks the exact plans and feature matrix before any markup.

Steps

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

  1. Offer scopeplannerentry

    plans, feature matrix, pricing model, recommended tier

    Show working prompt
    Lock the pricing offer. (1) Define each plan (name, price, who it is for) — typically 3 tiers. (2) Build the feature matrix: the rows of features and which plans include each (yes/no/limit). (3) Mark the ONE recommended/most-popular plan. (4) Decide the billing model: flat, or monthly/annual with the annual discount and the exact prices for each. (5) Each plan needs a CTA. (6) Write an acceptance-criteria checklist of 5-8 items, e.g. 'each plan shows its price and CTA', 'the recommended plan is visually distinguished', 'the feature comparison is present and consistent', 'a monthly/annual toggle updates all prices' (if applicable), 'responsive at 375px and 1280px', 'no console errors'. Write to notes/offer-scope.md and via write_task_note. No design or HTML yet.
  2. Visual designvisual-designer

    comparison layout + recommended-plan emphasis

    Show working prompt
    Design the pricing layout. (1) Pick a palette (hex) with an accent reserved for the recommended plan and CTAs. (2) Lay out the plan cards side by side with the recommended one emphasized (border, badge, scale). (3) Design the feature comparison (per-card lists or a comparison table) so plans are easy to scan against each other. (4) Design the billing toggle and the CTA buttons. (5) Specify the responsive reflow (cards stack on mobile). Self-contained CSS. Write the visual spec to notes/visual-design.md and via write_task_note. No HTML yet.
  3. Copywritingcopywriter

    plan names, taglines, feature labels, CTA

    Show working prompt
    Write the pricing copy. (1) A page headline and subhead. (2) For each plan: a one-line tagline of who it is for. (3) Clear, consistent feature-row labels. (4) The CTA label per plan (and a note on the most-popular badge text). Keep it benefit-oriented and scannable. Write the copy keyed by plan/section to notes/copy.md and via write_task_note.
  4. Builddeveloper

    implement index.html with plan cards + toggle

    Show working prompt
    Implement index.html with inline CSS/JS to the offer, visual spec, and copy. (1) Palette as CSS variables; render the plan cards with prices, taglines, feature lists/table, and CTAs. (2) Visually distinguish the recommended plan (badge + emphasis). (3) If monthly/annual was scoped, build a toggle whose JS swaps every plan's displayed price to the right value. (4) Make the feature comparison consistent and scannable. (5) Responsive at 375px and 1280px; vanilla, no CDN. On a loop-back, fix only the named gaps without regressing passing criteria. write_task_note the path and passing criteria.
  5. Evaluatereviewer

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

    Show working prompt
    Evaluate the pricing page. Open/render index.html, flip the billing toggle if present, and resize. Check EACH criterion from notes/offer-scope.md and write PASS/FAIL with a reason: does each plan show price and CTA, is the recommended plan visually distinguished, is the feature comparison present and consistent, does the monthly/annual toggle update ALL prices correctly, is it responsive? A toggle that does not update prices, or inconsistent feature rows, 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.
  6. 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