oncokb-ai-code-review

The full skill.

Original instructions from the publisher’s SKILL.md

## 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.