code-review

작성자: openshift

풀 리퀘스트의 코드 품질, 정확성, 프로젝트 규칙을 검토합니다. 사용자가 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.

openshift의 다른 스킬

openshift-docs
openshift
OpenShift Container Platform 문서를 마크다운 형식으로 검색하고 읽습니다. 사용자가 OpenShift 기능, 구성, 설치 등에 대해 질문할 때 사용합니다.
triage-leaked-infra
openshift
AWS VPC 또는 HyperShift CI의 인프라 세트가 삭제해도 안전한지 평가합니다. 사용자가 cleanleaked 출력을 붙여넣고 '이거 삭제해도 되나요?', '이거...'라고 물을 때 사용합니다.
openshift-expert
openshift
OpenShift 플랫폼 및 Kubernetes 전문가로, 클러스터 아키텍처, 오퍼레이터, 네트워킹, 스토리지, 문제 해결 및 CI/CD 파이프라인에 대한 깊은 지식을 보유하고 있습니다. 사용…
Konflux Archived PipelineRuns
openshift
KubeArchive를 통해 보관된 Konflux PipelineRun, TaskRun 및 파드 로그에 접근합니다. Konflux PipelineRun 결과를 확인하거나 조사할 때 자동으로 적용됩니다.
backport
openshift
메인 브랜치에서 릴리스 브랜치로 커밋이나 PR을 백포트합니다. 사용자가 브랜치 간 변경 사항을 백포트, 체리픽, 포팅하거나 해결을 요청할 때 사용합니다.
rebase
openshift
현재 브랜치를 기본 브랜치 위로 리베이스하고, 모든 충돌을 해결한 뒤 린트, i18n, 빌드가 통과하는지 확인합니다. 사용자가 리베이스, 업데이트, 또는 동기화를 요청할 때 사용합니다…
Build CPO Image
openshift
컨트롤 플레인 오퍼레이터 컨테이너 이미지를 빌드하고 푸시합니다. 라이브 클러스터에 배포가 필요한 CPO 변경 사항을 테스트할 때 자동으로 적용됩니다.
find-complexity
openshift
순환 복잡도가 높거나, 길이가 지나치게 길거나, 매개변수가 너무 많은 함수와 메서드를 찾습니다. 사용자가 복잡한 코드나 복잡도를 찾아 달라고 요청할 때 사용하세요.