Case study: repository review and correction
User problem
A repository maintainer wants consistent review on every relevant pull request, with an optional correction pass that stays inside normal branch rules and CI.
Application shape
The GitHub App supplies a verified repository event and repository-scoped identity. Redgold binds that repository to a workspace, starts the configured reviewer, and posts the result against the current pull-request commit. When fixer mode is enabled, an eligible finding can produce a follow-up commit on the same pull-request branch.
| Artifact | Role |
|---|---|
| Signed webhook event | Repository and pull-request identity |
| Workspace binding | Enabled automation modes and execution ownership |
| Review task | Diff, repository instructions, and verification result |
| App review or commit | Repository-visible audit trail |
| Existing CI | Final evaluation under repository policy |
Request path
GitHub pull-request event
-> signature and installation verification
-> repository/workspace binding
-> scoped review task
-> App review or eligible branch correction
-> repository CI
Representative result
A successful cycle leaves evidence in familiar repository surfaces: a review associated with a commit, an optional follow-up commit, and the repository's required checks. Maintainers retain their existing merge policy.
Current status and limitation
This is a managed preview for configured repositories. Installing the App alone does not enable processing. Protected branches, missing permissions, ambiguous changes, or unavailable execution capacity can stop a fixer attempt.
Follow Connect GitHub review automation for the onboarding checklist.