1. Choose a repository and a small first change
Start with a repository you can authorize for CodePeel. Use a small pull request whose intended behavior you understand. This makes it easier to compare the feedback with the actual change before applying the workflow broadly.
Follow the GitHub quickstart to sign in, install the app and select repositories. Read code handling before granting access to sensitive code.
2. Give the review useful context
Keep the pull request focused. Explain what changed, why it changed and how it was tested. Include relevant constraints, such as backward compatibility or a permission boundary that must remain intact.
For example: “Restrict invoice reads to members of the invoice account. Tests cover same-account access, cross-account rejection and unauthenticated requests.” This makes the expected behavior clearer than “fix invoice endpoint.”
3. Inspect findings in the pull request
Read each finding as a claim to verify. Follow the code path, confirm that the reported condition is reachable, and judge the effect on your users. Prioritize security boundaries, data loss and broken behavior over cosmetic changes.
Use review chat when you need clarification. A plausible explanation is not proof: confirm it against the implementation and tests.
4. Validate suggested fixes
Inspect the generated change before applying it. Check its assumptions, surrounding behavior and error handling. Add a regression test for the original problem where practical, then run the checks relevant to the changed code.
See suggested fixes and auto-fix for the available workflows. Do not merge a generated patch solely because the review tool proposed it.
5. Make merge requirements explicit
A posted review and an enforced merge requirement are different things. If you want to require a CodePeel status, configure pre-merge checks and the corresponding GitHub branch protection or ruleset. Confirm the actual status name and behavior in your repository before making it required.
Keep your existing test checks and human approval requirements. Decide how your team handles delayed or unavailable automated reviews; do not assume that no feedback means a successful review.
6. Check the workflow after rollout
Confirm that reviews are arriving for the intended changes, valid issues receive attention and noise is manageable. Use repository configuration to tune supported preferences. For teams, check membership and shared usage and the review allowance guide.
If results do not appear, check installation access, review status and available allowance. Collect the repository, pull request and approximate review time when requesting support; do not include access tokens.
Next: Review AI-generated code, or compare plans.