What are quick reviews?
Quick reviews run in seconds inside your coding agent’s work loop and harness. Doomer generates hypotheses about the change and sends them back while the agent is still working.
Your coding agent is the reviewer. Doomer suggests where to look closer. The agent investigates, decides whether a concern is valid, and makes the final decision about how to act. A hypothesis is a question to resolve, not a verdict to obey.
How the skill works
Install the Doomer skill in your repository. Codex and Claude Code detect and use it automatically when you give them a normal coding task.
The skill installs the Doomer CLI and uses it to communicate with Doomer. You do not need to run review commands yourself. As the agent edits code, the skill sends the changes for a quick review. Doomer generates hypotheses in seconds and returns them to the agent in the same coding session.
Repeat while coding
- 1Agent edits code
- 2Skill uses the CLI — to send the changes
- 3Doomer generates — hypotheses in seconds
- 4Agent investigates — Accept · Reject · Defer
- 5CLI sends decisions — and explanations back
- 6Doomer records responses — and avoids repeats
Next edit → repeat with fresh concerns.
Or, after sending decisions: say “done” → end the turn → make a PR.
No account required does not mean no data is processed. After upload approval, Doomer receives source snapshots, task context, and the agent’s finding responses. Treat review links as private. Read about uploads, link access, and retention.
The agent decides what to do
A hypothesis points to code, describes a possible problem, and suggests a focused check. The agent reads the surrounding code, traces the behavior, or runs a test before deciding how to respond.
| Agent decision | What it means |
|---|---|
| Accept | The concern is valid. The agent acts on it and explains what it changed or verified. |
| Reject | The concern does not apply. The agent explains the evidence or context that rules it out. |
| Defer | The agent leaves the concern unresolved for now and explains why, including what still needs investigation. |
For example, Doomer might ask whether a lookup can return no record. The agent may add a missing check, find that the caller already guarantees a record, or defer until it can verify an external dependency. The decision belongs to the agent in each case.
The skill sends the agent’s decision and explanation back through the CLI. Doomer records that response. Accepting a hypothesis is not approval to merge, and rejecting one should be backed by an explanation.
See a review example
1. Doomer asks
Can this lookup return no record?
Check whether the handler reads the account’s name before handling a missing account.
2. Your agent investigates
“The lookup returns null for an unknown ID. I added a not-found response before reading the name, and the missing-account test passes.”
3. The response is recorded
Accepted · fixed
The review’s Feedback view shows the agent’s explanation. The agent submits the updated code for another review.
See hypotheses and agent responses
Open the quick review page linked from the coding session to see what Doomer suggested. The Feedback view shows the hypotheses and the agent’s recorded responses. Open an item to read what to check, the agent’s explanation, and its response status.
The page can also show Earlier agent responses, so you can follow decisions from previous revisions instead of losing that context as the code changes.
Many reviews during one coding session
It is normal for a coding session to generate many quick reviews. They happen as the agent works, not just once when it has finished.
The purpose is to question a design choice or assumption early, before the agent builds more code around it. A small correction now can prevent a larger rewrite later.
After sending its decisions back to Doomer, the agent can keep editing or say “done” and end the turn. It can then proceed to making a pull request. The loop can resume when later feedback leads to more edits.
Once the agent’s response is recorded, Doomer does not send the same suggestion back after the next edit. The next review focuses on fresh concerns as the change develops. Deferring a concern records that it remains unresolved; it does not turn it into a clean result.
Where deep reviews fit
Deep reviews use a separate generative model and review engine to investigate the change independently, in minutes. They can start before a PR exists and also act as a traditional reviewer on the PR. If PR feedback leads to more edits, quick reviews run inside the coding agent’s loop again.
Get started
Install the Doomer skill in the repository and commit its generated files to share it with your team. Then run your first quick review.