Anatomy of a Review
Read an Angada check, review status, finding, evidence, and what to do next.
An Angada review appears on a GitHub pull request as a check and a result. The check shows whether the review is running or finished; the status summarizes Angada's review outcome. Findings explain issues Angada identified and point to the code it reviewed.
Check and status
Open the pull request's Checks area to follow the Angada check. While it runs, the check is in progress. When it finishes, read the review status in Angada to understand the result. A completed check does not mean the pull request is clear, and the review status is not a GitHub approval or request for changes.
The Angada check is running. Wait for it to finish before interpreting the review result.
Angada displays one of these review statuses:
| Status | Meaning |
|---|---|
| Not reviewed | Angada has not completed a review for this pull request. |
| Reviewing… | A review is in progress. |
| Reviewed | Angada completed the review with a clear verdict. Read the findings for details. |
| Reviewed (degraded quality) | Angada completed the review, but recommends a closer human look. |
| Review failed | The review did not complete successfully. See Troubleshoot a review. |
| Skipped | Angada did not run a review because a trigger, setting, or eligibility rule prevented it. See Limits and caps. |
Read a finding
A finding describes a potential issue. Its fields give you the claim, its assessed risk, and the code context behind it. The report can include:
| Field | What it tells you |
|---|---|
| Title | A short description of the potential issue. |
| Severity | The assessed impact of the issue. |
| Confidence | How strongly the evidence supports the finding. |
| Claim | Why Angada considers the code an issue. |
| Evidence | The file and line range associated with the finding, anchored to the commit reviewed. |
| Fix instruction | A suggested direction for addressing the issue. |
An inline comment can be read in this order:
[Finding title] · [Severity] · [Confidence]
[Claim explaining the potential issue.]
Evidence: [file and line range at the reviewed commit]
Suggested fix: [direction for addressing the issue]
This is a field placeholder, not an example finding. The exact fields and comment content depend on the review. Workspace settings control which findings are posted inline; see Review settings for the severity floor.
Follow up
Use the evidence to inspect the affected code, then decide whether to change it or leave it as is. If you push a change, Angada starts a new review after a 90-second delay. Findings refer to the commit Angada reviewed; the next review updates the current result and matching comments. See Re-runs and continuity for what carries forward.
Next steps
- Review settings explains the severity floor and other review controls.
- Limits and caps explains why a review may be skipped.
- Troubleshoot a review helps diagnose a skipped or failed review.
- Issue tracker integration explains how linked requirements add context to a review.