Every course lesson embeds its own build kit where you need it. This page collects the whole library in one place. Use it when you come back later and only want the prompt. Two of the thirteen kits are security kits. Those live only inside the paid courses.
What this is. Every course explains how the Betty system works. This library is the other half. For each working part Betty runs, you get a kit with three things: (1) what the real thing is; (2) how it works in plain English, including what any helper script does, step by step; (3) a copy-paste prompt. The prompt gets your agent tool to build YOUR version, shaped to your business.
How to use any kit (read once)
- You never write code. Betty's skills are written instructions in plain files. A few jobs use a small helper routine - a script. Your agent tool writes that script FOR you, explains it, and gives you a safe way to test it. Your job is to know what the script should do, not how to type it.
- Use your installed agent tool (Claude Code, Codex, or the tool you picked - see the Agent Setup guide). Paste the prompt. Answer its questions honestly. Save what it produces into the folders your governance layer names.
- Every prompt ends with the same guard: "Never invent facts I did not give you." Keep that line. That line stops the AI from filling your rules with fiction.
- Safety rails are built in. Every kit that touches email holds to flag-don't-send. Every kit that touches files holds to never-delete (it moves files to a review folder instead). Every script comes with a practice mode (a "dry run"). Practice mode shows what the script would do before it does it.
- After you build one: log it. Add one line to your tools-log: date, what you built, why, outcome. A change is not done until it is recorded.
Which kit feeds which lesson
| Kit | Betty's real artifact | Lessons that embed it |
|---|---|---|
| 1. Governance starter | the .management/ layer + two authority docs | Foundation M2 (and the free PDF, Part 2) |
| 2. Skill file | 38 governed skills, farmed from logs | Foundation M4 · Tripwire L5 · Hermes M2 |
| 3. Watcher (lean poller) | betty-lean-poller, 5-min job | Tripwire L3 · Foundation M5 · Email M2 |
| 4. Email authority block | the live email skill's opening block | Tripwire L4 · Email M3 · Foundation M6 · Governance M4 |
| 5. Morning digest | morning-digest 06:00 job (BOS reports) | Foundation M7 (and the free PDF, Part 5) |
| 6. Timer list | cron/jobs.json - the 26-job fleet | Hermes M3 (light version in Foundation M5) |
| 7. Scanner & responder | the security classification layer | Foundation M6 · Governance M4 |
| 8. Scaffold script | tender/project stamp routines | Tender M2 · Construction M2 (activation variant) |
| 9. Monitoring scan | orchestrator governance scan, 15-min | Governance M3 |
| 10. Wrapper file | 16 wrappers → shared-core library | Hermes M4 (and the free PDF, Part 4) |
| 11. Register + summary | RFQ/VO registers, machine-readable pricing note | Tender M3/M4 · Construction M4 |
| 12. Routing rules | document filing, intake → governed home | Email M4 · Construction M3 (WHS variant) · Construction M5 (handover variant) |
| 13. Sorting scheme | classify-by-meaning categories | Tripwire L2 · Email M1 |
Kit 1 · The governance starter (the rules layer)
What Betty runs. One hidden .management/ folder that holds the rules: a register of official homes (SSOT_Register.md), the do-not-touch list (Governance_Lock.md), standards, workflows, and the tools-log. It was built BEFORE the agent was switched on.
How it works. Nothing in it is code. It is a set of short plain-text files the agent must read first. The register ends "which version is right" questions. The lock ends "the AI changed my files" incidents. The log is the memory.
📋 The prompt - the ten-question interview. It is identical to the one in the free Blueprint PDF, Part 2. Run it once. Save the files it produces. If you have the PDF version, you already have this kit. The courses build on the same files.
✅ Check it worked. A stranger could name the official home for any subject. The lock names an owner and a review date. The log has its first entry (building the layer counts).
Kit 2 · The skill file (one repeatable job, written down)
What Betty runs. 38 skills. Each skill is one file that packages one repeatable job. The file states: when the job triggers, what it may read and write, the steps, what done looks like, and the lessons learned. None were designed up front. They were farmed: log what the system does, review the patterns, and turn the patterns into skills. When the system makes a mistake, the fix becomes a line in the skill.
How it works. The agent matches incoming work against its skills. It follows the file instead of improvising. The order inside the file matters: the authority rules sit ABOVE the steps. The agent cannot reach the how-to without passing the may-not. The Lessons section at the bottom is append-only. That section is where the skill improves.
📋 The prompt - farm your first skill from a real week:
I run a [trade] business called [name]. I want to turn one recurring job into a
written skill file for an AI agent - a method it follows the same way every time.
The job: [describe it roughly - e.g. "every morning I check three inboxes for
anything about live tenders and forward what matters to my estimator"].
Interview me, ONE question at a time:
1. What starts this job (a time? an email arriving? me asking)?
2. What does it need to read, and where does that live (folders, mailboxes)?
3. What are the actual steps, in order, as I do them today?
4. Where does the output go, exactly?
5. What must NEVER happen while doing this job?
6. How would I tell, at a glance, that it was done right?
Then write me ONE markdown file called SKILL.md with sections in this exact
order: Purpose (2 sentences) · Triggers · Authority (May read / May write /
Must never - my answer to 5 goes here word for word) · Steps (numbered) ·
Done looks like · Lessons (empty, append-only, dated entries).
Write it in my words, at the detail level I gave you.
Never invent facts I did not give you.
✅ Check it worked. Hand the file to someone who has never done the job. That person could do a passable version from the file alone. The Must-never lines are yours, word for word. Within two weeks the Lessons section has at least one dated entry. A skill with an empty Lessons section after a month is either perfect or unused.
Kit 3 · The watcher (Betty's lean poller)
What Betty runs. betty-lean-poller - every 5 minutes, 8am–4pm weekdays. More than 90% of its checks find nothing and stop at about 700 tokens (~$0.0003). It is the lowest-cost job in the company.
How it works - the three moving parts (this is "the code," in plain English):
- The cheap look. It asks the mailbox for a summary only: sender, subject, first line. No attachments, no full bodies. That is why the quiet check costs a fraction of a cent.
- The short-circuit. It searches those summaries for its trigger (Betty's trigger is "@Betty"). Then it checks a small memory file - a register of message IDs it has already handled. The register makes sure no message is processed twice. Nothing new? It says [SILENT] and stops. No log entry, no noise.
- The step-up. Only on a real hit does it read the full email. It does the real work by the rules (Kit 4 decides what it may send). Then it writes the outcome into the register, so step 2 can skip that message next time.
The register is the part people skip and regret. Without it, "have I already handled this?" becomes another expensive question. The skill file also carries a written warning list: jobs that must NOT be added to the watcher (quote processing, governance checks, tender logic). Each of those jobs has its own slower schedule. Extra scope is what makes cheap jobs expensive. So the file states its own boundaries.
📋 The prompt - build your watcher:
Build me a "watcher" skill for an AI agent, using the check / short-circuit /
step-up pattern.
My facts:
- Watch: [mailbox or folder, e.g. my inbox [email protected]]
- Trigger: [what counts as "work for the agent" - e.g. emails mentioning @Helper,
or anything from these senders: ...]
- Check every: [e.g. 5 minutes], between [8am] and [4pm], weekdays.
- When there IS work, the full job is: [read the full email, then ... ].
- It must never: [reply externally / delete anything / act twice on one message].
Produce, as separate saveable files:
1. WATCHER-SKILL.md - the skill file (use the section order: Purpose, Triggers,
Authority, Steps, Done looks like, Lessons). Steps must be exactly three
phases: cheap summary-only look; short-circuit against a handled-items
register (a small JSON file keyed by message ID - create its empty starter
file too); step up to the full job only on a real hit. On no work, output
[SILENT] and write nothing.
2. A "Do not add to this watcher" warning list inside the skill: name the heavier
jobs I might be tempted to bolt on, and where each should live instead.
3. A one-paragraph plain-English explanation of the register file: what is in it,
why the watcher reads it before acting, what happens if it is deleted.
Include a practice mode: for the first week, instead of doing the full job, it
only writes what it WOULD have done to a review file I read each evening.
Never invent facts I did not give you.
✅ Check it worked. In practice week, the review file catches real work and no repeats. The quiet checks show [SILENT] and nothing else. You can name what one quiet check costs. After week one, switch the practice line off. That switch is the whole go-live.
Kit 4 · The email authority block (who it may answer)
(due to the nature of the internet these days giving out security info is locked behind in the full course)
This kit lives, in full, inside the paid lessons: Your First AI Skill Lesson 4, Email & Document Automation Module 3, Foundation Module 6, and Governance & Compliance Module 4.
Kit 5 · The morning digest (the report you read with coffee)
What Betty runs. morning-digest, 06:00 weekdays. It is one report with a tracking number (BOS-2026-005 style). It holds: the tender/job table with a next action on every row, inbox counts, what the intake pass skipped, and mentions waiting. Monday's edition adds a weekly audit section.
How it works. The digest is a skill that READS what the system already maintains: status files, registers, the intake log. It does not go hunting. That is why it is cheap, and why it is honest. "0 new, 18 already-processed items skipped" means the pipeline ran and found nothing. That is different from the pipeline not running.
Every row must carry a next action with a person's name on it. The report also states what it ignored. So you can audit the filter itself. Report IDs exist because "which report was that in?" is a real question three weeks later.
📋 The prompt - build your digest:
Build me a "morning digest" skill for an AI agent. Delivered [06:00] weekdays
to [my email].
It reads ONLY these places (no hunting): [your status folder / job register /
intake log / inboxes by name].
The report, in order:
1. A tracking ID: [YOURINITIALS]-[year]-[running number].
2. A table of live [tenders/jobs]: name, due date, stage, and a NEXT ACTION
with a person's name on every row. No row without a next action.
3. Inbox counts per mailbox: new since yesterday, what needs me.
4. What the overnight/intake pass skipped and why (one line).
5. Anything waiting on my say-so, oldest first.
Rules: read-only - this skill changes nothing and sends nothing except the
digest to me. If a source is missing or stale, say so in the report rather
than guessing. Keep it scannable in under a minute.
Write the SKILL.md (Purpose / Triggers / Authority / Steps / Done looks like /
Lessons) plus one sample digest filled with placeholder rows so I can see the
shape. Never invent facts I did not give you.
✅ Check it worked. Monday's digest tells you something you would otherwise learn at 10am. You can scan it in under a minute. When a source was empty, the digest said so.
Kit 6 · The timer list (jobs on a schedule)
What Betty runs. 26 scheduled jobs in one file (cron/jobs.json). Read the file as a design. One job talks to a waiting human every 5 minutes. A small group watches for urgent items every 10–15 minutes. Routine material moves every 30 minutes.
Reports arrive at fixed human times (06:00, 17:00). The system maintains itself weekly. About 12% of the fleet exists only to watch the fleet: is the timer system still running? Did the PC restart? Retired jobs stay in the file, marked "disabled" - visible history.
How it works. Each entry has three parts: a name, a schedule, and the skill to run with its instruction. The schedule is written in a compact five-slot code (cron notation). Example: /5 8-16 * 1-5 means every 5 minutes, 8am to 4pm, Monday to Friday. You read this code far more often than you write it. Your agent tool writes it for you. The design rule that matters: nothing runs faster than its business reason.
📋 The prompt - design your timer list:
Design the scheduled-job list for my AI agent. My working hours: [days, hours,
timezone].
The jobs I think I need (challenge me if the pace doesn't match the urgency):
- [e.g. watcher on my inbox - needs to feel same-hour responsive]
- [e.g. morning summary - once, before I start]
- [e.g. new-work folder check - a few times a day is plenty]
- [e.g. end-of-day summary]
For each job give me: a short name, how often it should run and in what window
(with a one-sentence business justification - if I asked for a pace the urgency
doesn't justify, say so and propose slower), the schedule in cron notation with
a plain-English translation beside it, and which skill file it runs.
Add the two jobs I forgot: a self-check that tells me if the timer system
itself stops running, and a weekly housekeeping job that archives last week's
reports. Output as a table I can keep in my governance folder, plus the same
list in the JSON format my agent tool expects ([name your tool if you know it]).
Never invent facts I did not give you.
✅ Check it worked. Every row's pace has a one-sentence business reason you agree with. The self-check job exists. Nothing runs every 5 minutes except a job a human is actively waiting on.
Kit 7 · The scanner and responder (the security screen)
(due to the nature of the internet these days giving out security info is locked behind in the full course)
This kit lives, in full, inside the paid lessons: Foundation Module 6 and Governance & Compliance Module 4.
Kit 8 · The scaffold script (stamp the same folders every time)
What Betty runs. Scaffold routines that create a standard folder set the moment a tender is bid or a job is activated. Normal tenders get the full 26-folder standard. The high-volume type gets the lean 12-folder version (an audit found 14 of 26 folders were never used on that type).
How it works - what the script actually does (plain English):
- It asks (or is told) two things: the job's name or reference, and its type.
- It looks up the folder list for that type. The list lives in a plain template file in your governance layer, NOT inside the script. So a scaffold change never means a code change.
- It creates the folders. It puts a starter file into the ones that need one (a status note, the task checklist, an empty register). It refuses to run if the destination already exists. It never overwrites and never deletes.
- It prints what it made, and appends one line to your tools-log.
That is all a "script" is here: a saved routine. It does in two seconds what you would do by hand in ten minutes, identically, every time.
📋 The prompt - have your AI write it:
Write me a scaffold script that stamps my standard folder structure for a new
[tender/job].
My structure (folder names, one per line, sub-folders indented):
[paste your scaffold design]
Types: [e.g. "standard" gets everything; "minor works" gets this shorter list: ...]
Starter files: [e.g. status.md with today's date; Tasks/checklist.md from my
template at <path>; an empty quotes register]
Requirements, non-negotiable:
- The folder lists live in a separate plain template file the script reads, so
I can change my scaffold without touching the script.
- It must refuse to run if the destination folder already exists. It must never
overwrite and never delete.
- A practice mode that prints what it WOULD create without creating anything.
- After running, it appends one line to my tools-log: date, job name, type.
- Write it for [Windows/my setup - say what you use], tell me exactly how to
run it, and then explain the script to me section by section in plain
English so I could describe what each part does to another person.
Never invent facts I did not give you.
✅ Check it worked. Practice mode prints exactly your design. A real run creates the structure in seconds. A second run on the same job refuses. You can explain to someone else, without notes, what each part of the script does. If you cannot, ask the AI to explain again until you can.
Kit 9 · The monitoring scan (drift, caught on purpose)
What Betty runs. The orchestrator governance scan. Every 15 minutes in business hours it reads the lock state, status, and tasks. It compares reality against the baseline - what SHOULD be true - and reports gaps. It reports the lock state first on every run ("Lock state: intact, GovLock v1.0").
It never fixes what it finds. It reports for a human. It flags anything unclear and never guesses. It reports [SILENT] when nothing material changed.
How it works. The baseline is a short written list of statements that should always be true. Examples: every job has a governance folder; every subject has one owner; nothing claims to be a second source of truth. The scan is cheap because it checks structure, not content. "No change confirmed" is real evidence. "We checked, and it is fine" beats "we think it is fine."
📋 The prompt - write your scan:
Write a monitoring-scan skill for my AI agent that catches drift - the gap
between how my system is supposed to be and how it actually is.
My baseline (statements that should ALWAYS be true - challenge me if any is
untestable): [write 5 to 8, e.g. "every live job folder contains a status.md
updated within 14 days", "no subject appears twice in the SSOT register", ...]
The skill must: run every [15 minutes / hour] in business hours; report the
lock state first, every run; check each baseline statement and list gaps in
plain terms; REPORT ONLY - never fix, never move, never rename anything it
finds; flag anything ambiguous (live or legacy?) as a question for me, never
resolve it by guessing; output [SILENT] when nothing material changed, and a
dated findings note to [folder] when something did.
Write the SKILL.md plus my baseline as a separate BASELINE.md the scan reads,
so I can add statements without editing the skill.
Never invent facts I did not give you.
✅ Check it worked. Break one baseline statement on purpose (rename a status file). The next scan names it, plainly, and touches nothing. Fix it; the scan confirms all clear.
Kit 10 · The wrapper file (one method, many tools)
What Betty runs. 16 wrapper files in the runtime's skill folder. Each one points at the governed shared-core library on the company drive. The method is written ONCE, in governance. Every AI tool finds the method through its own thin pointer. No tool owns a private copy.
How it works. A wrapper is half a page: "the real method for X lives at <path>; read it and follow it; do not restate it here." When the method changes, it changes in one place, and every tool follows. When you swap a tool out, the method survives. The business method outlives the AI tool.
📋 The prompt:
My AI tool is [name]. My governed method files live at [path to your
.management skills/workflows]. Write me a wrapper file in the format [tool]
expects, that: names the governed file it defers to; instructs the tool to
read and follow that file rather than restating it; carries NO method content
of its own beyond a one-line description; and includes a note to future
maintainers that edits belong in the governed file, not here. Then list the
wrappers I should create (one per governed skill I name: [list them]) as
files I can save in one go. Never invent facts I did not give you.
✅ Check it worked. Change one line in the governed method file. The tool's behaviour follows, and you never touch the wrapper. Delete a wrapper; the method is still intact in governance.
Kit 11 · The register and the machine-readable summary
What Betty runs. Registers at every point where money moves. The RFQ register holds every supplier quote, its status in the chain, and the exclusions captured with every quote. The variation register holds every VO, numbered and tracked to its outcome. The machine-readable pricing summary is a short structured note saved beside the workbook. It lets the agent reuse the final number without opening the spreadsheet.
How it works. A register is a plain table: one row per tracked item, plus a status column. The status values come from a fixed list (draft → issued → acknowledged → quoted → …). The discipline: the register is the ONLY place status lives. The answer to "did the steel supplier reply?" is a lookup, not a memory. The pricing summary is five lines the agent can read: price ex-GST, price incl-GST, margin, key exclusions, validity date.
📋 The prompt:
Build my [quotes/variations] register and the summary format that goes with it.
What I track: [e.g. supplier quotes per tender / variations per job].
My status stages, in order: [use yours, or ask me to confirm this default:
draft, issued, acknowledged, quoted, clarified, shortlisted, awarded or
not-awarded, closed].
Produce:
1. REGISTER.md - a table template: one row per item, columns for reference,
who, dates, status (from my fixed list only), exclusions/notes, and next
action. Plus the three rules underneath: every item gets a row the moment
it exists; status changes only through the listed stages; the register is
the only place status lives.
2. SUMMARY-FORMAT.md - the five-line machine-readable note saved beside any
priced workbook: price ex-GST, price incl-GST, margin, key exclusions,
valid until. With one filled example using round placeholder numbers.
3. The skill steps an agent follows to update the register when a [quote/VO
response] arrives - including: it may update rows, it may never delete one.
Never invent facts I did not give you.
✅ Check it worked. Ask "where are we with [any tracked item]?" Answer it from the register alone, without opening email. The agent's updates only ever move status forward through your list.
Kit 12 · Routing rules (every document to its one home)
What Betty runs. The filing discipline. Documents land in an intake folder - never a permanent home. The agent reads each document and sorts it by what it means. Then it moves the document to its one governed home, per the routing rules.
Examples: addenda go to the tender's Addenda & Clarifications; quotes go to the quotes folder plus a register row; manuals and warranties go to the project's equipment folders, where they later become the O&M manual. The original moves to a processed folder as the written record you can check later. Staff findability is a hard rule: file where humans already look.
How it works. The routing rules are a plain table: document type → its one home. Governance owns the table. The most important rule came from a real mistake: the specific business rule beats the AI's general habit, always. (Betty once nearly lost addenda to a generic "processed" folder.) The agent applies the table. When a document matches no row, the agent asks instead of guessing.
📋 The prompt:
Write my document routing rules and the filing skill that applies them.
My document types and where each one belongs (one line each - I'll start,
challenge gaps): [e.g. tender addendum → that tender's "Addenda &
Clarifications" folder; supplier quote → the tender's quotes folder + a
register row; equipment manual/warranty → the project's equipment folder; ...]
My intake folder: [path]. My processed archive: [path].
Produce:
1. ROUTING-RULES.md - the table, plus these rules verbatim: nothing lives
permanently in intake; the original always moves to processed after filing;
the specific rule in this table beats any general filing habit, always;
file where my staff already look.
2. FILING-SKILL.md - the steps: read the document fully (attachments are the
document), match it to a row, move it home, add any register row, archive
the original, log one line. If it matches no row: put it in a review folder
and ask me - never guess, never invent a new home.
3. A practice mode: for the first week it only writes "would file X to Y"
to a review list I check.
Never invent facts I did not give you.
✅ Check it worked. Practice week's review list has no wrong homes you would overrule. The one document type that always used to get lost now has a row, and cannot get lost. Intake is empty at each day's end. Processed is append-only.
Kit 13 · The sorting scheme (classify by meaning)
What Betty runs. The classification layer under all email work. The agent reads every message fully, attachments included. It sorts each message by what it MEANS to the business - never by sender, never by subject line. (The revised price often sits in an attachment under "FW: updated docs".)
How it works. Six to eight categories cover the real inbox. Each category has a decision attached: reply, act, or file-only. The mailbox is a hint, not a verdict. The content decides.
📋 The prompt:
Build my email sorting scheme. I run a [trade] business. Here are 15 to 20 real
subject lines from my inbox last week (redacted where needed): [paste them].
1. Propose 6 to 8 categories sorted by BUSINESS MEANING (not sender), covering
everything I pasted plus the obvious gaps. For each: name, one-line
definition, one of my real examples, and the action: reply, act, or
file-only.
2. Flag which of my examples would have been mis-sorted from the subject line
alone, and say what the attachment or body probably held.
3. Write the one rule at the top: read the full body and attachments before
deciding anything.
Output as CATEGORIES.md I can hand to my agent as-is.
Never invent facts I did not give you.
✅ Check it worked. Take yesterday's ten real emails. Each one lands in one category, with no argument. At least one is an email whose subject line alone would have misled you.