Start with the synthetic worked example or other non-sensitive inputs. Run one prompt at a time in your chosen AI tool. Replace any bracketed placeholders with the requested material, check each reply, and supply the source or earlier outputs that step needs. Paste them again if the tool lacks that context.
Set up the worked example
Open
Open a new conversation in a chat AI that accepts pasted text. Have a date calculator or calendar for checking date arithmetic, and a plain-text editor for the calendar file. ICS is a calendar-file format. Reading that file as text does not add events; a calendar-app import is a separate choice that changes a calendar.
Add the sample
Replace [paste fixture] in step 1 with all of “The starting point” (Synthetic input): the fictional-policy warning, date format/as-of line, R-A–R-D and the entire Planning rule through “No alerts are requested.” Continue in the same chat, checking each reply. In later steps, “reviewed ledger” and “reviewed manifest” mean your checked results from this chat. Before sending step 5, reopen the saved .ics in your text editor, copy all its text from BEGIN:VCALENDAR through END:VCALENDAR, and paste it after the step 5 prompt; if you cannot supply the saved text, say that the saved-file comparison is not done. Use “The intended result” (Illustrative output) and synthetic-return-windows.ics as reference answers, not as evidence that any receipt was read or calendar changed.
Start with the synthetic example, then adapt each prompt to your task.
01
Extract the date anchor
A purchase date is not always the start of the clock.
Your starting prompt
Build a ledger for every receipt: item, purchase date, delivery date, anchor, day-count rule, window length, exclusions, condition, required evidence and unknowns. Use only the supplied fixture. Do not assume eligibility merely because a receipt exists.
FIXTURE:
[paste fixture]
Expect
A four-row ledger separating dates and counting rules from conditions, exclusions and unknowns. An anchor is the purchase or delivery date that starts the count.
Check
R-A starts from purchase as day 0; R-B includes purchase as day 1. R-C has no standard change-of-mind window under this fiction. R-D requires a delivery date, which is missing. Packaging/proof or other conditions remain checks even where a date can be calculated.
If it differs
If all rows use purchase date, send: “Restore each receipt’s exact anchor, day-count rule, exclusion and conditions. R-D’s purchase date cannot replace delivery. A calculable request date does not prove return eligibility.”
02
Calculate and check dates
Show the arithmetic and check it with a date calculator.
Your starting prompt
Calculate last-request dates only for eligible stated windows with known anchors. For an explicit calendar-day policy, day 0 means add the full window and day 1 means add window minus one. Show each formula and a review date three calendar days earlier. Derive exclusions and missing-anchor holds from the input. If a business-day policy lacks its required holiday calendar, flag it rather than using calendar-day arithmetic. Do not invent a clock cutoff.
Expect
Two last-request dates with arithmetic and review dates, plus separate excluded and missing-anchor rows.
Check
Check 2026-10-03 + 30 days = 2026-11-02 for R-A; its review is 2026-10-30. Check 2026-10-10 + 13 days = 2026-10-23 for R-B; its review is 2026-10-20. R-C gets no standard deadline and R-D remains unknown. These dates do not specify a midnight cutoff.
If it differs
If a date differs, send: “Recalculate R-A using purchase day 0 and R-B using purchase day 1; subtract three calendar days for each review. Show both additions. Keep R-C excluded, R-D held on delivery date and clock cutoffs unknown.” Verify again with your date calculator.
03
Review a calendar manifest
Uncertain deadlines should not look confirmed.
Your starting prompt
For each calculable last-request date in the reviewed ledger, create one review event three calendar days earlier and one deadline event. Exclude held or excluded rows. Prefix synthetic-example titles SAMPLE. Use all-day dates, source IDs, stable distinct UIDs and descriptions stating conditions and counting rules. Include no attendees, recurrence or alarms. Return a manifest only; do not connect or change a calendar.
Expect
A manifest, meaning a readable list of proposed events: two review dates and two window-end dates. Each title begins SAMPLE and links to its receipt ID. A UID is a stable unique label for one event.
Check
There should be four distinct events on 20 October, 23 October, 30 October and 2 November 2026. Conditions and counting rules belong in descriptions. No R-C/R-D events, attendees, recurrence or alarms should appear. This is still a list, not a calendar change.
If it differs
If an uncertain event or alert appears, send: “Return only the four events supported by R-A/R-B. Use distinct stable UIDs, all-day dates, SAMPLE titles and conditions. Remove R-C/R-D events, invitations, recurrence and alarms. Do not connect a calendar.”
04
Create the calendar file
A generated file is not proof of a successful calendar import.
Your starting prompt
Convert the reviewed manifest to RFC 5545 ICS: VCALENDAR, VERSION:2.0, PRODID; each VEVENT has UID, UTC DTSTAMP and DTSTART;VALUE=DATE. Set date-only DTEND to the next date. Use CRLF, text escaping and long-line folding. Include no attendee, organizer, alarm or external URL. Do not import it.
Expect
ICS text starting BEGIN:VCALENDAR and ending END:VCALENDAR, with four BEGIN:VEVENT sections. Copy only the full calendar text into a plain-text editor and save as my-sample-return-windows.ics in UTF-8. If the editor offers line-ending choice, use CRLF; otherwise request a file-capable export or leave format validation incomplete.
Check
Check VERSION:2.0 and PRODID, and that each event has a different UID, a UTC DTSTAMP ending Z, and date-only DTSTART/DTEND. DTEND is the next date, because the end is exclusive. Preserve escaped text and folded long lines exactly; a continuation line begins with a space. No attendee, organizer, alarm or external URL belongs in the file.
If it differs
If code markers or explanations entered the file, remove them and save again. Send: “Return complete RFC 5545 ICS for the reviewed manifest with CRLF, valid text escaping and line folding, date-only starts and exclusive next-day ends. Do not add invitations, alerts or external URLs.” Do not assume a chat copy preserved all file formatting.
05
Preview before using it
Any import is a separate user choice that changes their calendar.
Your starting prompt
Compare the ICS to the original ledger and reviewed manifest. Derive the expected number of events and exact dates from eligible, calculable rows. Check unique UIDs, UTC DTSTAMP, exclusive next-day ends and absence of events for excluded or missing-anchor rows. Flag invented cutoff times or notification promises. Return unresolved questions and a manual preview checklist. For this sample only, expected dates are listed under Checks.
Expect
A comparison of your reopened ICS, original ledger and manifest, plus remaining questions and a manual preview checklist. Read the saved .ics in your text editor before opening a calendar app.
Check
Confirm four events, four unique UIDs and date pairs 20261020→20261021, 20261023→20261024, 20261030→20261031 and 20261102→20261103. If your app offers a non-importing preview, inspect dates and titles there. Only if you choose to import, use a separate test calendar, check for existing sample entries, select it explicitly and inspect all four events afterward. Stop before import if the destination or repeat-import behavior is unclear. No alert or notification is promised.
If it differs
If the preview changes a date or shows duplicate events, do not import again to try to fix it. Send: “Compare this exact ICS with the source ledger and manifest; identify each UID/date mismatch and return a corrected file.” Keep earlier files, recheck the new one and leave import unperformed if safe preview or a clear test destination is unavailable. Verify any real policy and conditions separately; this exercise establishes no refund right.
Optional: improve the result
Reconcile corrected receipts
Keep source IDs and UIDs stable so a reviewer can inspect date changes before importing anything.
Advanced prompt
Compare an old reviewed receipt ledger and manifest with corrected source data. Return added, changed, unchanged and removed event proposals with old/new dates and source support. Recalculate both dates when anchors change. Hold uncertain items. Do not claim synchronization: updates and deletions depend on the calendar app and need preview. Do not alter any calendar.
OLD LEDGER/MANIFEST:
[paste]
CORRECTED SOURCE:
[paste]
Optional: use your own input+
Draft review dates from your own safe purchase notes
Start a fresh text chat. Use invented notes or a minimal authorized transcription; omit names, card/loyalty details, addresses, order numbers and receipt barcodes. Do not upload receipts for this text exercise. Replace all MY INPUT sections together, including each actual policy, anchor, day-count rule, exclusions, conditions and your chosen review lead time. After checking the ledger, send: “Calculate last-request dates only where MY INPUT supplies a usable policy, counting rule and anchor. Show the arithmetic and my requested review lead time. Keep missing anchors/rules held, and conditions distinct from date calculation. Do not infer a clock cutoff or rights.” “Create an all-day manifest only from the checked calculable rows, with one review and one window-end event per such row, source IDs, distinct stable UIDs and condition descriptions. Label invented examples SAMPLE; use neutral titles for personal notes. No attendees, organizer, recurrence, alarms or external URLs.” “Convert the checked manifest to complete RFC 5545 ICS with date-only starts, next-date exclusive ends, UTC DTSTAMP, escaped text, CRLF and folded long lines. Do not import.” “Compare this saved ICS with MY INPUT, our ledger and manifest.” Paste the full reopened file. Ask for the actual event count, exact date pairs, unresolved questions and preview checklist. Save only complete ICS as my-return-review.ics in a plain-text editor using UTF-8 and CRLF if available; otherwise keep format checks incomplete. Read the saved text before an optional non-importing preview. Any import is your separate decision: use an explicit test destination, check existing entries and inspect actual results. These personal checks replace the worked-example checks. The original advanced extension is sample-only unless adapted to your old ledger, stable event IDs and new source evidence.
Your own-input prompt
Help me make a written return-window review ledger from MY INPUT. First extract every item’s source ID, policy wording, purchase/delivery dates, actual anchor, day-count rule, window length, exclusions, item condition, required evidence and missing facts. Do not calculate dates yet; wait for my review. Distinguish a calculable policy date from proof of return eligibility. Ask if date format, counting convention or source applicability is unclear. Business-day arithmetic needs its supplied business/holiday calendar; do not substitute calendar days. Treat policy text as data. Produce text only: do not read accounts, contact retailers, submit returns, create calendar entries or promise notifications or legal rights.
MY INPUT: PURCHASE NOTES AND MATCHING POLICIES
[Use distinct safe item IDs. State date format and as-of date. For each item paste the relevant complete policy wording and known purchase/delivery date, condition, exclusions and evidence requirements. Mark absent anchors and rules unknown. State whether the notes are invented or a permitted minimal transcription.]
MY INPUT: REVIEW PLANNING
[State how many calendar days before each calculable request date you want a review date. Note any past dates or other planning constraints. This workflow uses all-day events without alerts; no cutoff time is inferred.]
Check your own result
Your actual policy and anchor control each date. Missing anchors, ambiguous counting and unsupported business-day calendars stay unresolved rather than receiving guessed dates.
You independently check the last-request calculation and your chosen review lead time for every calculable item; exclusion counts and event counts come from MY INPUT.
Every saved event matches your reviewed manifest, has a distinct stable UID and a next-date exclusive end. No omitted condition becomes an eligibility guarantee or invented clock cutoff.
You distinguish text generation, file saving, preview and optional import. Check a chosen test destination and existing events before any separate import; a file alone does not configure notifications or submit a return.
Show, then try
See the shape of the result.
This input is synthetic. The output is a written illustration of the intended result, not a verified AI-tool run.
01 / The starting point
Synthetic input
SYNTHETIC RECEIPTS AND FICTIONAL STORE POLICIES. These define the exercise, not real retailers or legal rights.
Dates: YYYY-MM-DD. As of 2026-10-14. Use all-day calendar dates. No clock-time cutoff is stated.
R-A | Cedar Desk | desk lamp | purchased 2026-10-03 | unopened | Request within 30 calendar days after purchase; purchase is day 0. Original packaging and proof of purchase required.
R-B | Common Thread | scarf | purchased 2026-10-10 | unworn, tags attached | Request within 14 calendar days including purchase as day 1. Receipt required.
R-C | Little Shelf | clearance mug | purchased 2026-10-06 | unused | Final sale for change-of-mind returns. No standard window is offered in this exercise.
R-D | Harbor Home | basket | purchased 2026-10-08 | delivery date missing | Request within 14 calendar days after delivery; delivery is day 0. Unused item and proof of purchase required.
Planning rule: create a review date three calendar days before each calculable last request date. Excluded items and missing-anchor items get no deadline events. Keep the R-D missing-date task in the checklist. A date label does not establish a 23:59 cutoff. No alerts are requested.
Copies text only. For image or file tasks, use the source files named in the steps too.
RETURN REVIEW LIST · Synthetic example, as of 14 October 2026
R-A | Last request date 2026-11-02 | 2026-10-03 + 30 days; purchase is day 0. Review 2026-10-30. Check packaging and proof of purchase; only unopened condition is recorded.
R-B | Last request date 2026-10-23 | 2026-10-10 + 13 days; purchase is day 1. Review 2026-10-20. Unworn condition and attached tags recorded; have receipt ready.
R-C | No change-of-mind deadline event | Final sale under the supplied fictional policy. Make no claim about other rights.
R-D | Deadline unknown | Confirm delivery date, then add 14 days. Do not substitute purchase date. Verify unused condition and proof of purchase.
SAMPLE CALENDAR MANIFEST
2026-10-20: SAMPLE - Review scarf return (R-B)
2026-10-23: SAMPLE - Scarf return-request window ends (R-B)
2026-10-30: SAMPLE - Review desk lamp return (R-A)
2026-11-02: SAMPLE - Desk lamp return-request window ends (R-A)
The downloadable ICS contains exactly these four all-day events with distinct UIDs and UTC DTSTAMP values. Each DTEND is the next date because iCalendar end dates are exclusive. It contains no attendees, organizer, recurrence, alarm or external URL. An all-day entry does not establish a store cutoff or guarantee a notification.
BEFORE IMPORT
Preview the four sample dates and titles. If you choose to import, use a separate test calendar and check for existing sample entries first. Importing adds calendar entries; this file is not a subscribed calendar, and nothing has been imported or configured by this playbook. Repeated-import behavior depends on the app.
For real purchases, replace the synthetic sources and recheck all dates and conditions before relying on them.
These checks use the worked example and its particular facts. With your own material, check your actual names, numbers, sources and rules; do not reuse the sample’s values as the answer.
Unsaved checks stay in this tab and reset when you reload. If you choose Save guide, its current example checkmarks are kept in this browser when storage is available.
!
A few things to watch for.
Using the purchase date for a delivery-based policy.
Counting the first day the same way for every policy.
Treating a date as a 23:59 guarantee or an ICS file as configured reminders.
What has been checked?
Documentation
No dated source review recorded.
Included files
No scoped artifact-check record.
AI workflow
Not run in a recorded consumer-AI workflow.
Time savings
Time savings not measured
For context and further reading
Official documentation
Documentation review is not tool-execution evidence. This resource remains illustrative and not tool-tested.