Your first pull request

Go from the demo to a real PR

The demo on the install page ran entirely offline. This rung costs three things it didn't: a signed-in agent harness, a GitHub token, and a repository with a labelled backlog for the agent to work against.

Every agentic stage needs one signed-in coding-agent harness. There are exactly two: GitHub Copilot CLI or Claude Code CLI.

npm install -g @anthropic-ai/claude-code
claude auth login

Verify Goobers can see it once you have an instance (below): --check-harness execs the harness CLI directly, in your process's own environment, and prints HARNESS claude-code: OK (or HARNESS copilot: OK) once it's installed and signed in.

One fine-grained PAT, scoped to the one repository, covers this rung: Contents (read and write), Issues (read and write), Pull requests (read and write), and Actions (read-only — GitHub's fine-grained UI has no separate Checks permission, so this is what lets CI status resolve on a private Actions-only repo). Export it as GOOBERS_GITHUB_TOKEN; one export covers both connecting and seeding below.

Running Copilot headless (no interactive sign-in on this machine) also needs a second, personal PAT with account-level Copilot Requests: Read-only, exported as COPILOT_GITHUB_TOKEN. That one has to be in the process environment directly — the startup preflight execs the harness CLI before any run exists, so a token.env reference in instance.yaml isn't resolved yet at that point; it only reaches a stage's subprocess once a run actually dispatches. Real least-privilege scoping, both identities, and why they end up distinct, is on tokens and permissions.

The quickstart template's shipped sample needs Node.js 20+ and npm on the same PATH Goobers will use — confirm with node --version / npm --version before materializing it; Goobers preflights the CI executable and fails before claiming any work if it's missing.

goobers onboarding stub-sample --destination ./getting-started-task-api --json
goobers init --template=quickstart ./tutorial-instance

stub-sample writes a disposable Node/npm project; it's non-interactive, safe to re-run, and never creates or pushes a remote itself. Create an empty GitHub repository and push that directory to it — any name, delete it whenever you're done — then point the instance at it:

export GOOBERS_GITHUB_TOKEN=<your token>
goobers connect <owner>/<repo> --seed ./tutorial-instance

connect rewrites the template's placeholder your-org/your-repo in instance.yaml and every materialized gaggle, records the token by name only — the value itself never passes through this command, and a value that looks like a pasted token is rejected — and validates the result in-process before touching anything else. --seed idempotently ensures the two label sets the workflow's backlog selector needs actually exist on the repository (without them a run dies at its first park or close-out) and files one starter issue carrying selector labels only. Configuration already pointing at a real repository is left untouched unless you pass --replace.

goobers validate --check-harness --check-repos ./tutorial-instance

--check-repos resolves the repository's token and verifies authenticated access before a run can claim anything against it — the same failure mode either flag catches here is one you'd otherwise hit mid-run instead.

goobers run quickstart ./tutorial-instance

This is a real autonomous run against your disposable repository, so it takes noticeably longer than the offline demo: it claims one approved issue, implements it, performs an advisory code review, pushes the run branch, and opens a pull request. Watch it the same way as the demo, goobers dashboard ./tutorial-instance in a second terminal.

quickstart@v1 is deliberately not production-safe: no CI gates, no remediation loops, no bounded escalation, no merge policy, no issue close-out. The onboarding happy path has no stall points on purpose — production configuration is its own step, past this page.

goobers init --guided is a first-run-only path toward a regular production instance instead of the disposable sample: it proposes one neighboring Goobers Instance and keeps active configuration and runtime state there, pinning a custom durable location instead with --instance-path <path>. It refuses a target that already has an instance.yaml or a populated config/, so it's safe to attempt and hard to trigger by accident. A separately reviewed configuration source stays an advanced opt-in past this default path.

The daemon's PATH is not your interactive shell's — a tool your dotfiles put on PATH can still be invisible to a stage. And if a provider rate limit stalls you, goobers reset-rate-limit clears the hourly run budget without touching runs/ — the instinct to rm -rf the instance instead destroys the run journals along with it.