Oneport Review

The AI code reviewer that lives in your pull requests — reviews every PR line-by-line, proposes one-click fixes, briefs your reviewers, answers questions in-thread, and learns your team's standards.

What happens on every PR

Once the two workflow files are in your repo, every pull request gets:

1. An inline review — findings appear as per-line comments in the Files Changed tab, exactly where a human reviewer would put them. Security holes, logic bugs, performance traps, bad patterns — each explained in plain English with why it matters.
2. One-click fixes — when Oneport is confident in the exact repair, the comment carries a committable suggestion. Reviewer clicks Commit suggestion, done.
3. A briefing comment — a high-level summary of what the PR does, a per-file walkthrough table, and a Mermaid diagram of how the changed pieces interact. Updated in place on every push (never spams the timeline). Your human reviewers start oriented instead of cold.
4. A conversation partner — reply @oneport why is this a problem? under any finding and it answers in-thread, with the diff and full thread as context. Push back; if you're right, it concedes. If you're not, it shows you the failing case.
5. A memory — reply @oneport remember: never use naive datetimes and it commits the rule to .oneport/guidelines.md on the PR branch. Every future review enforces it. The reviewer gets more yours over time.
6. A merge gate — error/critical findings fail the check (severity thresholds configurable), so the red X does the arguing for you.

And it scales like a real reviewer:

• Incremental — pushed three more commits? Only those get re-reviewed (a hidden marker in the last review is the state; the PR is the database). --full forces a fresh look.
• No PR too big — oversized diffs split on file boundaries into multiple deep review passes, merged into one review. No token-limit faceplants, no shallow skims.
• Linter-fused — if ruff/bandit are installed, their findings feed the model as hints to confirm or reject: linter exhaustiveness plus LLM judgment.
• Whole-file vision — the model sees the full, line-numbered content of changed files, not just diff hunks, so findings account for surrounding code.
• ignore_paths that works — migrations/**, vendor/**, **/*.generated.py never reach the model (or your token bill).

0-BYOK — no API keys, ever. Reviews run on OnePort's own managed models and are metered against your account's token balance; you never bring or expose a model key. The diff/context assembly stays local — only the review prompt goes to the OnePort backend, nothing is trained on, nothing is retained. The full story fits on one page: PRIVACY.md.

---

Setup in 2 minutes (GitHub)

pip install oneport-review

1. Add your OnePort token as the ONEPORT_TOKEN repository secret (Settings → Secrets and variables → Actions). Get one at oneport.co.in → Console → API Tokens. No model API keys needed (0-BYOK).
2. Copy the two workflows from examples/workflows into .github/workflows/:
   • oneport-review.yml — review + fixes + briefing on every PR
   • oneport-chat.yml — @oneport replies and remember:

Open a PR. That's it.

CLI — review before anyone sees it

# 0-BYOK — no model API key. Get a token at https://www.oneport.co.in/console,
# then log in once:
onp account login <op_live_...>

oneport review --staged                                  # what you're about to commit
oneport review --head                                    # your last commit
oneport review src/auth.py                               # any file
oneport review https://github.com/org/repo/pull/42       # any PR, in your terminal
oneport review https://github.com/org/repo/pull/42 --post  # ...and post it as an inline review
oneport summarize https://github.com/org/repo/pull/42 --post  # post the briefing comment

Exit code 1 on error/critical findings by default, so every command drops straight into scripts and CI. Tune what blocks with --fail-on (see below).

Block bad commits before they exist

oneport install-hooks

Installs a git pre-commit hook that reviews staged changes and blocks the commit on blocking findings (ONEPORT_SKIP=1 git commit ... to bypass once). Using the pre-commit framework? A hook definition ships in .pre-commit-hooks.yaml.

---

Teach it your team's standards

Three ways, same result — rules land in .oneport/guidelines.md, version-controlled in your repo, enforced on every review like the built-in catalog:

# from the terminal
oneport learn "never use print() in library code, use logging"

# from a PR thread
@oneport remember: all public functions need docstrings with examples

<!-- or just edit .oneport/guidelines.md — it's plain markdown -->
- API handlers must validate ownership before any DB write

Built-in rules are configurable too — .oneportrc:

model: gemini-flash-latest

fail_on: error            # severity that BLOCKS CI (info | warning | error | critical)

rules:
  ignore: [OPR042]          # disable a rule
  severity:
    OPR020: critical        # N+1 queries block merges in this repo

output:
  format: inline            # inline | json | github | sarif
  min_severity: warning     # what to DISPLAY — never affects the exit code

oneport rules list shows the whole catalog: security (SQLi, hardcoded secrets, SSRF, path traversal, command injection...), performance (N+1, sync-in-async, unbounded queries...), logic (races, off-by-one, swallowed exceptions...), and architecture patterns.

Tune what blocks — --fail-on

--min-severity controls what's shown; --fail-on controls what fails CI. They're independent.

oneport review --head --fail-on critical   # only critical findings block; errors are advisory
oneport review --head --fail-on warning    # strict — warnings block too

Default is error (error + critical block), preserving prior behaviour.

Waivers — accept a finding on the record

Approve a specific finding without disabling the rule everywhere (which would also hide the next real instance). Waivers live in .oneport/review-waivers.yml:

waivers:
  - file: "src/legacy/*.py"    # glob, or a bare basename
    rule_id: OPR012            # optional — omit to waive every rule in that file
    category: security         # optional — waive a whole category in that file
    reason: "legacy module, deleted in Q3 — JIRA-1234"
    expires: "2026-12-31"      # optional — after this date the finding blocks again

A waived finding is still shown (marked [WAIVED]) and still travels into SARIF — as a suppressions entry, so GitHub Code Scanning shows it dismissed rather than dropping it — but it never counts toward the blocking (CI-fail) decision, at any --fail-on threshold. An expired waiver is ignored, so the finding silently re-blocks: an approval can't outlive its stated reason.

---

Output formats

Format	Use case
inline	Terminal — coloured, human-readable, shows suggested fixes
json	Scripting — includes a blocking field for CI decisions
github	GitHub Checks API annotation payloads
sarif	VS Code Problems panel, GitHub Code Scanning

oneport review file.py --format json | jq '.issues[] | select(.severity == "critical")'

Programmatic API

from oneport import review

result = review("path/to/file.py")
for issue in result.issues:
    print(f"[{issue.severity}] Line {issue.line}: {issue.message}")
    if issue.fix:
        print(f"  Committable fix:\n{issue.fix}")

VS Code

Search "Oneport Review" in the Extensions panel — findings appear as squiggles with hover explanations. SARIF output also plugs into any SARIF-aware editor tooling.

---

GitLab & Bitbucket

oneport review accepts GitLab MR and Bitbucket PR URLs today (terminal output). Inline comment posting for both is on the roadmap; GitHub is the deepest integration.

Privacy

Short version: your code goes to the Anthropic API on your key and nowhere else; the only local artifact is a cache you can wipe with oneport cache clear; telemetry is off unless you explicitly turn it on. Long version, written for your security team: PRIVACY.md.

Contributing

git clone https://github.com/Bitxn/oneport-review
cd oneport-review
pip install -e ".[dev]"
pytest

License

MIT © Oneport