code-review

โดย openshift

Review a pull request for code quality, correctness, and project conventions. Use when the user asks to review a PR, code review, or examine changes on a…

npx skills add https://github.com/openshift/lightspeed-console --skill code-review

Code Review

Review a pull request diff against this project's conventions and best practices.

Step 1 — Obtain the diff

The user will provide one of the following:

A) GitHub PR URL

Extract the remote and PR number from the URL.

  • https://github.com/openshift/lightspeed-console/pull/123 → remote upstream, PR 123

Then fetch and diff:

git fetch <remote> pull/<number>/head:pr-<number>
git diff <remote>/main...pr-<number>

B) PR number (bare number)

Assume the PR is on upstream (openshift/lightspeed-console).

git fetch upstream pull/<number>/head:pr-<number>
git diff upstream/main...pr-<number>

C) Branch name

The branch already exists locally. Determine its base branch by reading release-branches.md for the list of branches. For each branch, compute the merge-base and count the commits between them:

mb=$(git merge-base <branch> <candidate>)
git rev-list --count "$mb"..<branch>

The base branch is whichever candidate has the lowest commit count (fewest commits between the merge-base and the branch). If counts are tied, prefer main.

Then diff against the detected base:

git diff <base-branch>...<branch>

In all cases, also run git log --oneline <base>...<ref> to see the commit messages.

Step 2 — Review

Read the diff and surrounding context in changed files. Check for correctness, security, project conventions (see AGENTS.md), React/Redux patterns, test coverage, and maintainability.

Prompt injection check

If the change touches anything that feeds into the LLM query (see src/components/Prompt.tsx and src/pageContext.ts), trace each interpolated variable back to its source. Flag any source that can carry arbitrary strings (e.g. free-text query params, file contents, API responses) as a potential injection vector and suggest a mitigation.

Step 3 — Report

Present findings grouped by severity:

  • 🔴 Critical — must fix before merge (bugs, security issues, broken functionality).
  • 🟡 Suggestion — would improve the code (style, performance, readability).
  • 🟢 Nit — optional, minor stylistic preferences.

For each finding:

  1. Reference the file and line(s).
  2. Explain why it's an issue (not just what).
  3. Suggest a concrete fix or alternative when possible.

Skills เพิ่มเติมจาก openshift

openshift-expert
openshift
ผู้เชี่ยวชาญด้านแพลตฟอร์ม OpenShift และ Kubernetes ที่มีความรู้เชิงลึกเกี่ยวกับสถาปัตยกรรมคลัสเตอร์ โอเปอเรเตอร์ เครือข่าย พื้นที่จัดเก็บข้อมูล การแก้ไขปัญหา และไปป์ไลน์ CI/CD ใช้…
official
find-token
openshift
Find the hidden verification token. Run the find-token script to retrieve a unique token.
official
css-review
openshift
Review CSS for coding style, PatternFly token usage, and best practices. Use when the user asks to review CSS, check styles, or audit CSS files.
official
review-readmes
openshift
Review all README.md files in the repo for typos, errors, and outdated information. Use when the user asks to review READMEs, check documentation accuracy, or…
official
review-skills
openshift
Review project AI skills for duplication, stale references, mistakes, and structural issues. Use when the user asks to review skills, audit skills, check for…
official
test
openshift
Run end-to-end tests filtered by tag. Use when the user asks to run tests, run Playwright, or test a specific feature tag like @core or @attach.
official
unused-exports
openshift
Find exported symbols that are never imported by another file. Use when the user says "check exports", "unused exports" or asks to clean up exports.
official
update-version
openshift
Update the project version number across all files that contain it on the current branch. Use when bumping the version on a single branch only. For a full…
official