DIY software factory with Cursor

Inspired by Zach Lloyd's software factory posts — a DIY take on squeezing more out of subscriptions you already pay for, with GitHub, Cursor, OpenCode, or whatever CLI fits the job.

Inspired by Zach Lloyd's software factory#

This post is inspired by Zach Lloyd and the software factory framing he's been pushing: stop shipping every feature by hand and start shipping the machine that ships. Ben Holmes has been writing the practical follow-ups (triage skills, review loops, self-improving agents), mostly through Warp's Oz stack.

I wanted my own version — less "buy the factory," more "comment on the idea and build a small one with tools you already subscribe to."

The point for me: get more out of subscriptions you already pay for. Cursor is the obvious example here because that's what this repo runs. Same loop works with OpenCode, Codex CLI, Claude Code, or whatever CLI / model fits the use case. You adapt the worker; you keep the conveyor belt.

GitHub is that belt. Write an issue on the fly (GitHub Copilot in the issue UI is fine for drafting), slap a label, and let your preferred agent CLI pick it up in Actions. Labels are the gates. Humans still decide what crosses each line.

The boring loop worth automating#

Not an "autonomous software company." Just the repetitive middle:

1. Issue lands, someone triages it
2. Ready work, someone opens a PR
3. PR opens, someone does a first-pass review

Humans still decide what crosses each line. Agents do the reading, drafting, and checklist grind.

Keep the labels short and boring:

Cursor CLI is just a worker#

In Actions, the interesting part is embarrassingly thin:

- name: Install Cursor CLI
  run: |
    curl -fsSL https://cursor.com/install | bash
    echo "$HOME/.local/bin" >> "$GITHUB_PATH"
 
- name: Run agent
  env:
    CURSOR_API_KEY: ${{ secrets.CURSOR_API_KEY }}
  run: agent -p "Follow the ai:triage skill for issue #$NUMBER"

Wire each label to one job:

on:
  issues:
    types: [labeled]
  pull_request:
    types: [labeled]
 
jobs:
  factory:
    if: |
      contains(fromJSON('["ai:triage","ai:implement","ai:review","ai:verify"]'),
               github.event.label.name)
    steps:
      - run: agent -p "Run ${{ github.event.label.name }} for this event"

That's it. Your Cursor subscription (or a service-account key) becomes a CI worker — more miles out of a plan you're already paying for. Same idea works with OpenCode or any other CLI: different install line, same event → agent → git/gh handoff. Pick the model/harness per use case; don't rebuild the factory when the worker changes.

GitHub's hooks (issue opened, PR labeled, workflow_dispatch) are the scheduler. Draft the issue with Copilot if you want, label it, walk away. You do not need a second orchestration product to get value on a personal repo.

Skills are the factory floor#

YAML should stay dumb. Behavior lives in skill files mapped 1:1 to labels:

• ai:triage: classify, ask concrete questions, emit one readiness state
• ai:implement: branch, change, validate, open a draft PR
• ai:review: read-only findings only
• ai:verify: apply safe localized fixes from review, then stop

When the agent is dumb, fix the skill. Not a one-off prompt buried in an Actions log from three weeks ago.

My hard rules on this site:

• Labels move work (ai:triage → ai:implement → ai:review → ai:verify)
• Review/verify is one pass per trigger (no infinite review/fix spam)
• No auto-merge

If that sounds less sexy than a fully autonomous factory, good. Sexy factories become bot farms. Boring factories ship.

What I actually optimize for#

Warp's factory posts push the right north star: measure automation rate and cost, not vibes. On a one-person site I use a cheaper version of that:

• Did ai:triage ask a real question instead of inventing scope?
• Did the ai:implement PR survive with minor edits, or need a rewrite?
• Did ai:review / ai:verify catch something I'd have missed at 11pm?

If agent PRs mostly get thrown away, the issues weren't ready, or the skills were too loose. Either way, that's a factory bug, not a model complaint.

Start smaller than you think#

You do not need the full loop on day one.

1. Add ai:triage only. Read-only. Strict output format.
2. Manually label one safe issue ai:implement.
3. Treat the PR like a junior contributor's.
4. Add ai:review / ai:verify after implementation quality is boringly acceptable.

Cursor is the demo harness. The product is the loop — and getting real throughput from subscriptions you already have. Build the machine that removes the boring parts, swap the worker when you need to, and keep your hands on the interesting ones.