Tessa's Runbook

Needs
- Read access to the school portal page and the school email inbox (a forwarding rule into one mailbox works if the portal has no feed).
- A family calendar the agent can write to.
- Ask your person which children, which year groups and what counts as urgent (default: due within 48 hours).

Build
1. Run twice a day, 6:30am and 3pm.
2. Fetch the portal news, homework and forms pages and the last day of school email. Compare with the stored snapshot from the previous run and keep only new items.
3. For each new item ask the model: "Is there a date, a deadline, a thing to bring or a form to sign? Return child, action, due date, or NONE."
4. Write each result as a calendar entry on the due date with a reminder the evening before. Mark the source in the entry.
5. Send a text only when the due date is within 48 hours. Otherwise stay silent.
6. Next morning, re-check forms marked due: if still open, send one text; never a second.

Check
- Post a test notice on the portal or forward a made-up school email: an entry appears within the next run.
- A day with no new items produces nothing.
- A notice with no date ("details to follow") becomes a calendar entry titled "date pending" on the next Monday and is rechecked daily until a date appears.

Needs
- An invoicing tool or sheet with due dates, sent date and an open-tracking flag.
- Gmail with draft access (no send permission).
- A payments feed or bank export to confirm receipt.
- Ask your person for terms, the tone of past chasers and a list of clients never to chase automatically.

Build
1. Run every weekday at 9am.
2. List invoices where today is 3 or more days past due and the open flag is true. Skip anyone on the never-chase list and anyone already drafted for.
3. Read the last 3 emails to that client for tone, and the person who normally pays.
4. Instruct the model: "Write 2 sentences, plain, first name, ask one question about where it is stuck, offer to resend. Never mention penalties."
5. Save as a Gmail draft on the original thread. Do not send.
6. At 9am next day, check the payments feed; if matched, label the thread paid and delete any unsent draft.

Check
- A made-up invoice opened and 3 days late produces a draft; one unopened produces none.
- A paid invoice has no draft left.

Needs
- Gmail read access to sent mail.
- A Notion database or sheet with columns promise, to whom, date made, due, status.
- Ask your person which phrases they use for promises ("I will send", "by Friday", "I will intro you").

Build
1. Every evening read the day's sent mail.
2. Ask the model to extract each commitment: who, what, any due date. Ignore thanks and pleasantries.
3. Write rows to the ledger with status open. If the promise names no date, set due to 7 days after it was made; order the Monday text by due date, then oldest first.
4. Also each evening, for every open row search later sent mail to that person for the promised item (an attachment of the right type or the intro). If found, set status closed with the link.
5. Every Monday 8am text the open rows, oldest first, maximum 6. If none, send nothing.
6. Rows open more than 60 days are marked stale and dropped from the text, kept in Notion.

Check
- Send yourself a made-up "I will send this Friday" email: a row appears next day.
- Send the item: the row closes.

Needs
- Calendar read access, grocery order history or receipts, a pantry list the person keeps current.
- A grocer account that allows building a basket without paying.
- Ask your person for allergies, dislikes, number of eaters and a weekly food budget.

Build
1. Sunday 4pm read next week's calendar and mark any evening with an event ending after 6pm as late.
2. Read the last 3 grocery orders and the pantry list for what is already in the house.
3. Instruct the model: "Plan 5 dinners. Late nights get meals under 15 minutes or a prepped one. Reuse ingredients across the week. Stay under the budget."
4. Write the plan to a Notion page.
5. Build the basket minus pantry items through the grocer's saved-list or basket page using browser steps, and leave it unsubmitted.
6. Text a link. Submit only when the person taps approve; delete the basket Monday 9am if untouched.
7. The following Sunday text: which of last week's dinners were cooked? Carry uncooked ones, and their ingredients, into the new plan.

Check
- The basket total is within the budget and no pantry staple is double bought.
- Late nights match the calendar; a week with 3 late nights has at least 3 meals marked under 15 minutes or prepped.

