Zane Homsi

Ask first

• Which chat app? (default one with an official bot API)
• Who may talk to it? (default only your own account; everyone else is ignored)
• Which commands should show in its menu? (default status, brief, wrap up, compact)

Needs

• A computer that stays on, a coding assistant that can run there, and a chat bot account.
• A process supervisor that restarts the assistant if it crashes or the machine reboots.
• Say to the person: "Only your account can reach it, and it still asks before sending email, buying or trading."
• If your assistant can only chat: use its phone app; you lose scheduled alerts but keep the conversation.

Build

1. Create the bot and lock it to the person's account ID.
2. Run the assistant in a long-lived terminal session on the home computer, connected to the bot; have the supervisor start it at login and restart it on failure.
3. Add a command menu that maps short commands to the assistant's own commands. Never expose one that wipes its context.
4. Point every scheduled run's alerts at this chat, so the person has one place to look.
5. Keep the same approval rules as at the desk: drafts, trades and sends wait for a yes in the chat.

Check

• Message it from another account; it must not answer. Then reboot the computer and confirm it replies within 2 minutes without anyone logging in.

In my version

• Telegram bot, Claude Code on a Mac mini in a tmux session kept alive by launchd, plus a remote-control server so my phone's Claude app can open Mac sessions too.

Ask first

• Which actions may it propose? (default only moves inside your own accounts)
• How long is a ticket valid? (default 24 hours)
• Any limit above which it must not even propose? (default your choice; required)

Needs

• A chat app with buttons, or reply with "yes 1" if it has none.
• An account that allows orders by API, with keys the assistant cannot read.
• If your assistant can only chat: it writes the ticket text and you place the order yourself.

Build

1. Read: a proposal from another run or from the person.
2. Decide: reject it if it breaks a written rule or is over the limit.
3. Deliver: send a ticket with what, why and expiry.
4. Act: only the person's tap, checked by a separate process that holds the keys, places the order. The assistant has no path to approve.
5. Close: record approved, declined or expired.

Check

• Send a test ticket against a paper or sandbox account and confirm nothing happens until you tap.

In my version

• Tickets in my Telegram chat; a small script holds the keys and places the order only on my tap.

Ask first

• Which inboxes and calendars should it read? (default every account you check daily)
• When should the brief be ready? (default 30 minutes before you usually wake)
• What counts as "needs you today"? (default a reply, decision or payment due before tonight)
• Where should the text go? (default your usual chat app; a phone notification if it cannot text)

Needs

• Read access to email and calendar. Say to the person: "It reads to summarize; it never sends, deletes or accepts anything."
• Notes from any other assistant that acts for the person (calls, bookings), if there is one; skip that section if not.
• A scheduler that runs while the person sleeps, and a way to re-run a missed slot.
• If your assistant can only chat: paste the night's email subjects and today's calendar each morning and ask for the same four sections.

Build

• 1. Read: mail received since the last brief (window, not a fixed time), calendar for today, overnight notes from other assistants.
• 2. Decide: sort each item into Needs you today, On the calendar, Handled overnight, FYI. Needs you today means a dated ask or deadline before midnight. Keep: "confirm by noon". Drop: a newsletter with a sale ending today.
• 3. Deliver: write the brief as a dated note. Only if Needs you today is non-empty, send a short text with those lines. Nothing is sent to anyone else.
• 4. Remember: store the time of the last mail read so the next run starts there. If the machine was asleep at the slot, re-run once when it wakes.
• Cost: one model call a day, about 30 a month.

Check

• Run it now with the text turned off against yesterday's mail; every line in Needs you today must point to a real message with a same-day ask.
• A quiet morning produces the note and no text. Confirm the first scheduled run by the note's timestamp.

In my version

• A coding agent on a Mac mini, started by the system scheduler at 4:50am, with a 15-minute catch-up job for missed slots.
• Two inboxes (personal and my business), one calendar, call notes from my phone assistant (see "Make and take calls for me").
• Texts go to my chat bot (see "Run my computer from a chat on my phone").

Ask first

• How often, and between which hours? (default every 2 hours, 8am to 8pm)
• What is worth interrupting you for? (default a new ask with a deadline before the next check, a calendar conflict, or a watcher match)
• Any standing "ping me when" items to start with? (default none)

Needs

• Read access to email and calendar, plus notes from any other assistant that acts for the person.
• A small stored list of watchers: what to look for, added date, and whether it has fired.
• Say to the person: "It reads and decides; it never sends email, changes your calendar or messages anyone but you."
• If your assistant can only chat: say "ping me when X arrives" and ask "anything new?" a few times a day.

Build

• 1. Read: everything since the previous check (stored timestamp), the next 24 hours of calendar, and the watcher list.
• 2. Decide: the default answer is "nothing". Send only for (a) a new ask due before the next check, (b) a calendar change that creates an overlap, or (c) a watcher match. Keep: "the meeting moved and now overlaps". Drop: "a new newsletter".
• 3. Deliver: one text, three lines at most. A fallback is a notification.
• 4. Close: delete any watcher that matched, and say so in the text.
• 5. Remember: save the new timestamp after the run finishes.
• Cost: about 7 model calls a day, about 210 a month; use a small model.

