Automate a Booking or Checkout Flow
Automate a multi-step booking, reservation, or checkout flow end-to-end — select, fill details, choose options, confirm — with a hard dry-run/confirmation guard so it never accidentally commits a real transaction during development. Maps the step-by-step flow, the success/failure signals, and the safety guard FIRST, then builds the resilient step driver with waits and retries, then tests both the happy path and the failure/abort paths against a stub or dry-run. Mapping-the-flow-and-guard-before-build is what makes booking automation safe and reliable instead of a brittle, money-spending click bot.
Steps
Entry step: scope. Each step names the specialist role it wants; the full working prompt is expandable.
- Scope the flowplannerentry
step map, success/failure signals, safety guard
Show working prompt
Map the flow and its guardrails before automating. Step 1: write the ordered step map (e.g. open → search/select → enter details → choose options → review → confirm), and for each step the element to act on and the signal that the step advanced. Step 2: define the inputs the flow needs (dates, quantities, traveler/customer details, payment placeholders) and where they come from. Step 3: define the success signal (a confirmation number / page) and the failure signals (sold out, validation error, timeout) and the abort behavior for each. Step 4: define the SAFETY GUARD — a dry-run/confirm flag that, when not explicitly set, stops before the irreversible commit step and never submits a real payment; default to dry-run. Step 5: write an acceptance-criteria checklist ('every step has a verifiable advance signal', 'dry-run stops before commit and asserts readiness', 'happy path reaches confirmation when armed', 'failure signals abort cleanly with a reason', 'no real transaction in dry-run', 'flow is idempotent / re-entrant'). Call write_task_note with the step map + signals + guard + checklist and write notes/scope.md. No code yet. - Build the flow driverdeveloper
drive each step with waits, retries, and the guard
Show working prompt
Implement the booking driver to the locked step map. Step 1: read the dry-run/confirm flag first and honor it — in dry-run, perform every step up to but NOT including the irreversible commit, then report 'ready to confirm'. Step 2: for each step, perform the action, then wait for and assert the advance signal before proceeding (explicit waits, not fixed sleeps); on a transient failure retry with backoff a bounded number of times. Step 3: on a defined failure signal (sold out / validation), abort cleanly and record the reason rather than blindly proceeding. Step 4: when armed, perform the commit step and capture the confirmation number. Step 5: write a structured run-log of each step's outcome and write the driver as a runnable module. Call write_task_note with the module path, how the guard works, and a sample dry-run log.
- Test the flowdeveloper
assert happy path, failure paths, and the guard
Show working prompt
Prove the flow on every branch using a stub/dry-run — never a live commit. Step 1: write tests that drive the flow against a stubbed booking surface so no real transaction occurs. Step 2: assert the happy path advances through every step and reaches the confirmation signal when armed. Step 3: assert each failure signal (sold out, validation error, timeout) causes a clean abort with the right reason and does NOT proceed to commit. Step 4: assert the SAFETY GUARD — in dry-run the flow stops before the commit step and never submits, and that flag defaults to dry-run. Step 5: assert idempotency/retry — a transient failure is retried within the bound and a re-run does not double-book. Put the driver and tests in a code-with-tests file; run them and confirm green. Call write_task_note with the test path and the pass count.
- Evaluatereviewer
Grade the deliverable against every acceptance criterion. All pass → finish; any fail → loop back and fix the gap.
Show working prompt
Run booking_test.py (or trace it) and verify every criterion from notes/scope.md: every step asserts an advance signal, the happy path reaches confirmation when armed, each failure signal aborts cleanly with a reason and never commits, the safety guard defaults to dry-run and stops before the irreversible step, and retries/idempotency prevent double-booking. Critically confirm NO test performs a real commit. Write PASS/FAIL per criterion; on any failure, name it and loop back to test. 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: "test" })` 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. - 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.
- automate a booking
- auto-checkout flow
- reserve automatically
- automate a multi-step form
- complete a booking for me
Source
View this craftbook on GitHub · MIT license