Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Idea: agentic review engine with OpenCode

Open
  • Is something wrong?
#120 6 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
github, typescript
Domain
backend, devtools

Research direction

Read the design draft in issue #120 and review the results of spike #85 before proposing implementation. The issue names no source files or tests; trace the runner’s engine interface, repository preparation, finding state, and Runs page entry points. Done means the spike answers whether the engine is worthwhile and the open design questions have decisions, since implementation is out of scope.

Written by the indexing model from the issue text.

Description

area: runner needs decision type: feature

Idea

Offer an agentic review engine next to PR-Agent, built on OpenCode and selectable per project. PR-Agent makes one model call over the prepared diff; an agentic engine reads files outside the diff, follows references and searches the code before it writes the review.

OpenCode instead of Claude Code: it is MIT licensed (compatible with Apache-2.0, can ship in the runner image), works with any provider the AI SDK supports (OpenRouter, Anthropic, OpenAI, DeepSeek, local models, so BYOK keeps working), and runs headless (opencode run or a server with an HTTP API; exact flags to be confirmed in the spike #85).

Why

On our own recent pull requests the single-call review missed defects that only show when reading code outside the diff (stale docs elsewhere, tests that pass for the wrong reason) and reported findings that the missing context would have ruled out. An agentic engine closes that gap at a higher cost per review.

Design draft

Engine interface in the runner. ReviewEngine.run(job) -> { summary, findings[], resolved[], usage }. PR-Agent becomes one adapter, OpenCode a second; the engine is a project setting.

Repository checkout. The agent needs the code on disk: GitHub's code search only covers the default branch, and reading file by file through the API is slow and eats the installation's rate limit. A minimal checkout of the PR head is enough:

git init && git fetch --depth=1 --filter=blob:limit=1m origin <head-sha> && git checkout FETCH_HEAD

One commit, no history, large binaries skipped. The diff against the base comes from the API as today and is handed to the agent as a file. Later steps if needed: a per-worker cache (bare repository per repo plus git worktree add, cache key includes the installation so tenants never share data, size-bounded with eviction) and sparse checkout for monorepos; above a size limit the job falls back to PR-Agent.

The runner prepares, the agent only reads.

  • The runner clones with the installation token and removes the credentials from .git/config; the agent process never sees the token.
  • The runner posts the comment. The agent returns structured JSON (findings with file, line, severity, body). This needs an engine-neutral finding state to keep the persistent comment and "Resolved findings" working (today PR-Agent owns the pr-agent-review-state format).

Permissions. OpenCode runs with edits denied, web fetch denied and the shell denied except a list of read-only commands (rg, ls, git diff, git show). Repository content is untrusted: no npm install, no running tests (that would execute foreign code).

Prompt injection. Defence in layers: no shell beyond the allow list, no web access, network egress only to the model API (#82). The LLM key lives only in the OpenCode process.

Limits. Maximum steps, a wall-clock limit enforced by the runner (it kills the process), a cost budget per review; token usage and cost show on the Runs page.

Re-review after a push. The agent gets the previous findings plus the diff since the last reviewed commit, decides what is resolved and looks for new problems in the new code only.

Expected cost and footprint

Roughly 5 to 20 times the tokens of one PR-Agent call and minutes instead of seconds per review (cents per review with a cheap model). A larger runner image (OpenCode binary) and more memory per job; the current 2 GB for three parallel jobs would be tight.

Open questions

  • Results of the spike #85: quality, false positives, cost and runtime against PR-Agent.
  • Finding state format and how existing PR-Agent comments migrate when a project switches engines.
  • Default limits (steps, time, cost) and how they are configured per workspace.

Out of scope for now

Implementation. This issue holds the design until #85 has answered whether it is worth it.

Dominant language
TypeScript
Stars
0
Forks
1
Avg merge
1h 18m
Merged PRs (30d)
186

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from ExpidetGames/code-reviewer

All issues in ExpidetGames/code-reviewer

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.