FoxeraThe guest standing in front of you right now: 10 AI skills for service recovery
guest-data-request
catches the complaint that's actually a data request before its clock runs out
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: guest-data-request description: Spots the complaint that is actually a data subject access request, "what do you have on me," "send me the CCTV," "delete my booking details", and puts it on the exact statutory clock UK GDPR now runs, including the clock rule that changed on 5 February 2026, rather than letting it sit in the ordinary complaints pile until it is already overdue. Use the moment any message contains a request for personal data, a copy, or deletion. --- # The complaint that's actually a data request, caught on the clock it runs on A guest asking what data you hold is exercising a right with a deadline starting the moment the request arrives. This states the deadline correctly under the rule that changed in February 2026. ## What it does 1. **Recognises the right.** Article 15(1) of the UK GDPR gives a right to "confirmation as to whether or not personal data concerning him or her are being processed" and, where so, access to it. A booking record, CCTV showing the guest, and complaint notes are all personal data. 2. **Starts the clock on the rule in force now.** Article 12A, inserted with effect from 5 February 2026, defines the "applicable time period" as one month from the latest of the request's receipt, any identity information received, or any fee paid. Extension is "by two further months" for complexity or number, but notice must be given "before the one-month period ends." This replaces the simpler rule many older guides still describe. 3. **Limits the search to what Article 15 requires.** Article 15(1A): the data subject is entitled only to what "the controller is able to provide" following "a reasonable and proportionate search" of named systems, not an unfounded promise to search everything ever used. 4. **Applies the fee and refusal rule exactly.** Article 12(5): where a request is "manifestly unfounded or excessive," the controller may charge a fee or refuse, but "shall bear the burden of demonstrating" that character; never a default response. 5. **Produces the copy the Article requires.** Article 15(3): "a copy of the personal data." Article 15(4): this "shall not adversely affect the rights and freedoms of others," so CCTV showing other guests is handled with that limit in mind. ## Then it checks 1. Every data-request message is flagged immediately, regardless of anything else said. 2. The deadline is calculated from the "relevant time" under Article 12A, not an outdated one-month-from-receipt assumption. 3. The search described is reasonable and proportionate against named systems. 4. Any refusal or fee is justified against the specific test, with reasoning recorded. 5. Any output involving a third party notes the Article 15(4) limit first. 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 calculate a deadline against an outdated rule; it changed on 5 February 2026. - Never apply the "manifestly unfounded or excessive" exception as a default. - A working assessment and deadline tracker for the owner to act on, and for a data protection adviser to check in any disputed request; not legal advice. ## Built from - UK GDPR, Article 15, https://www.legislation.gov.uk/eur/2016/679/article/15, read 4 Nov 2026: steps 1, 3, 5. - UK GDPR, Article 12A, https://www.legislation.gov.uk/eur/2016/679/article/12A, inserted 5 Feb 2026 (Data (Use and Access) Act 2025, SI 2026/82), read 4 Nov 2026: step 2. - UK GDPR, Article 12(5), https://www.legislation.gov.uk/eur/2016/679/article/12, read 4 Nov 2026: step 4. - ICO, "Right of access", https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/, read via search 4 Nov 2026 (site blocked direct access).
Prompt for Codex
# guest-data-request ## You are given A message flagged as a data access request: date and time received, the exact wording, whether identity verification or a permitted fee was requested and when received or paid. The systems Claude has described as reasonably and proportionately searchable (booking system, loyalty scheme, CCTV, complaint notes). Claude's decision on any extension or refusal, and why. ## Produce Write into a `./guest-data-request-output/` folder: 1. `requests.csv` with columns: `request_id`, `received_date`, `request_text_verbatim`, `identity_info_received_date`, `fee_paid_date`, `relevant_time_date`, `deadline_date`, `extension_applied`, `extension_notice_date`, `extension_reason_verbatim`, `refused_or_fee_charged`, `refusal_fee_reason_verbatim`. `relevant_time_date` is the latest of `received_date`, `identity_info_received_date`, and `fee_paid_date`, calculated, never estimated. `deadline_date` is `relevant_time_date` plus one calendar month, plus two further months only if `extension_applied` is `yes`. `extension_applied` and `refused_or_fee_charged` are `yes` or `no`. 2. `extension-timing-check.csv` with columns: `request_id`, `one_month_deadline`, `extension_notice_date`, `notice_given_before_deadline`, `verdict`. `notice_given_before_deadline` is `yes` or `no`. `verdict` is `pass` or `fail: extension notice late or missing`. Every row with `extension_applied` as `yes` in `requests.csv` appears here. 3. `search-scope.csv` with columns: `request_id`, `system_searched`, `reasonable_and_proportionate`, `search_completed_date`, `result_summary`. One row per named system searched for this request. `reasonable_and_proportionate` is `yes` or `no`, matching what was supplied, never decided here. 4. `third-party-redaction-check.csv` with columns: `request_id`, `material_type`, `third_parties_identifiable`, `redaction_applied`. `material_type` is exactly one of `cctv`, `written_note`, `booking_record`, `other`. `third_parties_identifiable` and `redaction_applied` are `yes` or `no`. Any `yes`/`no` combination is flagged in `gaps.md`. 5. `gaps.md` - a numbered list of: any request with no `deadline_date` calculated; any `extension-timing-check.csv` row with a `fail` verdict; any request past its `deadline_date` with no response recorded; any `third-party-redaction-check.csv` row where `third_parties_identifiable` is `yes` and `redaction_applied` is `no`; and any refusal or fee with no reason recorded. ## Rules - Codex calculates dates, checks timing, and indexes search scope. It never decides whether a request is manifestly unfounded or excessive, never decides what counts as reasonable and proportionate, and never drafts the response. - `relevant_time_date` and `deadline_date` are always calculated from supplied dates, never estimated. - An extension is only valid if its notice predates the one-month deadline; a late or missing notice is always flagged `fail`. - Never describe CCTV or notes identifying a third party as ready to hand over without a recorded redaction step. - British English, GBP, DD Month YYYY dates. No em dashes. - Every file ends: this is a working deadline tracker and search record for the owner to act on, and for a data protection adviser to check in any disputed request; not legal advice. ## Return The absolute path and row count of each file. The deadline date for every request and its status (within, approaching, or past). Extensions applied and whether each passed the timing check. Systems searched per request. Third-party redaction flags unresolved. The `gaps.md` item count.
Built from the best public work on this
Sources for guest-data-request
Everything below was read direct from legislation.gov.uk on 4 November 2026, except source 4 which is noted separately.
1. UK GDPR, Article 15 (Right of access by the data subject)
https://www.legislation.gov.uk/eur/2016/679/article/15, retained EU law forming part of UK law, read 4 November 2026.
Article 15(1) gives the data subject the right to obtain "confirmation as to whether or not personal data concerning him or her are being processed" and, where so, access to it, including "the purposes of the processing," "the categories of personal data concerned," and "the recipients, or categories of recipient" of the data. Article 15(1A): the data subject is "only entitled to such confirmation, personal data and other information as the controller is able to provide" following "a reasonable and proportionate search." Article 15(3): "The controller shall provide a copy of the personal data undergoing processing," with a reasonable fee allowed for further copies. Article 15(4): the right to a copy "shall not adversely affect the rights and freedoms of others." These subsections are steps 1, 3 and 5 of the skill.
Where the skill departs: Article 15(2), on safeguards for data transferred to a third country, is not built into the skill, since a hospitality venue's guest data is not typically transferred internationally in a way that changes how a request is answered.
2. UK GDPR, Article 12A (Meaning of "applicable time period")
https://www.legislation.gov.uk/eur/2016/679/article/12A, inserted with effect from 5 February 2026 by the Data (Use and Access) Act 2025, section 76, under SI 2026/82, regulation 2(h), read 4 November 2026.
The article defines the applicable time period as "the period of one month beginning with the relevant time," where the relevant time is the latest of: the date the controller receives the request, the date it receives any identity information requested under Article 12(6), or the date any Article 12(5) fee is paid. It allows the controller to extend the period "by two further months" where necessary because of "the complexity of the data subject's requests" or "their number," provided the controller "give[s] notice of the extension before the one-month period ends" and "state[s] the reasons for the delay." This is the exact text behind step 2 and the `relevant_time_date`, `deadline_date` and `extension-timing-check.csv` fields in CODEX.md. The legislation.gov.uk page itself carries the Textual Amendments note confirming the 5 February 2026 insertion date, which matters because this provision has been in force for only a matter of months as at the date this skill was written, and many older guides online still describe the simpler pre-2026 rule.
Where the skill departs: nothing. This is the current operative text and is quoted closely because getting the date wrong by relying on an outdated summary is the exact failure this skill exists to prevent.
3. UK GDPR, Article 12(5)
https://www.legislation.gov.uk/eur/2016/679/article/12, retained EU law forming part of UK law, read 4 November 2026.
Article 12(5): generally, information and the exercise of rights under Articles 15 to 22 are provided free of charge, but "where requests from a data subject are manifestly unfounded or excessive," the controller "may either (a) charge a reasonable fee..., or (b) refuse to act on the request," and "the controller shall bear the burden of demonstrating the manifestly unfounded or excessive character of the request." This is quoted behind step 4; the burden sitting with the controller is why the skill requires a recorded reason rather than a default refusal.
Where the skill departs: nothing beyond the point already made in the skill that this is a narrow exception, not a general discretion.
4. Information Commissioner's Office, "Right of access" guidance
https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/individual-rights/right-of-access/, read via search results on 4 November 2026; direct fetch of the page was attempted twice during this research and both attempts returned HTTP 403, consistent with the site's own bot-detection challenge rather than content unavailability.
Secondary commentary drawn from search results quoting the page describes the ICO's practice of counting the day of receipt as day one, its "stop the clock" allowance while awaiting a requester's clarification, and its description of "manifestly unfounded or excessive" as meaning "clearly or obviously unreasonable." These are consistent with, and were cross-checked against, the primary Article 12 and 12A text in sources 2 and 3 above, which this skill relies on as the authoritative wording.
Where the skill departs: because this page could not be fetched and read directly, nothing from it is quoted as if independently verified beyond what the primary legislation in sources 2 and 3 already establishes; the owner should re-read the ICO's current page directly before training staff from it, since ICO guidance is updated more often than the underlying Article.
Best public prompt we found for this job
The closest public artefact is `veale/access-request-template` on GitHub, at https://github.com/veale/access-request-template. The repository has 56 stars, read from api.github.com on 4 November 2026. Its own README describes it as containing "template letters for advanced, superpowered data protection (GDPR) access requests," made by Michael Veale, and it is the closest public match because it is built for exactly this right, not a generic customer-service or legal template repurposed for it.
It is written from the requester's side, as a letter a data subject sends to a controller, which is useful for understanding exactly what a thorough request can ask for, including specific systems and retention periods, which is the standard this skill's search-scope check is built against.
We did not copy its letter as a response template, because it is written to extract the maximum from a controller, not to help a small hospitality venue respond lawfully and proportionately. What we took instead was the reminder that a serious request can specify systems by name, which is why `search-scope.csv` records each system searched individually rather than letting a venue claim one undifferentiated search was done. What we deliberately left out entirely is any UK deadline calculation, because the template predates the Article 12A changes that came into force on 5 February 2026, and a 2026-current venue following an older template's assumed one-month-from-receipt rule, with no relevant-time or stop-the-clock logic, would now calculate the wrong deadline.
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.