How a review works
The review boundary stays explicit from the first command to the final engineering decision.
- 1 Produce the diff Use Git or another trusted client to select the working-tree, staged, branch, or pull-request change you intend to review.
- 2 Submit the evidence Send the unified diff, its primary language, and only the surrounding source context the review needs.
- 3 Inspect focused findings Review concrete security, correctness, reliability, race-condition, and severe performance risks returned as P0–P2 findings.
- 4 Revise and review again Apply the changes you accept, create a new diff, and run another review. You remain responsible for the decision to ship.
Available now
The current service supports developer-initiated Personal Review through two interfaces.
- Hosted MCP over Streamable HTTP with OAuth and the review_diff tool.
- Synchronous REST review for provisioned, entitled organization members.
- Structured findings for 16 language identifiers with optional context and review controls.
Current boundaries
Caller-supplied evidence only
Enjoyable does not reach into your machine or repository. Your client decides what to include and constructs the diff before review.
- Connected pull-request execution and persisted review runs are still in development.
- The service does not fetch repositories, compare branches, or inspect untracked files.
- A review supports human judgment; it cannot guarantee that a change is safe or complete.