code-review

โดย openshift

ตรวจสอบ pull request เพื่อดูคุณภาพโค้ด ความถูกต้อง และความสอดคล้องกับข้อกำหนดของโปรเจกต์ ใช้เมื่อผู้ใช้ขอให้ตรวจสอบ PR, ตรวจสอบโค้ด หรือตรวจสอบการเปลี่ยนแปลงใน...

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-docs
openshift
ค้นหาและอ่านเอกสารประกอบ OpenShift Container Platform ในรูปแบบ markdown ใช้เมื่อผู้ใช้ถามเกี่ยวกับฟีเจอร์ การกำหนดค่า การติดตั้ง… ของ OpenShift
triage-leaked-infra
openshift
ประเมินว่า AWS VPC หรือชุดโครงสร้างพื้นฐานจาก HyperShift CI ปลอดภัยที่จะลบหรือไม่ ใช้เมื่อผู้ใช้วาง cleanleaked output และถามว่า 'ลบอันนี้ได้ไหม?', 'มัน...
openshift-expert
openshift
ผู้เชี่ยวชาญด้านแพลตฟอร์ม OpenShift และ Kubernetes ที่มีความรู้เชิงลึกเกี่ยวกับสถาปัตยกรรมคลัสเตอร์ โอเปอเรเตอร์ เครือข่าย พื้นที่จัดเก็บข้อมูล การแก้ไขปัญหา และไปป์ไลน์ CI/CD ใช้…
Konflux Archived PipelineRuns
openshift
เข้าถึง Konflux PipelineRuns, TaskRuns และบันทึกพ็อดที่ถูกเก็บถาวรผ่าน KubeArchive ใช้โดยอัตโนมัติเมื่อตรวจสอบผลลัพธ์ของ Konflux PipelineRun หรือสืบสวน...
backport
openshift
ย้อนกลับคอมมิตหรือ PR จาก main ไปยัง release branch ใช้เมื่อผู้ใช้ขอให้ย้อนกลับ, cherry-pick, หรือพอร์ตการเปลี่ยนแปลงระหว่าง branch หรือเมื่อกำลังแก้ไข…
rebase
openshift
รีเบสสาขาปัจจุบันไปยังสาขาหลัก แก้ไขข้อขัดแย้งทั้งหมด และตรวจสอบว่า lint, i18n และ build ผ่าน ใช้เมื่อผู้ใช้ขอให้รีเบส อัปเดต หรือซิงค์…
Build CPO Image
openshift
สร้างและพุชอิมเมจคอนเทนเนอร์ control-plane-operator ใช้โดยอัตโนมัติเมื่อทดสอบการเปลี่ยนแปลง CPO ที่ต้องปรับใช้กับคลัสเตอร์ที่ใช้งานจริง
find-complexity
openshift
ค้นหาฟังก์ชันและเมธอดที่มีความซับซ้อนของไซโคลเมติกสูง ความยาวมากเกินไป หรือมีพารามิเตอร์มากเกินไป ใช้เมื่อผู้ใช้ขอให้ค้นหาโค้ดที่ซับซ้อน ความซับซ้อน…