oncokb-ai-code-review

---

name: oncokb-ai-code-review description: Run an AI-assisted PR review that validates issue linkage, local quality gates, manageable scope, and review comments.

Scope

• Use for end-to-end AI code review on an existing PR.
• Use this skill when the user asks for an AI review workflow, not just a single lint/test command.
• Keep the review auditable: report commands run, outcomes, and the final PR URL.
• This skill does not create or update pull requests. Use oncokb-make-pull-request for PR creation/update.

Required skill chain

Follow this order and do not skip steps:

1. Confirm target PR context
   • oncokb-make-pull-request first if a PR does not exist yet.
2. (Optional Ask User First) Local validation (format, lint, tests)
3. Manageability and scope review
4. oncokb-database-review
5. oncokb-logging-review
6. oncokb-html-accessibility-reference
7. oncokb-datastar-review (when Datastar usage is present)
8. Repo-specific code-review skill discovery
9. PR review comments prefixed with [ai-generated]
10. oncokb-code-comments-standards
11. oncokb-test-planning-and-coverage

Workflow

1. Get the related GitHub issue first.

   • Start by invoking the oncokb-github-issues skill.
   • Ask for the issue associated with the change, or create/find it via that skill workflow.
   • Do not proceed to PR work without an issue link or issue ID.
   • Completion criterion: issue URL/ID is confirmed and ready to reference in the PR.

2. Run local quality gates.

   • Run all project formatting, linting, and test commands that apply to the changed code.
   • Discover commands from the project environment (for example package scripts, Make targets, Gradle/Maven tasks, or other repo-standard tooling).
   • If any command fails, stop and report failures before proceeding with PR review comments.
   • Completion criterion: formatting, lint, and tests all complete with no errors.

3. Check that the change is manageable.

   • Verify the change is atomic: one focused feature/fix/refactor and no unrelated scope.
   • Verify only relevant files are included for that purpose.
   • Measure diff size against soft limits:
     • under 500 changed lines of source code
     • under 20 changed source files
   • If soft limits are exceeded or scope is mixed, recommend a PR stack split plan.
   • Completion criterion: reviewer can clearly see either (a) manageable scope or (b) a concrete split recommendation.

4. Confirm target PR context.

   • Ask for the PR URL to review.
   • If a PR does not exist yet, stop this skill and hand off to oncokb-make-pull-request first.
   • Do not create or update PR metadata from this skill.
   • Completion criterion: PR URL is confirmed and accessible for review/commenting.

5. Review database access risks.

   • Invoke oncokb-database-review and assess changed DB access for N+1 query risks, SQL injection risks, and deterministic pagination ordering.
   • If paging exists, require ORDER BY to include a unique tie-breaker (for example id or another unique key).
   • Add [ai-generated] review comments for any blockers or high-value follow-ups from the database review.
   • Completion criterion: database-review findings are documented and actionable.

6. Review logging quality and severity.

   • Invoke oncokb-logging-review and assess changed logging for correct TRACE/DEBUG/INFO/WARN/ERROR/FATAL usage.
   • Require level labels on all changed application logs.
   • Ensure changed error/fatal events are logged and intentionally ignored errors are logged as WARN.
   • Add [ai-generated] review comments for blockers and high-value INFO suggestions from the logging review.
   • Completion criterion: logging-review findings are documented and actionable.

7. Review HTML accessibility basics.

   • Invoke oncokb-html-accessibility-reference and use its references to review changed HTML/UI markup.
   • Check semantic HTML usage, accessible form labeling, heading/landmark structure, keyboard access, and ARIA misuse.
   • Add [ai-generated] review comments for accessibility blockers or high-value follow-ups.
   • Completion criterion: accessibility findings are documented and actionable.

8. Review Datastar architecture and semantics (conditional).

   • If changed files contain Datastar usage (data-* Datastar attributes, @get/@post/... actions, Datastar SSE patch patterns, Datastar plugin code), invoke oncokb-datastar-review.
   • Use its Tao-based checks to assess state placement, patch strategy, signal usage, loading/optimistic behavior, and accessibility implications.
   • Add [ai-generated] review comments for Datastar blockers or high-value follow-ups.
   • Completion criterion: when Datastar usage exists, Datastar-review findings are documented and actionable.

9. Check for additional repo-specific code review skills.

   • Inspect the current repository for any additional skills intended for code review (for example under skills/ and referenced in local agent docs).
   • Identify skills not already covered by this chain that are applicable to the current PR.
   • Invoke each applicable additional review skill and capture actionable findings.
   • Add [ai-generated] review comments for blockers or high-value follow-ups from those skills.
   • Completion criterion: repo-specific applicable review skills are either run with findings recorded, or explicitly reported as none found.

10. Add AI review comments on the PR.

• Post review comments that begin with [ai-generated].
• Keep comments specific, actionable, and tied to files/lines or clear review concerns.
• Do not post vague praise-only comments.
• Completion criterion: PR contains useful [ai-generated] review comments or an explicit no-issues-found note.

11. Review code comments quality.

• Invoke oncokb-code-comments-standards and assess whether comments explain non-obvious logic, invariants, and decisions.
• Add [ai-generated] PR comments for missing or weak comments in non-trivial areas.
• Completion criterion: comment-quality findings are documented in the PR.

12. Review testing adequacy.

• Invoke oncokb-test-planning-and-coverage and assess whether tests are sufficient for changed behavior and risk.
• Add [ai-generated] PR comments for missing high-value tests or coverage gaps.
• Completion criterion: test-coverage findings are documented in the PR.

Output requirements

• Report:
  • issue reference used
  • formatting/lint/test commands run and outcomes
  • scope metrics (source lines changed, source files changed)
  • manageable vs needs-split decision
  • database review findings (N+1, injection, pagination determinism, and key follow-ups)
  • logging review findings (level correctness, label coverage, error/fatal observability, ignored-error WARN logging, and INFO suggestions)
  • HTML accessibility findings (semantic structure, labels, keyboard access, ARIA usage, and follow-ups)
  • Datastar review findings when applicable (Tao alignment, state placement, patch strategy, signal usage, and reliability checks)
  • additional repo-specific review skills found and findings (or explicit none-found)
  • PR URL
  • count and summary of [ai-generated] comments posted
• If work is blocked (permissions, failing checks, missing issue), report the exact blocker and the next command or action needed.

Quality bar

• Never claim a command passed unless it was actually run.
• Never perform PR review work without an issue reference and a target PR URL.
• Treat 500 lines and 20 source files as soft limits: recommend PR stacking when exceeded.
• Run oncokb-datastar-review whenever Datastar usage appears in changed code.
• Do not skip applicable repo-specific code review skills discovered in the current repository.
• Keep all automated review comments clearly marked with [ai-generated] at the start.