Reading a review
A Codzee review has a few parts: comments on your code, one summary comment, and a check. Here's what each one tells you.
Comments on your code
- What kind of problem, and how serious. Bug, security or performance, and Critical, Major or Minor.
- What goes wrong and why it matters, in a few sentences.
- A fix you can apply in one click, when it's small. Bigger fixes come with a prompt for your coding assistant.
Codzee comments on the exact lines with a problem. Each comment says what goes wrong and why it matters, in a few sentences. It starts with what kind of problem it is (bug, security or performance) and how serious it is.
- Only what it's sure about. Every finding is checked a second time before it's posted. Guesses are left out.
- Up to 10 comments per review. Anything more goes in the summary comment, so nothing is lost. A Critical finding always gets its own comment.
- No repeats. If Codzee already raised something, it won't raise it again.
Some comments carry an extra label: Test gap (a test is missing or checks the wrong thing), Hardening (not broken, but easy to make safer) or Pre-existing (the problem was there before this pull request).
How serious is it?
| Severity | What it means | What to do |
|---|---|---|
| 🔺 Critical | Could lose money, leak or damage someone's data, let someone get past login or permissions, or corrupt stored data. | Fix before merging. |
| 🔶 Major | Something a user will hit in normal use, a race under ordinary load, or a test that hides a real bug. | Worth fixing in this pull request. |
| 🟡 Minor | Edge cases, robustness, confusing names, clarity. | Worth fixing, not worth blocking a merge. |
The icons have different shapes, not just colours, so they're easy to tell apart.
Fixes you can apply
- Small fixes (up to 15 lines) come as a GitHub suggestion. Click Commit suggestion to apply it.
- Bigger fixes come with a Fix with AI prompt. Copy it into your coding assistant and it has everything it needs to make the change.
The summary comment
Codzee keeps one summary comment on each pull request and updates it after every review. At the top is the verdict:
- ⛔ Blocked: something must be fixed before merging.
- 🔶 Changes requested: there are findings worth fixing.
- ✅ Passed with findings: only small things are open.
- ✅ Approved: nothing open.
Below that is a table of every finding with how sure Codzee is (Confirmed, Likely or Unconfirmed), a list of nice-to-haves, what's already been fixed, and a suggested reviewer. If another open pull request changes the same lines, the summary warns you about a likely merge conflict.
Summary in the PR description
Codzee adds a short Summary by Codzee to the pull request description: a plain-English overview and a few bullet points, so reviewers know what the change does before they read it. Your own text is never changed, and the summary is updated when the code changes.
Size labels
Codzee labels each pull request by how much there is to review, from size:XS (under 10 lines) to size:XXL (1,000 lines or more). Lockfiles and generated files don't count. You can turn labels off in Settings.
When you fix something
After each push, Codzee checks its earlier findings against the new code. Fixed ones are marked ✅ Fixed and their conversations are resolved for you.
If you fix things in a follow-up pull request, mention the original one (for example #12) in the description. Codzee checks the new pull request against the old one's open findings and links the fixes.
Test coverage
If your GitHub Actions workflow uploads a coverage report (lcov, Cobertura, JaCoCo or Istanbul), the summary shows how many of the changed lines your tests run, with links to the lines they miss. Codzee reads the report your CI already makes; it never runs your code.
Can't find what you need? Email support@codzee.io and we'll help.
1 🔺 Bug | Critical
2 The charge is worked out again from the room rate and leaves out tax, so the guest pays a different amount from the invoice they were shown.
- const charge = rates.compute(booking);+ const charge = invoice.total;