From an e-mail to a pull request: the go label

Level AdvancedEstimated time an eveningRead first Homelab 14: automate without a Zapier subscription, with n8n and a decision cascade, Claude Code, two ways: on the subscription and on your own models, Inari: your agents in your pocketA word you don't know? Glossary

Ideas arrive anywhere: on a walk, in a waiting room. You send yourself an e-mail. The next morning it is an issue on your forge, written properly, labelled, waiting. You read it, put the label go on it from your phone, and an agent does the work. You read the pull request and merge.

What you get. A queue of work fed from your mailbox and drained by local agents, with one human gesture in the middle. Each issue follows itself to the end: pull request linked, issue closed on merge, a "needs a human" flag when something fails.

1. The mail becomes an issue, and waits

You write to an address alias reserved for this (you+forge@…), subject [repository] what you want.
An automation reads the mailbox, and a local model drafts the issue: a clear title, a body, a kind (bug, feature, doc, task).
The issue is labelled triage: it means waiting for you. No agent touches it.

2. One label starts the work

Only an issue labelled go is work. A small worker passes every five minutes, takes one issue, and only if a model is actually loaded on a card:

labels it in progress and removes go;
hands the title and body to the coding agent, which opens a pull request;
comments the run's identifier on the issue.

Each following pass follows the run: pull request linked, issue closed when it merges, label needs-human and a comment when the run or the pull request fails. A task too wide for the agent gets needs-split.

The rule that makes it safe: no code ever adds the go label. Only your account, from your phone or the forge, can. A test checks that no script in the repository adds it.

3. Write the task for a small model

Give the agent the text, not the issue number: told "#4", a 9B model ran the same history search 208 times.
Four deliverables at most, a closed list of files, and a test that runs what was written.
Read the pull request before merging: short changes come back clean, long ones break.

Traps

Our forge's issue search ignored a label filter when no repository had that label yet, and returned everything. Check the label yourself on each result before acting.

Do not start the worker when no model is loaded: a run on an empty card fails after minutes and clutters the issue. Ask the GPU grid first.

Found this useful? Tell us what to measure next.