Cursor Cloud Automations on This Site — Issue to Draft PR

Companion: Company OS learnings — what I kept after retiring the control plane explains why the thesis moved to archive while this loop became the day-to-day ship path for the personal site.
Operator model (go-live): Semi-automated 24/7 Cursor + GitHub learn loop — Assigned queue, learn:candidate promotions, and why merge stays human.

This site is an Astro SSR app on Vercel (@astrojs/vercel, Node 24). Changes that used to sit behind a heavier “control plane” narrative now flow through a small, repeatable GitHub loop — the same pattern documented in docs/agent-setup/README.md (public repo; no secrets in that doc).

The loop in one pass

GitHub issue (Agent Task template)
  → human review → label agent:ready
  → Cursor Execute automation (cron)
  → agent:running (claim one issue)
  → branch cursor/agent-issue-<number>
  → minimal implementation
  → npm run check:types && npm run build (Node 24)
  → push + draft PR linking the issue
  → agent:done
  → CI on the PR
  → human merge to main → Vercel production

Labels in GitHub: agent:draft, agent:ready, agent:running, agent:done, agent:needs-human. Draft issues stay in agent:draft until scope and acceptance criteria look right; only then swap to agent:ready for pickup.

Smoke history on this repo includes issue chains like #53→#54 and #49→#55 — useful proof that the loop closes, not just starts.

What the Cloud Agent environment runs

The linked Cloud Agent environment installs with Node 24 (matching Vercel runtime). In fresh shells, nvm’s Node 24 bin must lead PATH — the same gotcha noted in AGENTS.md for local and CI parity.

CI gate for agent work (no separate lint script in this repo):

Broader local gate when needed: npm run check. The agent is instructed not to merge PRs or touch Vercel dashboard secrets.

How this differs from the older self-hosted stack

Your AI agent stack is your competitive edge describes a 24/7 LangGraph / Paperclip / LiteLLM pipeline on Hetzner (~€35/month infra in that post) with mobile approval and persistent agent memory. That architecture still makes sense for multi-site, always-on orchestration.

This repo’s loop is narrower:

Neither replaces the other in my head — they optimize for different surfaces. Company OS captured the operating model; Cursor Automations capture shipping this codebase with reviewable diffs.

Operator checklist (public parts only)

1. Create an issue from the Agent Task template → agent:draft.
2. Review acceptance criteria; set agent:ready.
3. Automation picks one ready issue per run (oldest / highest priority).
4. Verify the draft PR: what changed, how it was tested, link to issue.
5. Merge when CI is green and the diff matches scope.

Conventions live under .cursor/rules/ and .cursor/skills/ (e.g. write-agent-issue, fix-ci). SEO-heavy tasks pull from .agents/skills/ separately — not mixed into every automation run.

Links

• Why Company OS stepped back: Company OS learnings
• Tools and agent skills: Toolstack
• Thesis archive (still 200): Company OS
• Agent setup docs: docs/agent-setup/

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