Needs
- Pharmacy text messages forwarded to one mailbox.
- A shared sheet with each medicine, dose per day, last pickup date and pack size.
- Ask your person who else to alert and how many days of margin they want (default 3). The sheet is kept current by one rule: whenever a pharmacy text says a new dose or medicine, the agent adds it and texts the person to confirm; a person also edits it by replying with the change.

Build
1. Each day at 5pm read new pharmacy messages and update the last pickup date when one says collected or ready.
2. Compute days remaining as pack size divided by doses per day, counted from last pickup.
3. If days remaining is 3 or fewer and no ready or collected message exists, send the text to the person only.
4. If still no pickup message 24 hours later, send the same text to the named second person.
5. Never contact the pharmacy; the person does that.

Check
- Backdate a made-up medicine in the sheet: the warning arrives that evening.
- A collected message silences it.

Needs
- Daily or half-hourly meter readings from the supplier or a smart meter app export, and a weather history source.
- Ask your person for the alert threshold (default 40%), the list of big appliances and who to text.

Build
1. Every day at 7am load yesterday's total and its half-hourly shape.
2. Build a baseline: median use on the 20 previous days with a mean temperature within 3 degrees of yesterday.
3. If yesterday exceeds the baseline by the threshold, find the hours where use sat flat or jumped.
4. Instruct the model: "Given this shape and this appliance list, name the 2 most likely causes in one sentence each."
5. Text the totals and causes. Send nothing on normal days.
6. If the next day is also over, text again with the kWh above baseline so far; stop after 3 days.

Check
- Replay a past day with a known fault: it fires.
- A week of normal days sends nothing.

Needs
- Read access to both calendars (shared family calendar or invitation), the school pickup time, a sheet holding the tally of covered pickups.
- Ask both people for the pickup time, travel buffer (default 30 minutes) and any days that are fixed.

Build
1. Sunday 6pm list next week's events for each person that overlap the window from pickup minus the buffer to pickup plus 15 minutes.
2. A day is a clash when both people have an overlap and no third carer is entered.
3. For each clash propose the person with fewer covered pickups in the last 8 weeks, unless they are travelling.
4. Text both people with reply words mine or yours.
5. Update the tally on reply, and add a calendar block for the person covering.
6. If no reply by Monday 7pm, text once more; never message the school.

Check
- A made-up double meeting produces a clash line.
- A week without clashes sends nothing.

Needs
- Read access to texts and email, a contacts list with birthdays.
- Ask your person for a budget band and people to leave out. Texts are read from a read-only copy of the phone message database on the person's computer, or from notification emails forwarded to the mailbox if that is not possible.

Build
1. Each night read new messages from the phone message export or the messages bridge the person already uses, from people with birthdays. Keep lines where they state a want, a dislike, a hobby or a problem with something they own. Store each line, date and person as a row in a Notion or sheet table called hints.
2. Every morning find birthdays exactly 14 days ahead.
3. Instruct the model: "Using only the stored lines for this person, suggest 3 gifts in the budget band, each with the line that supports it. If fewer than 2 lines exist, say so."
4. Text the ideas to the person. If no lines exist, send nothing.
5. Record bought or skip by reply and keep the history.

Check
- Each idea cites a real stored line.
- A person with no lines sends no text.

Needs
- Email and Slack read access for client threads, plus a client list.
- A Notion page to write to.
- Ask your person for the client list and which clients are most important.

Build
1. Friday 3pm, for each client compute the median hours between my message and their reply over the last 8 weeks, and over the last 2 weeks.
2. Mark a client red when the recent median is 2 times the 8 week median and there are at least 4 exchanges in the window.
3. For red clients quote their last message and the open question between you.
4. Instruct the model: "Suggest one low pressure next step in a single sentence."
5. Write to Notion; text only if a red client is on the important list. Nothing red means no note.

Check
- Replay a past quiet client: it shows red the week before they left.
- No red week produces no text.

Needs
- Calendar read access with client names in event titles or attendee domains, an invoicing tool or sheet of invoice lines with dates, a client rate sheet.
- Ask your person which meetings are non-billable (internal, networking) and the minimum block length to bill (default 30 minutes).

