SKILL: Triage an inbox of incoming requests

A worked Skill from Innovation Day. Spec-first output (Way #1), a privacy rule that flags PII without echoing it (Way #3), and a human re-checking the priorities the AI got wrong (Way #2).

1. Goal - what this Skill does, and when to use it

Take a list of incoming requests (the kind that pile up in a shared mailbox or a ticket export) and turn them into a sorted triage table: priority, category, suggested next step, and a flag for anything a human must look at. Use it at the start of the day, or when a backlog has built up.

It replaces reading 12 tickets one by one and trying to hold “what’s actually urgent” in your head.

2. Inputs - what you paste in for it to work

• Input 1: the requests export (columns: id, received, from, request).

PRIVACY CHECK (Way #3): request text is full of personal data people typed without thinking. The Skill’s job is to flag it, not repeat it.

In the data	What the Skill must do
Mobile number 07700 900142 (REQ-003)	Do not echo it. Flag “contains phone number - redact.”
A person’s name (Priya Nair, REQ-003)	Don’t carry the name into the output; refer to “new joiner.”
Employee ID 48817 (REQ-009)	Do not echo it. Flag “contains employee ID - redact.”

The output is for a triage board other people see. PII must not be copied into it - that’s the postcard rule in action.

3. Output - what “good” looks like (write this BEFORE the prompt)

One row per request, sorted High → Low:

Priority test (state it in the prompt so it’s not a vibe): High = blocks people now / hard external deadline / health & comfort; Med = matters this week, no hard deadline; Low = “whenever convenient”, no impact if it waits.

4. Instructions / Prompt - the exact text to paste

You are helping me triage a list of incoming requests.

Output one row per request, sorted High priority first, with columns:
Priority + reason | Category | Suggested next step | Needs human review?

Priority rules:
- High = blocks people from working now, OR has a hard external/time deadline,
  OR is a health/comfort issue (e.g. no heating).
- Med = needs doing this week but has no hard deadline.
- Low = explicitly "no rush"/"whenever convenient" with no impact if delayed.
Judge by impact and deadline, NOT by whether the sender typed "URGENT".

Privacy rules:
- If a request contains a phone number, employee ID, or personal name,
  DO NOT copy it into the output. Replace it with a neutral reference
  (e.g. "new joiner") and set Needs human review = Yes with reason
  "contains PII - redact".

Set Needs human review = Yes for anything with PII, money, a hard deadline,
or a safety/comfort impact.

Requests:
[PASTE REQUESTS]

5. Worked Example - one real run

Input (a representative slice):

REQ-003 HR: New joiner starts Monday - needs laptop, accounts, desk. Name Priya Nair, mobile 07700 900142.
REQ-006 IT: Password reset for shared mailbox, whenever convenient.
REQ-007 Operations: Completely out of printer paper across the floor, big print run for the board pack tomorrow morning.
REQ-009 Finance: Payroll query from employee ID 48817 - thinks overtime wasn't paid. Needs looking at before next run.
REQ-011 Facilities: Heating off in the east wing for two days, people wearing coats at their desks.

Output it produced:

Priority + reason	Category	Suggested next step	Needs human review?
High - board pack print run tomorrow AM, floor is out of paper (hard deadline)	Operations	Source paper today; confirm board-pack print covered	No
High - heating off 2 days, staff comfort/welfare	Facilities	Raise with building services as priority; offer interim warm space	Yes - welfare
High - new joiner onboarding by Monday (hard date)	HR / IT	Provision laptop, accounts, desk before Monday	Yes - contains PII (phone number), redact
Med - payroll correction needed before next run	Finance	Investigate overtime calculation ahead of payroll	Yes - contains employee ID, redact; involves pay
Low - explicitly “whenever convenient”	IT	Queue shared-mailbox password reset	No

Note the output says “new joiner” and “employee ID, redact” - the phone number 07700 900142, the name Priya Nair, and the ID 48817 are nowhere in the table. Flagged, not echoed.

The catch (Way #2): AI triages on surface signals. It tends to mark a request that literally says “URGENT” as High, and to under-rate the two genuinely high ones here - REQ-007 (out of paper, board pack tomorrow) and REQ-011 (heating off two days) - because the language is calm. The prompt’s “judge by impact and deadline, not by whether they typed URGENT” rule fixes that, but verify it landed: the truly low ones (REQ-002, REQ-006, REQ-010 - all “no rush”) should be Low, and a calm-but-deadline-driven request should be High. Re-rank by hand if the AI got it wrong.

6. Guardrails - how to stay safe and sane

• Privacy (Way #3): the triage table must never contain a phone number, employee ID, or personal name. The Skill flags PII; it does not reproduce it. Spot-check the output for leaks before you share the board.
• Human check (Way #2): re-read the priorities. AI over-weights the word “urgent” and under-weights quietly-worded but high-impact requests (no heating, hard print deadline). You set the final order.
• Limits: this sorts and suggests - it doesn’t act, and it doesn’t know your internal SLAs or who’s on leave. It’s a fast first pass, not the rota.

7. Reuse notes - so it isn’t lost

• Owner: (your name)
• Last updated: (date)
• Lives in: Ops/Service-desk shared space → Skills. Tune the priority rules to your real SLAs once and everyone inherits the same definition of “High” - Way #5.

Built at Innovation Day. The five ways of working: ways-of-working.md.