The correction loop matters more than the trigger

The trigger is simple. An issue gets a label, a webhook fires, and a worker opens a branch. The hard part begins when the first patch is wrong.

Hyper's GitHub App documentation says maintainers can add /hyper <instruction> to an issue or pull request. Inline review comments arrive in the session with the relevant file and line. When CI fails, the session can read the log and push another fix. An installation can disable that automatic CI repair.

This removes several awkward handoffs. A reviewer can correct the work without leaving GitHub and repeating the task in another chat. A red CI result does not wait for someone to paste the log into the agent. The job retains the plan, budget, rate limits, and repository access of a normal Hyper session.

The loop still needs a ceiling. CI may fail because of flaky infrastructure, an incompatible test environment, or a requirement the agent cannot infer. Automatic repair should stop after a fixed number of attempts, then attach the latest log, commit SHA, and attempted fixes. Ten new commits can show that the loop is busy without showing that the patch is closer to correct.

The verification check has a narrow job

Hyper adds a Hyper verification check to every pull request its App opens. Its documentation defines the conclusions precisely: success when every recorded test or browser-flow run passed, failure when a recorded run failed, and neutral when the session recorded no test or browser run.

The check is a receipt for the session. It does not establish that the repository's required suite ran, that the tests cover the change, or that a browser flow reached the risky path. A green session receipt and green independent CI answer different questions.

The neutral result deserves close attention. GitHub's protected-branch documentation says a required check may satisfy the merge condition with a successful, skipped, or neutral conclusion. Hyper says its check is neutral when nothing was recorded. Together, those published rules imply that a required Hyper check can be satisfied without recorded verification.

Do not make it the only required check. Require the repository's own build, test, lint, and security jobs separately. Compare the Hyper receipt with CI on the exact head commit. GitHub requires checks to pass on the latest commit SHA, so a repair commit should make earlier results obsolete.

Our guide to grading the full coding-agent trajectory makes the same distinction. Evidence helps when its scope is plain. A narrow receipt should not become a verdict on the entire change.

Begin with one low-risk repository

Hyper lists repository permissions for Contents (read), Issues, Pull requests, and Checks (read and write). GitHub recommends that Apps request the minimum permissions required, and an installation can be limited to selected repositories.

Use that selection as a hard boundary. Start with a disposable or low-risk repository that still has representative CI, branch protection, and review rules. Check the permissions shown during installation, the human account linked to the App, who may add the trigger label, and how the service obtains code access for its session.

The least-privilege checklist for AI agent tools also applies beyond GitHub. An App can have narrow platform permissions while a build reaches package registries, test databases, cloud credentials, or deployment systems. Repository permissions cover only one layer of execution.

Choose a pilot issue with an observable acceptance condition and a patch that a maintainer can inspect line by line. A failing unit test with a known reproduction or a narrow validation bug is a better first job than credential handling, workflow-file changes, a dependency upgrade with broad lockfile churn, or production deployment logic.

Give the issue a testable finish line

An issue assigned to an agent should explain how a reviewer can tell it is done. Include the failing behavior, expected behavior, constraints, and commands that must pass. Point to public interfaces that may not change. If the repository lacks a regression test, require one that fails on the base commit and passes with the fix.

A compact handoff might read:

Reproduce: `npm test -- auth/session.test.ts`
Expected: an expired refresh token returns 401 and is never rotated.
Constraints: do not change the public response schema or session TTL.
Required evidence: regression test, full auth suite, lint.
Stop and ask: any database migration or new production secret.

That stop condition prevents a comment-driven job from quietly expanding into a migration or infrastructure change. Our safe pattern for comment-triggered coding-agent automation recommends narrow triggers, bounded retries, explicit permissions, and review checks. Those controls do not depend on a particular coding agent.

Deliberately test the bad paths

A useful pilot should produce four outcomes: a clean fix, a correction from a reviewer, a failed CI run, and a session with no recorded test. Confirm which comments the App accepts, whether an unauthorized user can trigger or steer work, how many repair attempts it makes, and what happens when a failure has nothing to do with the patch.

Read the pull request as a maintainer would. Is the session link durable? Can the reviewer see which commands produced the verification result? Does the recorded commit match the pull request head? Is a neutral Hyper check visibly different from a pass? Can branch protection require the independent check from a specific GitHub App? GitHub lets a repository select the expected source for a required check, reducing the chance that another integration posts a status with the same name.

Hyper has brought the agent into the issue and pull-request system where engineering work is already governed. Keep the convenience near the beginning and the authority at the end. A label may start work, comments may steer it, and session evidence may explain it. Independent branch rules should still decide whether it merges.