Engineer Runbook

Ask first

• Which sources may it read? (default your inbox, your texts, and notes from meetings if you keep them; ignore newsletters and automated mail)
• Who counts as someone you owe or who owes you? (default anyone who wrote to you personally in the last 60 days)
• When is a promise stale? (default 30 days, or 60 days if it has no date)
• Where should the list live? (default one page you open each morning)

Needs

• Read access to the sources
• One saved list with these fields for every item: title, who, direction (mine or theirs), source and link, date captured, due date if any, confidence (high or low), status (open, done or dropped) and why it closed
• A scheduler that can run every 15 minutes
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every 15 minutes, read messages and notes added since the last run. Pick out sentences where someone commits to do something: "I will", "I'll send", "we'll have it by", "can you send me".
2. Save each as one item with every field above. Mark confidence low if the commitment is vague or the date is a guess.
3. When a later message in the same thread contains the promised thing (an attachment, a link, the words "here it is"), close the item and write why. Never close an item on silence.
4. Mark an item stale after the stale limit and move it to a dropped list, never delete it.
5. Show the list with days waiting, oldest first, amber after seven days. This one list is the source for every other run that needs promises: the morning brief reads its Due from you section from it, and the follow-up run adds each commitment it drafts to it.

Check

• Seed three promises in a test thread; confirm all three appear with the right direction and date
• Send the promised thing; confirm the item closes and says why
• Confirm a vague promise is marked low confidence and a stale one moves to the list of dropped items
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a 15-minute schedule, one list I open each morning; my morning brief and my follow-up run both read and write it

Ask first

• Which errors qualify? (default new, with a clear stack trace)
• Which repository?
• Who reviews? (default you)

Needs

• Read access to the tracker and code, and permission to open a draft branch only
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every 15 minutes, look for new errors with a clear trace. Keep a list of the items already handled (by their address or id) and skip any that are on it, so the same item never produces a second brief, comment or draft.
2. Find the code at fault and write the smallest change that fixes it.
3. Add a test that failed before and passes now.
4. Open a draft pull request and stop. Never merge.

Check

• Introduce a known bug in a test copy; a fix and test appear
• Confirm nothing was merged
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a 15-minute schedule, a draft pull request

Ask first

• Which repositories?
• What do you always check? (default tests, secrets, large changes)

Needs

• Read access to pull requests and permission to comment
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every 15 minutes, find new pull requests with no review. Keep a list of the items already handled (by their address or id) and skip any that are on it, so the same item never produces a second brief, comment or draft.
2. Read the change and the tests.
3. Write what it changes, any risk and any missing test.
4. Comment. Never approve or merge.

Check

• Open a test pull request with a known flaw; it is named
• Confirm nothing was approved
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a 15-minute schedule, a comment on each pull request

Ask first

• What counts as an escalation? (default a ticket marked urgent, or open over three days with a second person involved)
• Where do tickets, chat and logs live? (a help desk, a team chat, a logging tool)
• Where are past cases kept? (default closed tickets from the last 12 months)

Needs

• Read access to the ticket, the chat threads and the logs, or paste them in
• A way to list changes released in the last 14 days
• Permission to comment on the ticket, never to change anything else
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every 15 minutes, find escalations with no diagnosis yet.
2. Collect the ticket, any linked chat threads, the logs for the affected account for the last 7 days, and the changes released in the last 14 days.
3. Search closed tickets for cases with the same symptoms. Keep the closest three and say how each was resolved.
4. Reason to the most likely cause. Give the evidence for it, the evidence against it, what you could not find, and your confidence as low, medium or high.
5. Name the one thing to check first. Comment it on the ticket. Never change a setting, a ticket status or a customer's data.

Check

• Replay a closed escalation you know the cause of; the diagnosis names that cause or says it could not tell
• Confirm a missing log is reported as not found and never guessed
• Confirm nothing but a comment was written
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a 15-minute schedule, a comment on each escalated ticket

Ask first

• Which products do you depend on, and where does each publish its release notes? (a link per product; a company blog, a docs page or a GitHub repo all work)
• What should the note flag? (default anything that changes your workflows, triggers or automation)
• Where should it reach you? (default a push to your phone)

