A maintainer assigns a small documentation-and-test issue to a coding agent while continuing to work on another branch. The agent can inspect the repository, propose code changes, run supported checks, and prepare a pull request for review. This arrangement is different from allowing a local IDE agent to edit the maintainer’s working tree directly. The cloud workflow creates an explicit branch and review artifact, but it also raises questions about repository permissions, available tools, network access, untrusted issue text, and what counts as a completed task.<\/p>\n
GitHub’s cloud-agent documentation<\/a> distinguishes an autonomous task running in a managed environment from an IDE agent acting locally. The current GH-300 guide includes agent sessions, task delegation, and Copilot features around pull requests. Candidates should know the handoff and review contract, not assume that every environment gives agents identical privileges or that every suggested change is safe to merge.<\/p>\n A good delegated issue names the observed problem, the exact behavior expected after a fix, and the tests or examples that determine completion. \u201cImprove error handling\u201d is too vague: it might invite broad changes across transport, monitoring, and user messages. \u201cReturn a specific validation response when the invoice reference is missing, without changing successful requests\u201d offers a bounded target that another reviewer can verify.<\/p>\n Include protected boundaries, such as avoiding schema migrations or secret-bearing configuration. Define whether a task may modify tests, documentation, dependencies, or CI files. Clear scope lets the agent focus; it also helps the reviewer notice when an unrelated change appears in the diff.<\/p>\n A cloud agent typically works against repository state in a separate execution context and prepares branch changes for review. A reviewer should inspect which commit was used as the starting point, which files changed, what commands ran, and whether the proposed patch remains compatible with the latest target branch. If the repository evolved while the agent worked, the patch may require rebasing or additional testing.<\/p>\n The pull request is the delivery artifact, not proof that the issue is solved. Treat generated summaries as navigation, then inspect the actual diff, test output, and business behavior. Human approval and repository branch protection remain meaningful even when an agent wrote all the code. The Copilot code-review discipline<\/a> addresses the independent review step.<\/p>\n A coding agent may use repository instructions, issue details, relevant files, and permitted tools. Not all repository text is trustworthy instruction. A malicious comment, issue body, or dependency README could try to redirect the agent toward releasing tokens or disabling checks. Review external inputs and configure tools so lower-trust content cannot silently authorize high-impact actions.<\/p>\nDefine the issue as a verifiable contract<\/h2>\n
Understand the repository branch and pull request lifecycle<\/h2>\n
Give agent sessions the minimum useful context<\/h2>\n