open-code-review-repo-reviewer

name

open-code-review-repo-reviewer

description

Review pull requests, commits, branch ranges, or working-tree changes for the JustasMonkev/open-code-review repository. Use when asked to code review changes touching the Open Code Review Go CLI, review agent, diff parsing, rule matching, LLM clients, config/env handling, session viewer, telemetry, npm wrapper, release scripts, docs, or CI. Produces findings-first review output grounded in changed lines, project conventions, and deterministic validation.

Open Code Review Repo Reviewer

Purpose

Review changes in JustasMonkev/open-code-review, a Go 1.25 CLI named ocr with an npm wrapper and optional AI review flow. Optimize for defects, regressions, security/privacy risks, test gaps, and repo-specific contract drift.

Resolve The Target

• If the user provides JustasMonkev/o%7B or JustasMonkev/o{, treat it as a likely malformed repo link and try JustasMonkev/open-code-review. State this assumption in the review.
• If the repository still cannot be resolved, ask for the correct locator before reviewing.
• Identify the requested target: GitHub PR, commit, branch range, staged/unstaged workspace, or a supplied patch.
• Read the current README.md, CONTRIBUTING.md, go.mod, package.json, and any repo-local AGENTS.md, .opencodereview/rule.json, or PR description before judging the diff.
• Do not modify code, config, labels, comments, or PR state unless the user explicitly asks for fixes or GitHub mutations.

Review Workflow

1. Establish scope. Fetch PR metadata, changed filenames, and patch content, or run git status plus the relevant git diff. Summarize the behavioral intent in one to three bullets for yourself.
2. Confirm coverage. Check every changed file unless it is generated, binary, vendored, or explicitly out of scope. Do not claim full review coverage until this is verified.
3. Run deterministic checks when a local checkout is available and the change risk warrants it:
   • Formatting check for changed Go files: gofmt -l <files>; do not run mutating go fmt during review-only work.
   • Static checks: go vet ./...
   • Repo checks from CONTRIBUTING.md: make test and make build
4. Optionally run the repo's own OCR tool as an additional reviewer when ocr is installed and ocr llm test passes. Use ocr review --preview to confirm files first, then prefer ocr review --audience agent --format json with --from/--to or --commit as appropriate. Treat OCR output as a lead list, not proof.
5. Manually validate each plausible issue by reading surrounding code and following the data flow. Use rg to inspect related symbols, configuration, tests, and documentation.
6. Filter out style-only comments unless they violate explicit repo conventions or hide a concrete maintainability, reliability, or correctness problem.

Repo-Specific Checklist

• CLI contract: command flags, aliases, defaults, output formats, and examples must match README, skill docs, and implementation.
• Config and secrets: env vars must have the documented precedence, config writes must not expose tokens, and logs/telemetry must avoid leaking prompts or credentials by default.
• Diff selection: workspace, ref-range, single-commit, untracked-file, binary/generated-file, and large-diff behavior must be deterministic and documented.
• Rule matching: custom --rule, project .opencodereview/rule.json, global rules, built-ins, first-match-wins, doublestar, and brace expansion must behave predictably.
• Review positioning: line-level comments must map to real changed lines; failed positioning must be handled without misleading file/line claims.
• Agent/tool loop: prompts, tool definitions, max tool rounds, concurrency, timeouts, and token limits must not create runaway loops or miss high-risk files.
• LLM clients: Anthropic and OpenAI-compatible flows need correct request shape, retries/backoff, timeouts, error reporting, and model/config handling.
• Sessions, viewer, and telemetry: JSONL sessions and the viewer can contain sensitive prompts; Host allowlists, loopback binding, and telemetry.content_logging defaults matter.
• NPM wrapper and releases: postinstall scripts, OS/arch mapping, checksums, binary permissions, Node engine support, and release URL patterns must be reviewed as supply-chain surfaces.
• Tests and docs: behavior changes require focused tests; user-facing behavior changes require README, skill, command, or contributing-doc updates.

Finding Standard

• Lead with findings. Do not put summary before actionable issues.
• Report only issues that can plausibly affect correctness, security, privacy, reliability, maintainability, or project contracts.
• Ground each finding in a concrete file and line. If the exact line is unavailable, name the smallest affected function, command, or config path.
• Explain impact in one sentence and give the smallest useful fix direction. Avoid broad rewrites unless the bug requires them.
• Mark severity:
  • P0: exploitable or release-blocking breakage.
  • P1: likely bug, security/privacy issue, data loss, broken CLI contract, or high-confidence test failure.
  • P2: meaningful regression risk, missing validation, missing tests for changed behavior, or maintainability issue with clear future cost.
  • P3: minor issue worth fixing but not blocking; include sparingly.
• If no actionable findings remain, say that clearly and mention any residual risk or tests not run.

Output Format

Use this structure:

## Findings
- [P1] Title - path/to/file.go:123
  Impact and fix direction.

## Open Questions
- Question or assumption, if any.

## Verification
- Command or check: result

If there are no findings:

## Findings
No actionable issues found.

## Verification
- Command or check: result