Coding tasks

Describe a change and the coding loop makes it: it clones your connected repo in an isolated sandbox, edits the code, runs your project's own typecheck/build, and opens a pull request as the deliverable. You review the diff on GitHub and merge when it's right.

Prerequisites

• A connected GitHub repo. Without it the loop can't proceed — it tells you to connect GitHub in Integrations and stops.
• If you've selected a repository in Integrations → GitHub, the loop uses it verbatim. Otherwise it picks the repo that best matches your request and notes the assumption.

Two paths: spec-first vs. straight to PR

What you ask for decides the path:

• A full feature — a new user-facing capability that isn't there yet — goes through the Pointer→PR loop. First a run reconstructs your one-liner into a product spec: what users will be able to do, acceptance criteria in plain English, scope, and any open questions where the answer changes the user-visible behavior. The spec lands in the ticket for you to review.
• A bugfix, refactor, copy change, dependency bump, or any small tweak goes straight to a pull request — no spec step.

The spec is a product document, not a technical design — it's how you confirm the agent understood the feature before any code is written. Approve it and the next run implements; or comment with changes and it revises.

Ask for a change

Talk to the dispatcher in the sidebar in plain language:

add a dark-mode toggle to the settings page

fix the 500 error when saving a profile with an empty bio

The first is a feature — you'll get a spec to approve. The second is a bugfix — you'll get a PR directly.

Approve a feature spec

When a spec is filed, the ticket flips to awaiting review with an Approve & implement button. Clicking it posts "Approved" as your comment, which re-runs the loop to implement the spec — clone, change, open a PR. You can also type a comment instead (for example, to narrow scope or answer an open question); the next run reads your comment and decides whether to implement, revise the spec, or reply.

What the implementing run does

1. Clones and branches — git clone your repo, then a fresh adagent/<slug> branch.
2. Installs dependencies — it detects your package manager and the version your lockfile needs, and installs before editing.
3. Edits to your conventions — it matches your framework, directory layout, and file patterns, touching only the files the change requires.
4. Verifies the build — before committing it runs your repo's own typecheck, then build, then lint (only the scripts that exist in your package.json). A PR that breaks the build is worse than no PR, so it fixes what it broke and re-runs until the checks pass.
5. Opens the PR — commits, pushes the branch, and opens a pull request whose body says what changed and why, plus anything it deliberately skipped or couldn't verify.

If a check genuinely can't run for reasons unrelated to the change — a private registry the sandbox can't reach, a pre-existing failure, or a repo with no typecheck/build script — the run doesn't abandon the PR. It states plainly in the PR body what it ran, what passed, and what it couldn't verify, rather than claiming the change is verified when it isn't.

What you get

A single pull request on your branch, ready to review like any other change. One PR per run — depth over volume. The diff is the deliverable; merging is always yours.

Keeping the PR mergeable

If your main branch moves and an agent-opened PR goes conflicted, the PR babysitter steps in: it re-merges the latest base into the PR branch and conservatively resolves the conflict — but only when both sides' intent is unambiguous (the canonical safe case is two non-overlapping additions). When reconciling needs product judgment it doesn't have, it leaves the PR conflicted and flags the exact region for you rather than guessing. A wrong auto-resolution is worse than an honest flag. See the PR babysitter page for the full lifecycle.

Notes & limits

• A run is capped at roughly 20 minutes, each command at about 10. For a heavy monorepo build the loop scopes down — typechecking just the package it touched — rather than burning the budget on a full build.
• It never commits secrets or the raw contents of your file store — only derived repo files that match your project's conventions.
• If there's nothing to change (the change is already present, or the request isn't actionable), the run opens no PR and tells you why instead of fabricating one.