om-code-review

Reviews diffs, branches, and PRs against correctness, security, and breaking-change standards with severity-ranked findings.

1|Updated Apr 23, 2026
One-click install
npx skills add https://github.com/tkogut/agents-os-core --skill om-code-review-tkogut
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: om-code-review
Source: https://github.com/tkogut/agents-os-core/tree/main/global_skills/om-code-review
Command: npx skills add https://github.com/tkogut/agents-os-core --skill om-code-review-tkogut

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve? Code reviews are inconsistent: reviewers miss security holes, breaking contract changes, and failing validation gates, and feedback arrives without clear severity or a merge verdict. This Skill standardizes the review of any diff, branch, or pull request against correctness, security, breaking-change, and quality rules, producing actionable findings and a mechanical approve/request-changes verdict. ## Core Features & Use Cases - Mandatory validation gate: Runs every configured validation command in order and reports per-command PASS/FAIL/NOT RUN results; any failure is a blocker finding. - Severity-ranked findings: Applies a built-in staff-engineer checklist plus repo-local checklists (CODE_REVIEW.md, BACKWARD_COMPATIBILITY.md, product-brief.md) and reports blocker/major/minor/nit findings with file, line, and concrete fixes. - Contract and security gates: Flags breaking changes to APIs, routes, events, CLI flags, and DB schemas without deprecation paths, plus missing permission checks, data-scoping leaks, and migration anomalies. - Use Case: Point it at PR #42 and receive a structured review report with a validation-gate table, severity-grouped findings, breaking-change consequences, test-coverage gaps, and a final verdict that callers like om-auto-review-pr use to drive labels and autofix loops. ## Quick Start Ask the agent to review the current branch's diff against the base branch and produce a severity-ranked review report with a merge verdict.

Frequently Asked Questions about om-code-review

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I review a pull request with an AI agent?▼

Provide a PR number, branch name, commit range, or nothing to default to the current branch's diff against the base branch. The skill fetches the diff via tracker operations, runs the configured validation gate, applies its checklist, and returns a severity-ranked report with an approve or request-changes verdict.

What does the code review checklist cover?▼

The checklist covers correctness and edge cases, security (auth, injection, secrets, data scoping), breaking changes across code, wire, and data contracts, tests, error handling, performance, concurrency, readability, scope discipline, dependency hygiene, observability, and docs. Each check maps to a typical severity.

Can I add repo-specific review rules to the checklist?▼

Yes. Set reviewChecklist in .ai/agentic.config.json or add CODE_REVIEW.md at the repo root; both are applied in addition to the built-in checklist, never replacing it. BACKWARD_COMPATIBILITY.md and product-brief.md are also enforced when present.

What makes the review verdict request changes instead of approve?▼

Any blocker finding forces request changes with no exceptions, and any major finding without a documented maintainer waiver does the same. A failing or unrun validation gate command also counts as a blocker, so approval requires all gates passing.

Does the review skill modify labels or claim issues on the tracker?▼

No. It is a read-only review engine that fetches the PR and diff but takes no claim and mutates no labels. Callers such as om-auto-review-pr and om-review-prs own the claim protocol, label transitions, and verdict submission.

Why does the review report NOT RUN for some validation commands?▼

NOT RUN means a configured command could not execute within the authorized scope, and the reason plus the action needed is recorded. An unexecuted command keeps the verdict at request changes until validation actually runs, since supplied test results do not satisfy the execution gate.