How this site builds itself—Titanium Birch Labs

The section landing explains the experiment; this article is the ops layer—tools, workflows, PM and builder roles, and the path from a Linear ticket to merged code.

For what this experiment is and why it exists, start with About this Labs site. Here is the delivery mechanics layer: which tools hold state, which workflows fire when, and how a PM cycle ticket turns into merged code. The implementation lives in this codebase—workflow YAML under .github/workflows/, skills under .github/skills/, and agent instructions in AGENTS.md—summarised here for visitors without implying the repository is publicly browsable.

Tools

Tool	Role
Linear	Tickets, workflow state, delegation to Cursor Cloud agents (PM cycle tickets include `[repo=Titanium-Birch/MagnetMagpie]` and model directives per `linear-tickets` skill)
GitHub Actions	CI on every PR, deploy on `main`, weekday iterate schedule (chains deploy, feedback sync, audience sim, PM heartbeat), plus manual and callable workflows
Cursor Cloud	Executes PM and builder sessions; builders push branches and open PRs
Slack	Human feedback in `#magpie-feedback` is copied into a Linear inbox ticket by Feedback Sync so PM cycles can read it without manual copy-paste

Agent types

PM agent—Runs one cycle per trigger. Reads .github/skills/product-manager/SKILL.md: assess git and Linear, collect feedback (including audience simulation output read from iterate run logs via gh run list --workflow=iterate.yml rather than manually reading every page), write outcome-based tickets, delegate to builders, update AGENTS.md or skills when new stable constraints appear. Does not merge PRs, poll agents, or implement code.
Builder agents—Pick up delegated Linear tickets, edit the repo, run bash build.sh locally where needed, open cursor/* pull requests.

Process flow (each cycle)

Trigger—PM Heartbeat (heartbeat.yml) creates a Linear issue whose body instructs the PM agent and references the product-manager skill. Iterate (iterate.yml) runs on a weekday schedule (and manual dispatch) and invokes heartbeat after deploy, feedback-sync, and audience-sim with upstream step results embedded in the ticket. Heartbeat can also run alone via workflow_dispatch. Each agent run is a single cycle; recurrence is the next workflow trigger, not a loop inside the session.
State from Git—Recent merges and open PR counts are gathered in the heartbeat job and pasted into the new ticket description.
State from Linear—PM reads active tickets and delegation state (per PM skill).
State from GitHub Actions—CI results on PRs; optional audience simulation output via gh CLI; deploy outcomes when iterate runs.
State from Slack—Via the inbox ticket populated by Feedback Sync (feedback-sync.yml), which runs in the iterate chain on weekdays (and on manual dispatch) when secrets and variables are present.
Output—New builder tickets, occasional updates to AGENTS.md or skills, optional human-input requests filed as Linear issues.

Watchdog (watchdog.yml) has no cron; run it via workflow_dispatch or workflow_call. It lists open cursor/* PRs, flags conflicts, and can promote drafts—so stuck work can surface when the workflow is triggered.

Path from ticket to production

flowchart LR H[Heartbeat] --> PM[PM cycle] PM --> B[Builder agent] B --> CI[CI] CI --> AM[Auto-merge] AM --> D[Deploy] D --> H

Builder opens a PR from a cursor/* branch.
CI runs scripts/validate-site.sh (which includes bash build.sh: Hugo build, Playwright tests).
Auto-merge enables squash auto-merge for qualifying cursor/* PRs; GitHub merges when required checks pass.
Deploy Labs Site runs on push to main; if AWS role, region, bucket, and distribution variables are unset, the workflow logs a skip and exits without failing the chain.

GitHub Actions workflows

About a dozen workflows handle CI, auto-merge, deployment, agent scheduling, feedback sync, and housekeeping like branch cleanup and workflow linting. Each is a short YAML file under .github/workflows/ in the MagnetMagpie codebase.

Agent skills

Each agent type follows a skill file that defines its scope, rules, and exit conditions—covering product management, ticket mechanics, content authoring, development conventions, and graphics. Skills live under .github/skills/ alongside the code they govern. AGENTS.md at the repo root ties everything together with environment facts, cost constraints, and strategic context.

What changed after the first orchestration draft

An earlier PM design polled Linear and GitHub every minute, built the site every cycle, diff-reviewed every PR, and maintained a hand-off plan document. That burned context on status polling, duplicated CI’s job on reviews, and let plan files drift while Linear and git already held truth. The current heartbeat ticket text explicitly tells the PM not to read every page—Audience Simulation (audience-sim.yml) builds the site and checks rendered public/ pages against the content expectations register for violations, emitting PAGE_REVIEW: and PUBLIC_READINESS: lines, when iterate (or a manual run) invokes it.

Feedback and quality signals

Feedback Sync—Slack threads → Linear inbox for PM step 2.
Audience Simulation—Structured violation reports and pass/fail readiness lines in workflow logs when CURSOR_API_KEY is configured; cloud agents without that secret cannot run the sim locally (AGENTS.md).
Actionlint—Validates workflow YAML on PRs that touch .github/workflows/.

Refresh Model Map—Updates model-map.json from the Cursor models API when CURSOR_API_KEY is set; trigger manually or via workflow_call (no schedule).
Branch cleanup—Deletes merged cursor/* heads on PR close and can sweep stale branches on workflow_dispatch (branch-cleanup.yml).
Slack Deploy Summary—Posts a commit summary after deploy (chained from deploy.yml) when configured (no hourly cron).

For a live snapshot of merges, article coverage, and open questions at build time, see Live operations.