Build
1. Friday 4pm read calendar events from the last 4 weeks where an attendee domain or title matches a client.
2. Drop events marked non-billable, declined, or shorter than the minimum.
3. For each client sum event time per week and compare to invoice lines dated in the same weeks, allowing a 15 minute tolerance.
4. Collect blocks with no invoice line covering them.
5. Text the list, one line per client, with reply words add or skip.
6. On add, append a draft line (date, minutes, rate) to the next invoice. On skip, store the event id so it is never raised again.

Check
- Delete a line from a test invoice: the matching block appears in the next Friday text.
- A fully billed month sends nothing.

Needs
- Read access to brokerage positions and a sheet of target weights.
- The path Tessa runs: the text alone, and she places the trade herself in the broker app. A builder whose broker offers an order API may add order placement after an APPROVE reply.
- Ask your person for the drift threshold, tax lot rules and the funds that are off limits.

Build
1. Friday after close, compare each fund weight to its target.
2. Silent unless any fund differs by 5 points or more.
3. Agent one proposes the smallest set of trades that restores targets, preferring long term lots.
4. Agent two receives only the proposal and is told: "Find reasons this is a mistake: tax, timing, fees, concentration."
5. Text both arguments with the reply words APPROVE and REJECT (or buttons if the messaging app offers them).
6. Place nothing yourself: the person trades after reading the texts.

Check
- A made-up 6 point drift produces a proposal and a counterargument.
- A tap of Reject places no order.

Needs
- A folder of bills, Gmail draft access, web search.
- Ask your person for the providers and a minimum saving worth asking for (default 8 a month).

Build
1. Each quarter read the latest bill from every provider and extract plan, speed or cover, and monthly price.
2. Search public price pages for the closest equivalent from two competitors.
3. Keep providers where a competitor is cheaper by the minimum or more.
4. Draft a short retention request citing the competitor plan and price.
5. Save to Gmail. The person sends.
6. When a reply arrives, log the new rate.

Check
- Drafts cite a real competitor price.
- Providers with no cheaper option get no draft.

Needs
- Web access to official state unclaimed property search sites.
- A list of full names and past addresses.
- Ask your person for the states they lived in.

Build
1. Each quarter search each state site for each name and address.
2. Keep results where name and a past address match.
3. Score each hit: exact full name plus a past address on file is a match; a name variant (middle initial, maiden name, nickname) plus an address is a possible match; a name alone is dropped. If a state site needs a captcha, list it under "check by hand" in the note with its link. Draft the claim answers, never uploading identity documents.
4. Write to Notion with a link to each official claim page.
5. The person files; mark paid on receipt.

Check
- A known test match appears, and a state with a captcha shows under check by hand.
- No results produces a one line note.

Needs
- Meeting notes or sent mail to find decisions, a Notion page for the journal.
- Ask your person for what to count as a decision (a change to a process, price, hire, vendor or commitment).

Build
1. After each meeting note or sent email containing words like "we decided", "I will switch", "let us go with", extract the decision, why, and the expected result in one line.
2. Write it to the journal with a check date 30 days later.
3. Each morning find entries due today and text one question: did the expected result happen? Reply better, same or worse.
4. Save the reply.
5. On the first of the month post a note listing which kinds of decisions turned out worse than expected.

Check
- A made-up decision is logged and asked about on its date.
- Unanswered items are asked once more after 7 days, then closed.

Needs
- Access to the proposal document, a folder of past proposals with the questions clients asked.
- Ask your person to describe the usual sceptic (CFO, board, buyer). To start the log from nothing, seed it by reading the last 10 sent proposals and the replies to them and extracting every question the client asked; after that each new reply adds to it.

Build
1. Trigger when the document tool reports a save (a folder watch or change webhook) on a file in the proposals folder with "proposal" in the title, at most once per hour per file.
2. Load the 10 most recent past questions logged for similar clients, plus the monthly pattern note from the decision journal so decision types that went badly get harder questions.
3. Instruct the model: "Act as a sceptical finance lead. List the 3 questions most likely to stall this proposal, each with a one sentence suggested answer from the document."
4. Post as a comment on the draft.
5. When the client responds, log their actual questions and mark which were predicted.