Check

• Add a watcher for an email you can send yourself, run it with delivery off, and confirm it matches once and is then removed.
• A normal afternoon sends nothing.

In my version

• Runs 7 times a day on a Mac mini with a smaller model; watchers live in a small file; texts go to my chat bot.
• I add watchers by texting "ping me when ..." (see "Run my computer from a chat on my phone").

Ask first

• Which accounts, and can it get read-only access to each? (default whatever you can export; type in the rest)
• What are your rules? (default a target mix and how far each part may drift before you act)
• Which money dates matter? (default tax deadlines, renewals, big bills)
• Which days? (default Monday, Wednesday, Friday)

Needs

• Balances per account, read-only. Say to the person: "It reads balances; it cannot move money or place orders."
• A short written rules page the person owns. If they have none, help them write one first; that is most of the value.
• A list of upcoming money dates.
• If your assistant can only chat: paste balances and your rules page and ask for the same three sections.

Build

• 1. Read: pull balances with a script, not the model, and save them with today's date.
• 2. Decide: a script compares each number to the rules and flags anything outside its band; the model only writes the words around those flags. Dates within 30 days go under Coming up.
• 3. Draft: write three sections: Where things stand, Coming up, Decisions for you. Every decision is a proposal.
• 4. Check: a second pass confirms every number in the text matches the saved data; if one does not, send nothing and alert the person.
• 5. Deliver: email the briefing. Nothing is traded, paid or moved.
• Cost: a few model calls per run, about 40 a month.

Check

• Run it with email off and change one rule so a flag must appear; confirm it shows under Decisions and the check step passes.

In my version

• A coding agent on a Mac mini, three mornings a week; scripts pull the data, a few helper agents write sections, a checker compares numbers before it sends.
• Decisions I approve go to "Approve money moves with one tap".

Ask first

• Which day and time? (default Sunday evening)
• What counts as a correction? (default any time you told it to redo, stop or change something)
• How long unused before an instruction is proposed for retirement? (default 6 weeks)

Needs

• A searchable record of the week's chats and job logs.
• The assistant's own instruction files, which it can read but not edit in this run.
• If your assistant can only chat: once a week, ask "what did I correct you on this week, and what should you change?" and paste the answer into its custom instructions yourself.

Build

• 1. Read: corrections from the past 7 days, failed or noisy job runs, and last week's approved edits.
• 2. Decide: propose an edit only if the same correction appeared twice or a job failed twice. Keep: "two corrections about length". Drop: a one-off preference.
• 3. Deliver: write numbered proposals with the evidence for each. Never edit a live instruction file in this run.
• 4. Close: after the person approves, the live assistant applies the edit; next week's run reports whether it held.
• Cost: one larger model call a week.

Check

• Run it over last week with delivery off; every proposal must quote at least two real corrections or failures.

In my version

• A coding agent on a Mac mini, Sundays at 7:30pm, with a smaller model; proposals go in a file and I approve by chat.

Ask first

• Where does long-term memory live? (default one folder of short notes, one fact each)
• What is worth keeping? (default a fact that will matter in a future chat)
• Should it text you about changes? (default only if something changed)

Needs

• A place the assistant drops quick notes during the week, and a memory folder it reads at the start of each chat.
• Version history on that folder so any change can be undone.
• If your assistant can only chat: once a week, ask it to list what it learned about you and add or remove items in its saved memory.

Build

1. Read: the week's quick notes and the current memory index.
2. Decide: for each note, update an existing memory, add one, or drop it. Replace a fact that changed; never keep two versions of it. Keep: "moved to a new team". Drop: "was tired on Tuesday".
3. Deliver: write the changes, save a version, and write a one-page review of what changed.
4. Text the person only if something changed.

Check

• Plant two notes, one durable and one trivial, run it, and confirm only the durable one lands.

In my version

• A coding agent on a Mac mini, Sundays at 7pm; memory is plain text files with version history; the wiki is a folder of pages.

Ask first

• Which day and time to check (default Friday 8am, your time zone)
• How you want the picks: the place you already hear from your assistant (default)
• How many picks at most (default 3)

Needs

• An assistant that can run on a schedule and open a web page
• What your assistant already knows about you: your routines, tools and recurring tasks
• If your assistant can only chat: ask it "anything new on Runbook for me?" once a week and it does the same check on the spot

Build

1. Each week, open https://myrunbook.ai/new.json?since=<date of the last check, or 7 days ago>.
2. Pick at most three routines that fit something specific about the person: a task they repeat, a tool they already use, a gap in their week. Skip ones they already have, ones that need a setup they lack, and ones that are only broadly relevant.
3. If nothing fits, send nothing.
4. If something fits, send one short message: each pick's name, one line on why it fits, and its link, ending "Reply with a number and I'll set it up."
5. Never build anything without a yes. On a yes, open that routine's build steps and follow them.
6. Save the date of this check for next week.

