Semi-Automated 24/7 Cursor + GitHub Learn Loop — What I Run Day-to-Day

Companion: Cursor Cloud Automations on this site — issue to draft PR covers the first diagram (issue → branch → CI). This post is the operator model after go-live: feeding the queue, approving on mobile, and promoting learnings into rules.

The operating model in one screen

Semi-automated here means the agent runs on a schedule, but merge authority stays human. I feed agent:ready issues; Cursor Execute claims one per run; I approve from GitHub on my phone when CI is green.

Issues (labels)                    Pull requests (human)
─────────────────                  ─────────────────────
agent:draft  → human scopes        (nothing yet)
agent:ready  → cron picks ONE      branch cursor/agent-issue-<n>
agent:running → work in flight     PR opens (Ready for review)
agent:done   → PR exists           github.com/pulls/assigned ← YOU
agent:needs-human → blocked        Approve → Merge → Vercel prod

Parallel learn path:
PR Learnings → learn:candidate issue → Learn automation → .cursor/rules|skills

That is Cursor Cloud Automations 24/7 in practice: not a factory that merges while you sleep, but a GitHub agent workflow that keeps shipping if you keep the inbox stocked.

Why this ROI level — not full auto-merge

I tried the mental model “merge everything the agent opens.” It fails the same way cheap models fail ROI: you move cost from tokens to incidents and calendar.

Night runs still help — if you feed agent:ready before bed. The agent does not invent scope; it executes acceptance criteria you already wrote. That is the difference between “24/7 agent” marketing and a loop that actually closes.

Operator queues — issues vs Assigned

Two surfaces, two jobs:

GitHub Issues (by label) — pipeline state for work to do:

GitHub Pull requests — pipeline state for work to ship:

• Primary: Review requests
• Backup: Assigned to you

Execute always assigns emilingemarkarlsson and requests review (cursor-bot as author). After merge, unassign yourself — GitHub does not clear assignees on merge, and Assigned should only mirror open PRs waiting for you.

Public docs: docs/agent-setup/APPROVE.md.

Execute loop (short)

The deep issue→PR path lives in the companion post. Day-to-day Execute does this:

1. Pick oldest open issue with agent:ready → swap to agent:running
2. Read acceptance criteria; touch only what they require
3. npm run check:types and npm run build on Node 24 (PATH prepend per AGENTS.md)
4. Push cursor/agent-issue-<number>, open PR with Closes #<number>
5. PR: Ready for review, assign + request review, ## Din tur with preview URL
6. Set agent:done on the issue

Prompt source: docs/agent-setup/EXECUTE_PROMPT.md. Skills: .cursor/skills/write-agent-issue, .cursor/skills/fix-ci. SEO tasks pull .agents/skills/ separately — not every run.

Learn loop — learn:candidate → rule → small PR

Execute is not where architecture knowledge should die. When a run teaches something specific — a command, a label transition, a schema limit — the PR Learnings section can spawn a follow-up:

Agent PR merged
  → concrete bullet in Learnings
  → new issue: title [learn] …, label learn:candidate only
  → Learn automation (cron / manual)
  → promote ONE change via .cursor/skills/promote-learning/SKILL.md
  → PR to .cursor/rules/*.mdc OR .cursor/skills/*/SKILL.md OR docs/agent-runs/
  → human merge (same Assigned queue)

Vague learnings (“be careful with SEO”) are skipped. Good ones look like: “seo.description hard-fails at 160 chars in src/content.config.ts — count before push.”

Prompt: docs/agent-setup/LEARN_PROMPT.md.

This is how learn loop AI agents compound without a separate memory product: GitHub issues as the inbox, repo files as the memory.

Mobile approve — GitHub app, no secrets

I do not need a custom approval dashboard for this repo. The GitHub mobile app sends Participating notifications when Execute requests review or assigns me.

Flow on phone:

1. Tap notification → PR
2. Read ## Din tur → open Vercel preview if the diff is UI/content
3. Check CI badge
4. Approve → Merge
5. Remove assignee on the merged PR (sidebar)

No tokens in posts, no private automation UUIDs in the body — only public labels and queue URLs.

What broke / what we fixed (high level)

Shipping this loop surfaced boring ops issues, not agent magic:

• Node 24 in Cloud Agent shells — default node was v22; install nvm 24 and prepend PATH (documented in AGENTS.md and .cursor/environment.json).
• Draft PRs without assignee — easy to miss in notifications; Execute now always assigns + requests review.
• Bugbot / review bot limits — usage caps mean not every PR gets automated review; human Assigned queue remains source of truth.
• seo.description length — content schema max 160 chars; several agent posts failed build until descriptions were shortened (same class of bug as frontmatter typos).

These are operator fixes, not reasons to abandon semi-auto. They are why the learn loop exists.

Run this tomorrow morning (checklist)

1. Open Issues with agent:draft — tighten acceptance criteria on one issue; flip to agent:ready.
2. Open Assigned — merge or request changes on any open agent PR.
3. After merge, unassign yourself on closed PRs if GitHub left you on the sidebar.
4. Skim Toolstack if a task needs .agents/skills/ (SEO, schema, CWV) — link skills in the issue body, not in every automation.
5. If a merged PR had a concrete Learning, confirm a learn:candidate issue exists or create one manually.
6. Verify production on Vercel after merge (this site deploys from main).
7. Keep @astrojs/vercel — do not swap hosts mid-loop.

Context from the archive

Company OS learnings explains why the heavy control plane stepped back while this loop became day-to-day shipping. The six-layer model still applies: approvals and outcomes stay explicit even when Execute runs every 30 minutes.

For contrast with always-on self-hosted orchestration, see AI agent stack as competitive edge — different surface area, same discipline about who merges.

FAQ

What is a semi-automated 24/7 Cursor + GitHub coding loop?
A scheduled Cursor automation claims one agent:ready issue, implements minimal scope, opens a PR, and marks agent:done. You merge from GitHub Assigned — the loop is 24/7 only when the issue queue is fed.

Why not fully auto-merge agent PRs?
Because publishing and production changes need a human quality gate. Auto-merge saves minutes; a bad deploy costs hours. This matches the autonomy ladder: execute freely inside scope, approve irreversible ship steps.

How does the learn loop turn a run into a lasting rule?
Concrete PR learnings become learn:candidate issues. A Learn automation promotes one rule into .cursor/rules, .cursor/skills, or docs/agent-runs/, then opens a small PR for you to merge.

Where do I approve?
Review requests first; Assigned as backup. Every Execute PR should assign you and request review.

How is this different from LangGraph/n8n on a VPS?
Self-hosted stacks orchestrate many workflows 24/7 on your infra. This loop is one repo, one PR per issue, Cursor Cloud Agents for compute, GitHub for state — less ops, tighter scope.

For the systems behind this work, explore the projects, the toolstack, or start a conversation.