Ship-It Lena (test)
Every routine below is something AI runs for Ship-It. Press Copy for my agent on any of them to have your own AI build it.
Ship-It Lena (test), you've built a night shift that writes its own bug fixes and a sceptic who heckles your pricing page, and the whole business runs on drafts you sign off.
1Sort overnight support email into the tracker
Each support email becomes a ticket in the tracker with a severity and a suggested reply saved as a draft. A morning note lists anything marked urgent.
Sort overnight support email into the trackerDraft
Overnight: 7 emails, 5 tickets, 2 duplicates merged. Urgent (1): export fails for accounts over 10k rows; draft apology and workaround saved. Normal (4): two billing questions, one feature request, one password reset.
How to borrow it
- Reads
- the support inbox, the ticket tracker, the docs site
- Done when
- A ticket closes itself when I send the draft and the customer does not reply within 5 days
- Runs on
- a coding agent on a schedule
Ask first - Where does support mail arrive? (default one shared inbox) - Which tracker do you use, and does it have an API or email-in address? (default email-in) - What makes something urgent? (default: the product is unusable for the customer, or the word "urgent" with a paying account) - Do you want drafts, or only tickets? (default both) Needs - read access to the support inbox and the ability to save drafts. The agent says: it reads the support inbox only, never the person's own mail, and never sends. - a tracker that accepts tickets by API or email. Without one, the agent keeps a plain text file of tickets and the morning note links to it. - the docs site, for the suggested reply. Without docs, drafts say only what the agent can see in the thread. - a chat-only version: paste the overnight emails each morning and ask for severities and replies. Build 1. Read: unread support emails since the last run. Keep the last run time in a small state file so nothing is read twice. 2. Decide: group emails by sender and subject into one ticket each; a second email on the same subject within 24 hours is a comment on the existing ticket, not a new one. Severity: urgent per the rule above, otherwise normal. Write a reply from the docs where a docs page answers the question; where none does, write "I have logged this" and nothing more. 3. Deliver: one ticket per group, one draft per ticket, and one morning note listing the urgent ones. Nothing is sent to a customer. 4. Closing: a daily pass marks a ticket done when the draft was sent (it is no longer a draft) and no reply has come in five days. Roughly 60 model calls a month at this volume; set a cap of 200. Check - Send two test emails with the same subject from one address: one ticket, two comments. - Send one containing "urgent" from a non-paying address: severity normal. - A quiet night: the morning note says "nothing overnight" rather than not arriving. In my version - A coding agent on a cron job on a small server. Tickets go to the tracker by API. The support inbox is a shared mailbox, separate from my own.
2Watch the error log and open a fix for anything new
A pull request waits each morning for any error that appeared for the first time yesterday, with a test that reproduces it. I review and merge.
New last night: TypeError in the export worker when a column is null. PR #312 adds a null guard and a test with a null column. 14 lines. Review time about 5 minutes.
How to borrow it
- Reads
- the error tracker, the repository
- Done when
- Closes when the PR is merged and the error has not reappeared for 3 days
- Runs on
- a coding agent on a schedule
Ask first - Where are errors collected? (default the hosting platform's log) - Which repository and branch? (default main) - May the agent open PRs, or only write patches to a folder? (default PRs, never merge) Needs - an error source the agent can read, with a message and a stack trace. - a repository it can read and push a branch to. The agent says: it pushes branches and opens PRs; it never merges or deploys. - a chat-only version: paste the stack trace and ask for the fix and the test. Build 1. Read: errors since the last run, deduplicated by message and top stack frame. Keep the set of seen errors in a state file. "New" means not seen in the last 30 days. 2. Decide: for each new error, write a failing test that reproduces it, then the smallest change that makes it pass. If a fix would touch more than 60 lines, stop and write a note instead of a PR. 3. Deliver: one PR per error, titled with the error message, with the test and a three-line explanation. Nothing merges. 4. Memory: a fixed error stays in the seen set; if it reappears after merge, the morning note says "regressed". Check - Throw a deliberate error in a test route once: the next morning a PR exists with a test that fails on main and passes on the branch. - A night with no new errors: the morning note says "no new errors". In my version - A coding agent on cron, reading the hosting platform's log through its CLI. About three PRs a week.
3Draft the changelog from merged pull requests
A changelog entry is drafted in the docs repo for anything merged today, in customer words, with a screenshot placeholder where the UI changed.
Draft the changelog from merged pull requests
14 October
Exports now handle empty columns without failing.
The billing page shows the next invoice date.
[screenshot: billing page]
How to borrow it
- Reads
- merged pull requests, the existing changelog
- Runs on
- a coding agent on a schedule
Ask first - Where does the changelog live? (default a markdown file in the docs repo) - Which PR labels are customer-facing? (default anything not labelled internal) Needs - a list of merged PRs with titles and descriptions. - a place to write the draft. Without a docs repo, a text file the person copies from. Build 1. Read: PRs merged since the last run. 2. Decide: skip internal labels. Rewrite each title as what the customer can now do, one line each, no file names. Where files under the UI folder changed, add a screenshot placeholder. 3. Deliver: one dated draft block appended to a draft file; the person moves it to the real changelog when they publish. Check - Merge a PR labelled internal: nothing is drafted. In my version - Same agent as the error routine, same server.
4Chase trial users who stalled
A draft email sits in my outbox for each trial that signed up over 3 days ago and has not created a project, mentioning the one thing they did do.
Chase trial users who stalledDraft
Hi Sam, you set up a workspace on Thursday but have not added a project yet. The quickest way in is the sample project on the home screen. Anything in the way? Lena
How to borrow it
- Reads
- the product database, the email tool
- Done when
- A draft is dropped if the person creates a project before I send it
- Runs on
- a coding agent on a schedule
Ask first - What counts as stalled? (default signed up 3 or more days ago, no project created) - How many drafts a week at most? (default 20) - Any plans or countries to skip? (default none) Needs - a way to read sign-ups and their first actions, a database or an export. - an email tool that can hold drafts. Without one, a text file of drafts to copy from. - a chat-only version: paste the week's sign-up list with a column for projects created and ask for the drafts. Build 1. Read: users created 3 to 14 days ago with zero projects, excluding anyone already drafted in the last 30 days (kept in a state file). 2. Decide: for each, find the one thing they did do (named the workspace, invited someone, opened the sample) and mention it. If they did nothing at all, use a plain version. 3. Deliver: drafts only. Before the person sends, a check step deletes any draft for a user who has since created a project. Check - Create a test user dated five days ago with no project: a draft appears. Create a project for them and run the check: the draft is gone. In my version - A query against the production database replica, drafts in the email tool. About twelve a week.
5Match payouts to invoices before I look at the books
A sheet lists this week's payouts from the payment processor against invoices, with anything unmatched at the top. Most weeks the top is empty.
Week to 10 Oct: 23 payouts, 23 matched. Unmatched: none. Refunds: 1 (customer 4471, partial).
How to borrow it
- Reads
- the payment processor, the invoicing tool
- Runs on
- a coding agent on a schedule
Ask first - Which processor and invoicing tool? (default: ask, then use read-only API keys for both) - What is a match? (default same amount within 1 unit of currency and same customer, within 7 days) Needs - read-only access to payouts and invoices. The agent says: it reads amounts, dates and customer ids; it moves no money. - a chat-only version: paste both exports and ask for the unmatched rows. Build 1. Read: payouts and invoices for the last 7 days plus 7 days before, so late ones match. 2. Decide: match by the rule above; refunds are listed separately; anything matched last week is not repeated. 3. Deliver: one sheet with three sections, unmatched first. If unmatched is empty, say so in the first row. Check - Add a test invoice with no payout: it appears in unmatched. Add its payout: next run it is matched. In my version - Read-only keys for both tools, stored on the server, never in the repo.
6Draft my monthly investor update from the numbers
A draft update appears as a document with revenue, sign-ups and churn pulled from the dashboard, with the narrative left for me to write in brackets.
October update Revenue: [figure], up [x]% on September. Sign-ups: [n]. Churn: [y]%. [What happened: ...] [Asks: ...] Shipped: exports fix, billing dates, two changelog posts.
How to borrow it
- Reads
- the metrics dashboard, last month's update
- Runs on
- a coding agent on a schedule
Ask first - Which five numbers do you always report? (default revenue, new sign-ups, churn, cash, runway) - Where is last month's update? (default a folder of past updates) Needs - the numbers, from a dashboard, a database or typed in. - past updates for structure. Without them, use the five-number template. Build 1. Read: the month's numbers and last month's update. 2. Decide: fill the numbers, copy last month's section headings, leave every narrative section as a bracketed prompt. Never invent a reason for a change in a number. 3. Deliver: a draft document. Nothing is sent to anyone. Check - Run it with last month's numbers: every number in the draft matches the dashboard, and no narrative text is filled in. In my version - Numbers come from the product database and the payment processor; the draft goes to a documents folder.
7Rewrite the docs pages an API change affects
A pull request to the docs repo updates every page that mentions the changed endpoint, with the old and new examples side by side for me to check.
Docs PR #88: 4 pages mention /v1/export. Updated the parameter name on all four, regenerated 3 code samples, flagged one page whose example no longer makes sense (needs a human).
How to borrow it
- Reads
- the API change (a PR or a diff), the docs repository
- Runs on
- a coding agent
Ask first - Where are the docs, and how are code samples kept? (default a docs repo with samples inline) Needs - the diff of the API change and read and write access to the docs repo. - a chat-only version: paste the diff and the page, ask for the updated page. Build 1. Read: the diff, then every docs page mentioning any changed name. 2. Decide: update parameter names and samples mechanically; where the meaning of a page changes, leave a flagged note instead of guessing. 3. Deliver: one PR with a list of pages touched and pages flagged. Check - Rename one parameter in a test branch: the PR touches exactly the pages that mention it. In my version - Run by hand from the terminal when I merge an API change.
8Argue against my pricing page before I publish it
Two replies come back: the five objections a sceptical buyer would raise about the new page, and a rewrite that answers each one without adding length.
Objections: 1. "Unlimited" is undefined. 2. No annual price shown. 3. The team plan hides the per-seat cost... Rewrite: (follows, same length)
How to borrow it
- Reads
- the draft pricing page
- Runs on
- a chat assistant
Ask first - Who is the buyer? (default a small team lead paying with a company card) Needs - the page text. Fully a chat routine. Build 1. Read: the draft page. 2. Decide: objections must each quote the line they object to. The rewrite may not be longer than the original. 3. Deliver: two replies, objections first. Check - Paste a page with the word "unlimited": it is objected to. In my version - Claude in the browser, before each pricing change.
Tools
Reads from
- the support inboxemail
- the error trackererrors
- the payment processorpayouts
Runs on
- a coding agentcron on a small server
Runbook updated 14 October 2026