Check

• Run it once now with since set to 30 days ago and delivery off; every pick must name a specific reason it fits
• A week with nothing new or nothing fitting sends no message

Ask first

• What may it call about? (default bookings, appointments and simple follow-ups)
• What must it never do? (default pay, share card numbers, or agree to anything costing money)
• Should it say it is an AI? (default yes, at the start)

Needs

• A voice-agent service with a phone number and an API.
• A fixed call-note format the agent returns: who, asked, result, follow-up.
• If your assistant can only chat: it writes a call script and you make the call.

Build

1. Read: the person's request and any times from the calendar.
2. Decide: refuse any request outside the allowed list.
3. Deliver: place the call, then save the call note where the morning brief reads it.
4. No answer or voicemail: leave no message unless the person asked for one, write "no answer" in the call note, and try once more after 2 hours.

Check

• Have it call your own phone for a fake booking and confirm the note matches what was said.

In my version

• A voice agent built on Bland, which my coding assistant dispatches by API from my own number; notes feed "Brief me on today before I wake up".

Ask first

• Which meetings count? (default all recorded ones since the last update)
• What gets its own page? (default a person, project or topic that comes up twice)

Needs

• Meeting transcripts or summaries from any note-taker.
• A folder of plain pages with an index and a change log.
• Meetings without a transcript: paste bullet notes and it treats them as a short transcript, marked "notes only".
• If your assistant can only chat: paste a meeting summary and ask which page it belongs on and what to change.

Build

1. Read: transcripts since the last logged update.
2. Decide: for each fact, update an existing page or make a new one. Flag contradictions; never pick a side silently.
3. Deliver: write the pages, update the index and log, and list what changed.

Check

• Run it on one past meeting and confirm every new line cites that meeting.

In my version

• Granola transcripts, read by Claude Code; plain text pages.

Ask first

• Where is your best writing? (default 10 pieces you are proud of)
• Words or habits you never want? (default none)

Needs

• Samples of the person's writing, and a one-page style guide built from them.
• If your assistant can only chat: paste the style guide at the top of each request.

Build

1. Read: the request and the style guide.
2. Decide: apply the banned-words list and the person's sentence habits.
3. Deliver: one draft; the person sends it.

Check

• Mix three of its drafts with three of the person's own; they should not be able to tell easily.

In my version

• A style guide, a samples file and a list of banned constructions, read by Claude before any draft.

Ask first

• Where should the page open? (default your browser)

Needs

• An assistant that can write and open a local web page.
• If your assistant can only chat: number the paragraphs and comment by number.

Build

1. Read: the current draft.
2. Deliver: write a page that shows it, lets the person select text and attach a comment, and has one button to copy all comments as a list.
3. Revise: the person pastes the list back; apply every comment in one pass.

Check

• Leave three comments, copy them, and confirm each quotes the selected text.

In my version

• Claude Code builds the page with a small annotation library bundled in.

Ask first

• What frameworks do you trust? (default: define done first, smallest v1, name the riskiest assumption)

Needs

• The doc, and a short page of the person's own frameworks.
• If your assistant can only chat: this is a chat habit; paste both.

Build

1. Read: the doc and the frameworks.
2. Decide: find the single weakest assumption, then what is missing, then a test that would change the person's mind.
3. Deliver: three short sections, no rewrites.

Check

• Run it on a doc you already know is weak and confirm it finds that weakness.

In my version

• A saved command in Claude Code that reads my frameworks page first.

Ask first

• Your rules? (default one page, no summary line)
• Where is the master list? (default build one from your current resume)

Needs

• A master list of every bullet you could use, and the job post.
• If your assistant can only chat: paste both and ask for a ranked bullet list.

Build

1. Read: the post and the master list.
2. Decide: rank bullets by match; never invent a claim.
3. Deliver: a one-page file plus notes on what changed and why.

Check

• Every bullet in the output must exist in the master list.

In my version

• HTML resume as the source, exported to PDF and Word; a notes file per version.

Ask first

• Which agents can you run? (default one coding agent, two copies)
• Max agents at once? (default 3)

Needs

• Two or more coding agents that run from the command line, and a repository.
• If your assistant can only chat: ask it for the task graph and run each task yourself.

Build

1. Read: the objective.
2. Decide: split it into tasks with dependencies; no two tasks edit the same files.
3. Deliver: start agents on ready tasks, show status, start dependents when a task finishes.
4. Failures: if an agent fails, retry once, then mark the task blocked and hold everything that depends on it. If two tasks touch the same file, run them one after the other.
5. Stop: when every task is done or blocked, or after 2 failures in a row.

Check

• Run a two-task objective where task 2 depends on task 1 and confirm it waits.

In my version

• A local web app that coordinates Claude Code and Codex.