Skip to main content
This is preview documentation. The official release is not yet available.
Have an all-Hosted Team add status filtering and pagination to order queries. The Leader, Developer, Reviewer, and QA run on Runtime Hosts and carry a GitHub Issue through implementation, PR creation, review, CI, rework, approval, and merge. Roles may use the same provider or different supported providers.

​
Goal and prerequisites

Prepare Service, working Runtime Hosts and authenticated providers, Git, GitHub CLI, and JDK 17+. Use an exercise repository with developer and independent reviewer identities. A repository administrator configures required checks, branch rules, and merge permissions. Hosted identity and GitHub identity are separate; creating Agent roles does not create GitHub accounts. Download these files, remove the final .txt, and place them in the exercise repository: The fixture implements the query logic behind an order API, not an HTTP server. Filtering and pagination are intentionally absent: three of five checks fail initially. The Issue also requires additional boundary tests. Ignore out/, commit the fixture and CI, and create the Issue. Initial CI failure represents the unimplemented feature.
The baseline and a reference repair were checked locally. Execute the GitHub and Team steps below in your configured environment.

​
1. Create four Hosted roles

Follow Hosted setup, then verify each Agent’s task and collaboration capabilities. The Developer needs push/PR access, Reviewer needs review access, and QA needs Actions status/log access. Merge uses an authorized identity. Isolate GitHub identities using Host users, execution environments, or tool credentials rather than concurrently switching a shared CLI login. Under DESIGN → Teams, select the Hosted Leader and add the other three members. Use team instructions such as:

​
2. Start from a GitHub Issue

Create a Service Issue under WORK → Issues with the GitHub Issue URL, OWNER/REPO, base branch, test command, criteria, and authorization scope: delivery through a merge-ready PR or including merge. Assign the Team and require human acceptance. The Leader reads the original GitHub Issue through its tools and retains its identity. This minimal path does not require event bridging. If GitHub Work Source is configured, use the synchronized Service Issue. The current adapter handles Issues and comments; PR review and CI still require GitHub tools. Set REPO, ISSUE_NUMBER, BASE_BRANCH, and subsequent variables to actual task values. Check identity in the task environment:
The Leader turns filter-before-pagination, blank filters, unmatched results, large pages, invalid arguments, and input immutability into a checklist before delegation.

​
3. Implement and create a PR

The Developer clones the exercise repository into its Host task directory and creates a task-specific branch. A repository open on the administrator’s computer is not automatically task input. Reviewer and QA use their own checkouts; commits share code, while Comments and Artifacts share reports. Run baseline checks, implement the feature, add tests, and record commands, exit codes, and commits. Write requirements, changes, tests, and the Issue link into pr-body.md. If merge should close the Issue, include the actual Closes #number reference.
Save the returned URL. Check for an existing PR before retrying creation. See GitHub CLI PR creation for branch and body-file options.

​
4. Review, CI, and rework

Reviewer and QA first record the head SHA, then check out and inspect the PR:
Verify local HEAD matches the intended commit. QA runs tests there and checks CI logs and the tested revision. Include Integer.MAX_VALUE as a page to detect overflow in (page - 1) * size. Write concrete findings and acceptance requirements into review.md and request changes. The Leader reads findings and explicitly dispatches follow-up work; Service Inbox Request changes does not automatically rerun execution.
After a revision is pushed, record the new SHA and recheck affected work. --required lists only configured required checks; an empty set is not evidence that tests passed. Pending, cancelled, and missing checks do not establish success. See checks.

​
5. Approve, merge, and accept

The independent reviewer verifies the final commit and submits GitHub approval with evidence in the report:
See review options. A Workflow can wrap the Team with an approval gate, but Service tool approval and Issue acceptance do not substitute for GitHub review. When merge is authorized and the final commit meets required CI and repository review rules, the authorized executor merges. REVIEWED_SHA must be the inspected commit, not a newly fetched value used to skip review:
If a merge queue applies, observe actual completion. An accepted command is not a merged PR. New commits, conflicts, or unmet rules return the work to validation; do not bypass them with administrator options. See merge behavior. The Leader delivers the Issue, PR, commit, review, CI, merge status, and open items. Inspect them in Inbox. If scope ends at merge readiness, state that administrator merge remains outstanding.

​
Failure paths and event-driven extension

First complete the loop through explicit CI queries. Then add Automation: a bridge verifies GitHub events, correlates repository/PR/commit with existing work, and deduplicates delivery IDs. A generic webhook’s new task does not automatically resume the old Team; define correlation and subsequent dispatch explicitly. Keep delivery evidence, clean exercise branches and credentials, and inspect outstanding Host tasks. Include a real rework or recovery path in acceptance, not only a successful screenshot.