In operations, a runbook is a written procedure you can hand to anyone — or run yourself next month without re-thinking it. Here are three I actually use, with the real prompts to paste at each step. Expand one and follow along.
Notice the thread running through all three: each one produces a machine-readable twin of your work — structured data you can re-run and refresh. That's the habit from Part 4, in practice.
Stand up your own personal site — get a domain, design it, build it, deploy it.
This site is yours — a personal home on the web for your portfolio, CV, conference talks, or anything you want to share. Start by getting the address people will type. In your Cloudflare dashboard (pricing in Tools I Use), register a new domain like yourname.com, or transfer one you already own. Doing it in Cloudflare now means the address and the hosting live in one place, ready for the deploy step later.
One real cost to know about. A Cloudflare account is free, and so is hosting your site — but a domain name is not. You'll pay the registration fee for the address itself, typically around $10 a year for a .com (Cloudflare charges at cost, with no markup). That annual fee is the only thing you have to pay for in this entire runbook.
Before you design a single page, decide how everything should look and sound. Ask Claude Design to help you build a small design system — your color palette, typography, and voice — that every page will then inherit. Decide your look once, deliberately, instead of re-deciding it on every page.
Two good ways to choose colors and fonts: do a little research in Perplexity first (pricing in Tools I Use) and bring your findings, or ask Claude Design to point you to trusted resources — like Coolors and Adobe Color for palettes, Google Fonts and Fontpair for type — and more besides.
Help me create a small design system for my personal website, before we design any pages. Keep it to three things: - Color palette: a primary, a secondary, an accent, and a few neutrals — with good contrast for accessibility. - Typography: a heading font and a body font that pair well, with a simple size scale. - Voice & tone: a few lines on how my copy should sound (for me: [warm and professional, approachable, clear]). For the colors and fonts: I may bring research I did in Perplexity. If I haven't, suggest a few reputable resources I can use to choose a palette and pair fonts, and we'll decide together. Save this as a design system I can reuse for every page.
Now build the actual page — in the same Claude Design workspace, so the system carries over as context. Describe the page in plain language and tell it to use the foundation you just built. Everything inherits your palette, type, and voice automatically, so it's consistent from the first draft.
Using the design system we just created, design a single web page for my personal site. It's my professional home page. Include: a warm hero with my name and a one-line introduction, an "about me" section, a section for my work (portfolio / CV / conference talks), and a way to get in touch. Apply the palette, typography, and voice from the design system. Build it as a Design Component I can keep iterating on, and use placeholder images where photos will go.
React to what you see. "Make the hero calmer." "Add a section for my conference talks." "My name should be more prominent." Keep going until it's right — this is the reference interview, applied to a web page.
Ask Claude Design to create a handoff bundle for Claude Code. Open Claude Code in that bundle's folder and ask it to turn the design into a deployable site and set up version control.
Take the HTML design in this folder and turn it into a static website I can deploy to Cloudflare Pages. - Keep the markup and styling as-is. - Wire up any navigation links between pages. - Put the finished site in a /dist folder. - Initialize a git repository and make a first commit. - Add a short README.md with the exact deploy command.
One command publishes it to the web. Claude Code can run this for you — or you can paste it into your terminal yourself.
npx wrangler pages deploy ./dist --project-name=my-personal-site
Expect a browser pop-up the first time. When Claude Code — or CoWork — runs this, it will pause and open a browser window asking you to log in to Cloudflare and approve. That's normal and a good thing: the agent never sees your password, so this is your moment to sign in and stay in control. Approve it, and the deploy continues on its own.
A deployed folder is great, but editing it means reopening the project and redeploying by hand. A content management system keeps your content separate so it's easy to change — and the right CMS lets you make those changes the same way you built the site: by asking your AI agent. Perfect for the quick updates a living site needs: a new talk, an updated CV, a fresh project.
My recommendation: EmDash, hosted on Cloudflare. I chose it for one reason — it was purpose-built to be fully AI-agent accessible. I set it up and make every change through Claude Code; I've honestly never opened its admin screen. There's no new dashboard to learn: you just tell your agent what to change, the same way you built the site. It's how this very site is published. (Pricing in Tools I Use.)
What you get: a real, public web page at your own address that you can edit any time. Next year's update is an edit, not a rebuild.
Give your agent its own inbox, subscribe it to the ALA JobLIST postings, and let CoWork turn each issue into a filterable, refreshable view.
The idea: give your agent its own inbox. Instead of pasting a newsletter in every month, route it to a dedicated email account and let CoWork read it for you. The data comes to the agent, on a schedule the publisher already runs — and you never copy-paste again.
Create a dedicated email account just for your AI — a new mailbox in your library's Google Workspace if you have one (your IT admin can add it), or a free Gmail account if you don't. Then subscribe to the newsletter with that address. For this example, set up ALA JobLIST email job alerts sent to it. From now on, every issue lands in one clean, single-purpose inbox.
CoWork can connect directly to that email account and read what's in it — no copy-paste. The important part comes when you connect it: you decide what the agent is allowed to do.
Grant read-only access — and nothing more. This job only needs permission to read the inbox. Withhold the ability to send email entirely. Your agent can look, but it can never write or speak on your behalf. Pair that with a single-purpose inbox and the worst case is simply: "it read a public newsletter." That's the whole point of giving the agent its own account.
A newsletter is written for humans. Before you can build anything, it has to become structured data. Point CoWork at the inbox and ask for clean JSON.
In the [your agent's inbox address] inbox, find the most recent ALA JobLIST job-postings email. Extract every job posting into a JSON array. For each posting include: title, institution, location (city, state), type (full-time / part-time), salary (the text as written, or null), posted_date, and url. If a field is missing, use null. Don't invent anything. Return only the JSON — no commentary.
Now that the data is structured, the view is easy. Have CoWork build it as an artifact — a live, self-contained dashboard you can see and use right there in CoWork, then download as a single file to open anywhere or email to a colleague.
Using the JSON of job postings, build a single-file HTML dashboard as an artifact I can view and interact with here in CoWork. - A sortable table of all postings. - Filters for state and job type. - A small summary bar: total postings and a count by state. - Keep the JSON embedded in the file so it works offline. Make it clean and readable — librarian audience, not developers.
Don't even run it yourself. CoWork has a built-in scheduled task feature — set one up once and the dashboard rebuilds on its own, say the first of every month. The inbox fills itself; now the refresh runs itself too.
Set up a scheduled task that runs on the 1st of every month: 1. Check the [your agent's inbox address] inbox for any new ALA JobLIST emails since the last run. 2. Extract them into the same JSON shape we've been using. 3. Merge with the existing data and remove duplicates (match on url). 4. Regenerate the dashboard and save it. If there are no new emails, do nothing.
What you get: the job market is just one example — this works for any newsletter you track. We all skim a whole issue hunting for the few things we actually need; the dashboard does that scanning and filtering for you, every time, fed by an inbox that fills itself and a scheduled task that runs itself.
Design the look once in Word; let the words flow in from a Markdown file, every quarter, automatically.
The idea: separate the look from the words. The hard part of a polished report isn't the writing — it's the formatting: the cover page, the heading styles, the table borders, the page numbers in the footer. So do that part once, by hand, in the tool built for it — Word. Then never touch it again.
From then on, each new report is just fresh content poured into that frozen design. The styling can never drift, because nobody re-formats anything.
Two words you'll see — in plain English
{{ phEmpty }}
Jinja placeholder. A labeled blank — a fill-in-the-blank you write right into the Word doc, like{{ phReportTitle }}. The automation finds each blank and drops in this report's value.
python-docx-template. A small, free tool that opens your styled Word file, fills in the blanks, and saves a finished .docx — keeping every style intact. You won't install or run it by hand; you'll ask CoWork to, and it handles the rest.
Start from a typical report — say a quarterly usage report. Put in everything you'll reuse: cover page, headings, body text, lists, tables, header and footer, page numbers. Use real sample content so you can judge it with your own eyes, and lean on Word's built-in Styles (Heading 1, Normal, a table style) rather than formatting each line by hand — that's what lets the look carry over automatically.
When it looks right, stop. Save a backup copy and treat this as the locked visual reference. Skim once to confirm the formatting is style-driven and consistent — headings, spacing, tables, header/footer all behaving — before you change a single word.
Save it as an ordinary .docx file — not a .dotx Word template. The automation tool reads a plain .docx, so keeping it in that format is what lets the Python step open and fill it cleanly.
Now go through the doc and replace just the parts that change each time with placeholders. You're editing text only — the placeholder sits in the same spot and inherits the same style, so the look is untouched.
{{ phReportTitle }}
{{ phPreparedBy }}
{{ phExecSummary }}
Keep one small Markdown file listing every blank and what goes in it. It's the single source of truth that keeps your Word template and your content file speaking the same language — and it's a textbook machine-readable twin (Part 4): the human-readable contract for a machine-readable job.
# Template fields — Quarterly Usage Report - report_title — Full report title (e.g. "Q2 2026 Usage Report") - quarter — Quarter, e.g. "Q2" - year — Four-digit year, e.g. "2026" - prepared_by — Name of the person or team - prepared_date — Date prepared, written out - executive_summary — 2–3 sentence overview of the quarter - key_findings — Bulleted list of the main takeaways - recommendations — Bulleted list of suggested next steps
Put three files in a folder — the styled Word template, this quarter's content as Markdown, and the field index — and point CoWork at them. Notice the guardrails: it stops and asks rather than inventing a missing value, and reports anything that doesn't line up.
Generate a Word report from my styled template using python-docx-template.
In this folder:
- the styled Word template with {{ phEmpty }} placeholders
- this quarter's content as a Markdown file
- template-fields.md — the authoritative list of fields
Please:
1. Fill only the placeholders listed in template-fields.md, pulling
values from the Markdown content.
2. Keep every Word style exactly as-is — don't hard-code any fonts,
sizes, colors, or spacing.
3. If a required field has no value, STOP and tell me which one —
don't guess.
4. Save a new .docx (don't modify the template), and give me a short
summary: which fields were filled, plus any unused content or
placeholder/index mismatches.
What you get: a board-ready Word file, perfectly styled, in seconds — the design frozen, the words fresh. The quarterly report is just one example: this fits any recurring document, and especially shines on the ones you dread. You could even adapt it to a newsletter whose content is gathered from emails — the same template, filled from a different source.