Needs

• A list file with one line per product: name, link, and the last version or date you have seen. The last part is filled in for you after the first check
• An assistant that can run daily, read a web page and keep that saved value
• For a page that loads its content with JavaScript: a browser you are signed in to, read as text. For a GitHub repo: its release feed, which needs no browser

Build

1. Each day, for every line on the list, read the page and find the newest entry. Work out whether anything is newer than the saved value.
2. On the first check of a product with no saved value, record the newest entry as the baseline and say nothing.
3. If something is newer, write at most six short lines on what changed, then one line starting "Affects you:" on the things you named. Send it only to yourself, and move the saved value forward only after it was sent.
4. If nothing is newer, send nothing.
5. If a page cannot be read three days in a row, tell the owner once. If its layout changes so no entry can be found, say so once and stop.

Check

• Put two products on the list with different layouts (one with version numbers, one with dates) and a saved value two releases back for one; run once with sending off and confirm the summary and the Affects you line
• Run again with the real saved values and confirm it says nothing

In my version

• A shell script on a daily schedule, 8am Pacific, summary by claude -p, push to my phone; my list holds several products

Ask first

• What time should it arrive? (default 7am on weekdays, your time zone)
• Which calendars and inboxes count? (default your work calendar and work inbox)
• Which accounts or customers should it watch? (default any that wrote to you in the last 30 days)
• Where should it land? (default a page you open, or a message from your assistant)

Needs

• Read access to your calendar and inbox
• A short list of accounts to watch, or a way to infer them from recent mail
• The promises list, if you keep one. If you have none, build it by pulling "I will" and "I'll send" lines from your last 14 days of sent mail, or paste one in
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each weekday before the set time, read today's events, unanswered mail from the last three days, and any change in the watched accounts since yesterday.
2. Write one page with four parts: Today, Needs you, Moved overnight, Due from you. Read Due from you straight from the promises list; do not rebuild it from mail. Keep each part to at most five lines.
3. If a part is empty, leave it out.
4. Put the page where you read it. Never send anything on your behalf.

Check

• Run it once now and confirm each line names a person or an account, not a general remark
• Confirm nothing on the page is more than three days old unless it is a promise
• Confirm Due from you matches the promises list
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a weekday schedule at 7am, written to one page I open in the browser

Ask first

• Which logs and trackers? (a build tool, an error tracker)
• What is a new error? (default not seen in 14 days)

Needs

• Read access to the logs, or paste them in
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each morning, read the last 12 hours of build results and errors.
2. Group errors by cause. Mark any not seen before.
3. Say what changed shortly before each failure.
4. Name the one thing to look at first.

Check

• Replay a night with a known failure; it is caught and named
• Confirm each line links to the log
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a 6am schedule, a message

Ask first

• Where is your dependency list? (a lock file, a repository)
• What severity should reach you? (default high and critical)

Needs

• Read access to the dependency list and a source of advisories
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each morning, read new advisories.
2. Match each to the packages and versions in the list.
3. Report only matches, with the fixed version.
4. Send nothing when none match.

Check

• Run it with an old advisory that matches; it is reported with the right versions
• Confirm an advisory for something you do not use is dropped
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a daily schedule, a message only on a match

Ask first

• Which repositories?
• Who reads the changelog? (customers, your team)

Needs

• Read access to merged pull requests
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each Friday, list merged pull requests since the last changelog.
2. Drop internal-only changes.
3. Write each in plain words for the reader, with the link.
4. Flag anything that changes how people use or set things up.

Check

• Run it on last week; every line maps to a pull request
• Confirm internal changes are left out
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a Friday schedule, a draft in my docs

Ask first

• Where are incident notes?
• What monitoring data can it read? (metrics, logs)
• How noisy is too noisy? (default more than two false alarms a week)

Needs

• Read access to incident notes and the monitoring data, or paste both
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each Friday, list the week's incidents with when each started and when it was noticed.
2. For each, find the earliest signal in the data that was visible before it was noticed.
3. Propose one alert rule that covers the most incidents. Replay it over the last two weeks and count catches and false alarms.
4. Report both numbers. Say which incident it would not catch.