Check
- Each question points at a real number in the draft.
- The hit rate is logged after each reply.

Needs
- Gmail read access, a folder with each client's signed scope, Gmail drafts.
- Ask your person for the client list, the rate card and the tolerance (default: small clarifications are free).

Build
1. On each new email from a client address, load that client's scope document.
2. Instruct the model: "List any new deliverable, extra location, extra stakeholder or deadline change requested in this email that the scope does not cover. Return NONE for clarifications and questions."
3. If NONE, stop with no output.
4. Otherwise estimate effort from past change orders and draft a short change-order note citing the scope clause and the rate.
5. Text the summary with the draft link. Never send to the client.
6. If the client has not answered 5 days after the draft is sent, draft a gentle nudge.

Check
- Send a made-up email asking for a second deliverable: a text and draft appear.
- A scheduling question produces nothing.

Needs
- Both contract versions as documents, Gmail, Notion.
- Ask your person which clause types matter (default: payment, liability, termination, renewal, exclusivity, IP).

Build
1. When an email arrives with a revised contract attachment and a prior version exists in the folder, load both.
2. Align clauses by heading and number.
3. Instruct the model: "For each clause in the listed types, return old text, new text and whether the meaning changed. Ignore punctuation and wording-only edits."
4. Write the note with meaning changes first.
5. Email it to the person and create the Notion page with accept and push back fields.
6. On push back, draft a reply quoting the old clause and asking to keep it.

Check
- Alter one liability number in a test copy: it is the first item.
- A typo-only redline reports no meaning changes.

Needs
- Gmail with trip confirmations, a flight status source, and Gmail draft access.
- Passenger names and booking references come from the confirmation emails; bank details are never stored, the person adds them when sending.

Build
1. Read confirmation emails and keep a list of flights with scheduled arrival and booking reference.
2. On travel days, every 30 minutes after scheduled arrival, check actual arrival.
3. Claim only when the delay is 3 hours or more and the flight departs from the EU or UK, or an EU or UK airline lands there.
4. Work out the amount: 250 euros up to 1,500 km, 400 euros up to 3,500 km, 600 euros beyond. Ask the model to write a firm two paragraph claim naming the regulation and distance band.
5. Save as a draft with the boarding pass attached. Text "Claim drafted" only after a draft exists.
6. Fourteen days later, if the thread has no reply, draft an escalation to the national enforcement body.

Check
- Replay a past delayed flight: a draft appears with the correct band.
- A 2 hour delay produces nothing.

Needs
- The policy PDF in a folder the agent can read, the denial letter by email, Gmail draft access.
- Ask your person for supporting records and the appeal address.

Build
1. Trigger on an email or scan containing words like "denied", "not covered" or "declined" from the insurer.
2. Extract the claim number, stated reason, clause cited and appeal deadline.
3. Search the policy for the clause cited and any clause that grants cover. Quote both exactly; if a quote cannot be found, leave it out.
4. Instruct the model: "Write a respectful appeal that argues from the policy text, in under 300 words, and list the documents to attach."
5. Save as a draft with the deadline in the subject. Never send.
6. When a refusal arrives, draft the next-level appeal using the same quotes plus the insurer's stated reason.

Check
- Every quoted clause appears word for word in the policy.
- The deadline matches the letter.

Needs
- Run logs for every routine, a repository holding the scripts, permission to open a pull request but not to merge.
- Ask your person for the expected daily output count of each routine.

Build
1. At 1am read the last 24 hours of logs and each routine output count.
2. Flag a routine if it errored twice, or if its output is zero on a day it normally produces something.
3. For each, read the error and the script and reproduce it with the saved input.
4. Instruct the model: "Propose the smallest change that fixes this and write a test that fails before the change and passes after."
5. Open a pull request with the diagnosis; text a one line summary.
6. Never merge. Record merged or rejected and why.

Check
- Break a script on purpose: a patch appears that passes its test.
- A healthy night sends no text.