The guest standing in front of you right now: 10 AI skills for service recovery
walkout-and-dispute-log
turns a walkout into a logged incident the police could actually use
How the two work together
Claude thinks it through. Paste the Claude prompt into Claude Code, or drop the folder into your skills folder. Claude does the judgement: what to look for, what is worth doing, what is right.
Codex gets it done. At the hand-off point Claude runs Codex on your machine with one command and passes it the Codex prompt. Codex does the mechanical part and hands the result back. Claude checks it before you see it.
No API key to set up: Claude calls the Codex you already have installed. If Codex is not installed, Claude does that half itself and tells you.
Prompt for Claude
--- name: walkout-and-dispute-log description: Turns a walkout or a disputed charge into a written record built against the actual offence it may be, "making off without payment" under the Theft Act 1978, with the facts the police would ask for recorded immediately rather than reconstructed from memory a week later, and a clear line between logging the incident and deciding whether to call the police at all. Use the moment a table leaves without paying or a guest disputes a charge after the fact. --- # A walkout, logged as the record it might need to become Does not decide whether to call the police, and does not chase the guest. Writes down what happened, when, in the words the offence actually uses, so a later report is already built. ## What it does 1. **Names the offence before writing anything down.** Section 3(1) of the Theft Act 1978: a person "who, knowing that payment on the spot for any goods supplied or service done is required or expected from him, dishonestly makes off without having paid as required or expected and with intent to avoid payment of the amount due shall be guilty of an offence." Three elements: knowledge, dishonesty, intent. 2. **Records knowledge of the expectation to pay.** What was ordered, whether prices were visible, whether a tab was opened. Section 3(2) extends "payment on the spot" to "payment at the time of collecting goods on which work has been done," covering a takeaway as much as a dine-in walkout. 3. **Records dishonesty and intent as observed facts, not a conclusion.** Did the party leave through an exit away from the till, while staff were occupied, without saying anything, after being asked to settle. 4. **Records the one statutory exception.** Section 3(3): the offence "shall not apply where the supply of the goods or the doing of the service is contrary to law, or where the service done is such that payment is not legally enforceable." 5. **Keeps the amount, the evidence, and the decision to report separate.** The amount, any CCTV or till reference, and witnesses are facts. Whether to call the police is a business decision this skill does not make. ## Then it checks 1. All three elements are recorded separately, not merged into one description. 2. The amount, time, and any evidence reference are recorded, never estimated. 3. Any case where the service might not be legally chargeable is flagged, not logged as an ordinary walkout. 4. No entry states a conclusion that an offence was committed. 5. No entry has been altered; a correction is a new line. Any check fails: name it, redo that step once. Failed twice: say what is wrong and stop. ## Rules - Public information only. Never invent a fact, a number or a quote. Anything sent in someone's name says whose name it is. - Never decide, or recommend, whether to call the police. - Never describe a disputed charge as theft in the log itself; record only what was observed. - Never contact or threaten the named guest; this is an internal record, not a collection tool. - A working incident record for the owner to decide what to do with, and for police or a solicitor to review; not a finding that any offence occurred. ## Built from - Theft Act 1978, section 3, https://www.legislation.gov.uk/ukpga/1978/31/section/3, read 4 Nov 2026: the offence, its elements, its extension, and its exception, behind every step.
Prompt for Codex
# walkout-and-dispute-log
## You are given
An incident report in the owner or manager's own words: what was ordered, what was observed, when, and by whom. Till or booking system records of the order and the amount. Any CCTV or card-reader reference numbers. A witness list, where available. Any previous walkout-and-dispute log for this venue.
## Produce
Write into a `./walkout-and-dispute-log-output/` folder:
1. `incidents.csv` with columns: `incident_id`, `date`, `time`, `amount_unpaid`, `order_summary`, `payment_expectation_evidence`, `dishonesty_facts_observed`, `intent_facts_observed`, `legally_enforceable_flag`, `evidence_references`, `witnesses`, `staff_reporting`. `incident_id` is W0001 upward. `payment_expectation_evidence` records what showed payment was known to be required (a priced menu, a confirmed order, a running tab). `dishonesty_facts_observed` and `intent_facts_observed` are each a plain description of what was seen or heard, never a legal conclusion. `legally_enforceable_flag` is `yes` if there is any reason the service itself might not have been legally chargeable, `no` otherwise, with the reason recorded in `gaps.md` if `yes`.
2. `elements-check.csv` with columns: `incident_id`, `payment_expectation_recorded`, `dishonesty_facts_recorded`, `intent_facts_recorded`, `verdict`. Each of the three "recorded" columns is `yes` or `no`. `verdict` is `complete record` or `incomplete: missing [element]`, naming whichever of the three is missing.
3. `evidence-index.csv` with columns: `incident_id`, `evidence_type`, `reference_or_location`, `retained_until`. `evidence_type` is exactly one of `cctv`, `till_record`, `card_reader_log`, `witness_statement`, `written_note`. `retained_until` is left blank for the owner to set, never guessed.
4. `gaps.md` - a numbered list of: any incident with an `incomplete` verdict in `elements-check.csv`; any incident with `legally_enforceable_flag` as `yes`; any incident missing an amount; any incident with no evidence reference at all; and any log entry that appears to have been edited rather than added as a new line (flag any out-of-sequence `incident_id` or altered prior row).
## Rules
- Codex records, cross-checks the three elements, and indexes evidence. It never concludes an offence occurred, never recommends calling police, never contacts the named guest, and never estimates an amount not shown in a record.
- The "facts observed" fields are always observations, never conclusions ("they stole from us" becomes a request for the observed facts instead).
- Entries are appended, never edited or deleted; a correction is a new, timestamped line referencing the original `incident_id`.
- Never record a legal conclusion anywhere. `verdict` describes completeness, not guilt.
- British English, GBP, DD Month YYYY dates. No em dashes.
- Every file ends: this is a working incident record for the owner to decide what to do with, and for police or a solicitor to review if a report is made; not a finding that any offence occurred.
## Return
The absolute path and row count of each file. The number of incidents and total amount unpaid. The number `complete` versus `incomplete`, naming the missing element. The number flagged `legally_enforceable_flag` `yes`. Incidents with no evidence reference. The `gaps.md` item count.
Built from the best public work on this
Sources for walkout-and-dispute-log
1. Theft Act 1978, section 3 (Making off without payment)
https://www.legislation.gov.uk/ukpga/1978/31/section/3, Act of Parliament, as amended, read 4 November 2026.
Section 3(1) in full: "Subject to subsection (3) below, a person who, knowing that payment on the spot for any goods supplied or service done is required or expected from him, dishonestly makes off without having paid as required or expected and with intent to avoid payment of the amount due shall be guilty of an offence." This single sentence is the entire basis for the skill; its three elements (knowledge of the expectation, dishonesty, intent to avoid payment) are the three fields the log is built around in step 1 and the `elements-check.csv` in CODEX.md.
Section 3(2): "For purposes of this section 'payment on the spot' includes payment at the time of collecting goods on which work has been done or in respect of which service has been provided." This is quoted behind step 2, and it is why the log covers a collected takeaway as much as a dine-in walkout.
Section 3(3): "Subsection (1) above shall not apply where the supply of the goods or the doing of the service is contrary to law, or where the service done is such that payment is not legally enforceable." This is the exception behind step 4 and the `legally_enforceable_flag` column; it is a narrow carve-out, but a real one, and the skill records the possibility rather than assuming every unpaid bill fits the offence.
A former subsection 3(4) was repealed with effect from 1 January 2006 by the Serious Organised Crime and Police Act 2005, as shown on the same legislation.gov.uk page; the skill uses only the current, in-force text of subsections (1) to (3).
Where the skill departs: the Act does not say how a report should be made to the police, what evidence a prosecution needs beyond the three elements, or what happens next; those are matters for the police and, where relevant, a solicitor, which is why the skill produces a record rather than a report.
Best public prompt we found for this job
The closest public artefact is the `runbook` skill in Anthropic's `knowledge-work-plugins` repository, raw source at https://raw.githubusercontent.com/anthropics/knowledge-work-plugins/main/operations/skills/runbook/SKILL.md. The repository has 34,654 stars, read from api.github.com on 4 November 2026. It is a general operational-procedure skill, described as turning "tribal knowledge into exact step-by-step commands," and the closest public match for the discipline of writing a repeatable incident record with a fixed structure, rather than a free-text note.
Its output format fixes an "Expected result" and an "If it fails" field for every step, forcing the same information to be captured the same way every time. We took that same discipline of fixed fields over free text: the log here always captures the same three legal elements in the same order, rather than whatever the person on shift happens to remember to mention.
We did not copy its "Prerequisites," "Owner," or "Last Run" framing, because those describe a recurring internal task someone performs on a schedule, not an incident that happens to the business from the outside. The bigger gap is that a generic runbook has no concept of a statutory offence with named elements; it would happily record "guest left without paying" as a single free-text line and call the record complete. Building the three elements of section 3(1) into the structure itself, so a record is marked incomplete until all three are captured, is the part no general-purpose operations prompt is written to know it needs.
Want this running in your business?
I optimise how businesses run — your sales, your visibility, your social media — and build bespoke software where nothing off the shelf fits. The first conversation is free. Work starts from £150 a day.
Foxera