Check

• Replay last week's incidents against the proposed rule; the counts match what you see
• Confirm a rule that would be too noisy is rejected
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a Friday schedule, a page in my docs

Ask first

• What counts as long? (default over 400 words or any attachment)
• Which sources? (default your inbox and one shared folder)
• Where should the card land? (default a page you open)

Needs

• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file
• Read access to mail, attachments and the folder
• Somewhere to write a card per item with a link back
• If your assistant cannot read one of these, paste it into the chat when it asks. A thinner version still works

Build

1. Every 15 minutes, look for new long items you have not summarised, skipping any marked handled by another run, and read each fully.
2. Write a card: what it is, what it asks of you, dates, and what you would push back on. Under 80 words.
3. Link the original. Mark anything with a date in the next seven days.
4. Never reply or forward.

Check

• Run it on a document you know well; every date on the card is in the document
• Confirm a short email is skipped
• Say whether the writing step ran for real or on sample text. Check that every quote and link on the page matches its source, and drop any that does not

In my version

• Claude Code on a schedule, cards written to a page I open each morning

Ask first

• Where should complaints be sent? (default the assistant you already message)
• May the coding agent deploy without asking? (default no; it opens a change for you to approve)
• Where should tickets be visible? (default a simple tracker with five statuses: open, in flight, ready, waiting, resolved)
• How many fixes may run at once? (default two)
• Where does the "it is live" message arrive? (default a text; a notification if the assistant cannot text)
• Do you have a coding agent with access to the app's code today? (default no; then the routine stops at a filed ticket you fix yourself)

Needs

• An assistant that can take a message and store a ticket row: number, title, the complaint as said, status.
• A tracker people can look at, mirrored from the rows.
• A coding agent with the app's repository, its tests, and a way to deploy. Connecting: "It reads the app's code and tickets; it messages only you."
• A watcher that notices new tickets and starts one agent session per job, recording each job's state in a file so nothing starts twice.
• If your assistant can only chat: say "bug: X" and it writes the ticket; you paste the ticket into your coding tool yourself and tell the assistant when it is fixed.

Build

1. Read (file): the assistant's ticket tool takes a short title and the complaint as said, stores a row with an incrementing number, and replies with that number. Mirror the row to the tracker.
2. Read (pick up): the watcher checks for open tickets on a schedule, a few minutes apart, and starts a session per ticket up to the limit. The job file holds each ticket's state.
3. Decide (brief): the agent's standing brief is: read the ticket; find the cause; fix; run the type check and the tests; mark it ready. A separate merge step merges, deploys and checks the live app.
4. Decide (status): open when filed; in flight when a session starts; ready when the change passes its checks; waiting when the agent needs the person, with the reason; resolved when the fix is live, with a plain note of what shipped.
5. Deliver: when live, resolve the ticket and message the person what was wrong and what it now does. If it cannot finish, message that it needs them, with the reason. Fallback: a notification. Nothing goes to anyone else.
6. Memory: the job file and the tracker; a resolved ticket is never reopened by the watcher. One agent session per ticket.

Check

• File a deliberately small complaint with deploy off: the ticket appears as open, moves to in flight, then ready, with the type check and tests passing.
• The message to you names the cause and the result.
• Quiet run: a watcher pass with no open tickets does nothing and logs one line; the first real run shows as a status change in the tracker.

In my version

• I complain to Q, my assistant, by text or voice; tickets mirror to a Notion database; a watcher on my Mac starts Claude Code sessions, one at a time; a merge step deploys and smoke-tests; Q sends a push notification when the fix is live.

Ask first

• How do you mark a release?
• What counts as worse? (default errors doubled)

Needs

• Read access to deploy history and errors
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each release, compare an hour before and an hour after on errors and speed.
2. If worse, find the commit nearest the change.
3. Name the likely commit and mark it a guess.
4. If nothing got worse, say so in one line.

Check

• Run it on a past release you know was bad; it names the right area
• Confirm a guess is labelled
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code after each release, a note