소스 정보
- 저장소
- openshift/cluster-capi-operator
- 최근 소스 활동
- 2026년 4월 29일 14:17
- 감지된 SKILL.md 언어
- 영어
- 스타
- 14
- 포크
- 75
설치 방법
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
소스 파일 검토
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
메뉴
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/openshift/cluster-capi-operator --skill deep-review명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
Use when the user wants to audit, update, or regenerate RBAC permissions for a controller or service account. Covers: adding new permissions after code changes, auditing a service account for least privilege, periodic RBAC reviews, or regenerating RBAC manifests after adding new CRD types or controllers. Trigger on any mention of "rbac" in the context of updating or reviewing permissions.
Use when auditing, reviewing, or refining cloud provider CredentialsRequest permissions in OpenShift. Use when asked to minimize IAM permissions, check for unused permissions, or verify a CredentialsRequest manifest against provider source code. Triggers on mentions of CredentialsRequest, IAM permissions audit, credential refinement, or cloud provider permission minimization.
Apply when writing, modifying, or reviewing test files (_test.go). Covers test level selection, assertion quality, BDD naming, and use of shared helpers.
SOC 직업 분류 기준
SKILL.md 표시 중
| name | deep-review |
| description | Run a two-pass parallel code review with synthesis |
| disable-model-invocation | false |
Run a two-pass code review of the changes described below.
Changes to review: $ARGUMENTS
Current branch: !git branch --show-current
Recent commits on this branch:
!git log --oneline -20
Before launching any agents, verify Gemini is available by running this smoke test using the Bash tool:
echo "Reply with exactly: OK" | gemini -p - 2>&1
If the command fails for any reason — binary not found, authentication error, configuration issue, network error, or unexpected output — Gemini is not available. In that case:
NOTE: Gemini is not available — the
geminiCLI is not working (not installed, not authenticated, or misconfigured). The Gemini review passes (agents 2 and 3) will be skipped. This review will use Claude-only analysis. Fix thegeminiCLI setup to enable multi-model review.
Before launching agents, assess the scope. If the changeset is large or spans distinct areas (e.g., framework code, platform-specific tests, migration logic), split the work across multiple agents by area rather than sending everything to one. Each agent should review a coherent subset.
Launch the following agents in parallel using the Agent tool, with run_in_background: true:
code-reviewer agent (subagent_type: code-reviewer) — Claude/Opus. Full code review:
gemini agent (subagent_type: gemini) — Gemini via CLI. Independent second opinion from a different model:
gemini agent (verifier) (subagent_type: gemini) — Second Gemini instance focused on verification:
If the changes include test files (_test.go, suite_test.go, or test helper files), ask the user whether to also launch a dedicated test quality reviewer. If yes, launch an additional agent:
subagent_type: code-reviewer) — test quality focus:
.claude/skills/test-standards/SKILL.md as the review checklistProvide all agents with sufficient context: commit range, relevant file paths, and what the feature does.
Wait for all agents to complete.
Once all agents have returned, synthesise their findings yourself (do NOT delegate this to a subagent). Analyse the sets of findings and:
Write the final review to .claude/reviews/review-$0.md, structured with sections that fit the findings. Use categories that match what was actually found rather than a fixed template. Common categories include:
Only include sections that have findings. Be specific — include file paths with line numbers and suggested diffs where applicable. Be concise — don't restate code that is already clear from the file path and line number.