Menu
PR 리뷰 결과의 조치 필요 항목을 파싱하여 리스트로 보여주고, 사용자가 선택한 항목을 수정하는 스킬입니다. 이 스킬은 "/review-action", "/review-action
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
jh_kim dev 계정(dev Keycloak)으로 E2E API 테스트를 수행하는 스킬입니다. 로컬 main 빌드 API + dev DB + dev Keycloak PKCE 토큰 조합으로, dev API 서버에 아직 배포되지 않은 머지 코드를 실데이터 환경에서 검증할 때 사용합니다. "/e2e-test-dev", "dev 계정으로 E2E", "jh_kim으로 API 테스트", "dev DB로 E2E 테스트" 등을 요청할 때 사용됩니다. (로컬 Docker Keycloak 기반 테스트는 e2e-test 스킬 사용)
plan-master(기획용 FE 코드 + docs/specs 기획서)와 bitda-back(구현된 BE 코드) 사이의 갭을 분석하여 누락된 기능·API·정책을 GitHub 이슈로 자동 생성하는 스킬입니다. 기획서→이슈 전달 과정에서 발생하는 누락을 방지하기 위해 FE 코드를 1차 소스로 사용합니다. "/gap-analyze", "/gap-analyze BOM", "/gap-analyze production" 등을 요청할 때 사용됩니다.
plan-master FE 코드만을 유일한 1차 소스로(기획서 .md 배제) 멀티팀 에이전트가 BE가 보장해야 할 비즈니스 로직과 FE 작업에 필요한 API 항목을 도출하고, 총괄 에이전트가 bitda-back BE 구현과 실측 대조하여 누락 갭을 발굴, 직렬 verifier로 확정한 뒤 GitHub 이슈로 생성하는 스킬입니다. gap-analyze의 변종으로, 기획서가 구현완료를 선언해 갭을 가리는 오염을 제거하기 위해 기획서를 의도적으로 보지 않습니다. /gap-fe-code 생산현황, 기획서 빼고 FE 코드로 갭 분석, FE 코드만 보고 누락 API 이슈 만들어 등을 요청할 때 사용됩니다.
실제 API 서버(8080 포트)를 실행하고 Keycloak OAuth 인증을 통해 E2E API 테스트를 수행하는 스킬입니다. 테스트 결과와 요청/응답을 docs/e2e-test/{test}/ 디렉토리에 markdown 형식으로 기록합니다. 이 스킬은 다음 상황에서 사용됩니다: - 특정 API의 실제 동작을 테스트하고 싶을 때 - API 변경 후 실제 환경에서 검증이 필요할 때 - 사용자가 "E2E 테스트", "API 테스트", "/e2e-test" 등을 요청할 때
Creates phase-based feature plans with quality gates and incremental delivery structure. Use when planning features, organizing work, breaking down tasks, creating roadmaps, or structuring development strategy. Keywords: plan, planning, phases, breakdown, strategy, roadmap, organize, structure, outline.
Swagger 스냅샷(api-docs.json)과 코드베이스를 기반으로 Notion API 맵핑 DB에 API 문서를 등록하고 상세 페이지를 작성하는 스킬입니다. (notion-api.py REST wrapper 사용 버전) 이 스킬은 다음 상황에서 사용됩니다: - 특정 API를 Notion에 문서화할 때 (MCP 비활성화 환경) - mcp__notion__* 도구 deprecated/불안정한 경우 - 사용자가 "api 노션 등록 (api 모드)", "/api-to-notion-api" 등을 요청할 때
| name | review-action |
| description | PR 리뷰 결과의 조치 필요 항목을 파싱하여 리스트로 보여주고, 사용자가 선택한 항목을 수정하는 스킬입니다. 이 스킬은 "/review-action", "/review-action |
PR 리뷰 결과(pr-review 스킬로 생성된 댓글)에서 조치 필요 항목 테이블을 파싱하여
사용자에게 선택지를 제공하고, 선택된 항목을 수정한다.
PR 번호를 다음 우선순위로 결정한다:
/review-action #123 → #123gh pr view --json number -q '.number'
gh pr view {pr-number} -R invigoworks/bitda-back --json comments -q '.comments[].body'
가장 최근의 ## 🔍 PR 리뷰 결과 댓글을 찾는다.
리뷰 댓글에서 ### 📋 조치 필요 항목 섹션의 테이블을 파싱한다:
| # | 심각도 | 분류 | 위치 | 내용 | 상태 | 비고 |
|---|--------|------|------|------|------|------|
| 1 | 심각 | 코드품질 | `파일:라인` | 설명 | ⬜ | N차 신규 |
파싱 결과:
#: 항목 번호심각도: 심각/중간/낮음분류: 코드품질, 테스트, 백엔드아키텍처, 아키텍처일관성위치: 파일:라인 형식내용: 지적 내용상태: ⬜ (미조치) / ✅ (조치완료)⬜ 상태인 항목만 목록에 포함한다.
AskUserQuestion 도구를 사용하여 사용자에게 선택지를 제공한다.
표시 형식:
📋 조치 필요 항목 ({N}건)
조치할 항목을 선택하세요.
옵션 구성:
multiSelect: true로 여러 항목 동시 선택 가능옵션 예시:
옵션 1: "모두 조치 ({N}건)" - "미조치 항목 전체를 순차적으로 조치합니다"
옵션 2: "[{심각도}] {위치} - {내용 요약 30자}" - "{내용 전체}"
옵션 3: "[{심각도}] {위치} - {내용 요약 30자}" - "{내용 전체}"
옵션 4: "[{심각도}] {위치} - {내용 요약 30자}" - "{내용 전체}"
"모두 조치" 선택 시:
사용자가 선택한 각 항목에 대해:
수정 시 준수 사항:
⛔ 로컬
./gradlew절대 금지. 수정 검증을 위해 로컬에서 Gradle(ktlint/test/build)을 실행하지 마라. 로컬 Gradle은 데몬이 잔존하여 시스템을 느리게 만든다. 파일 편집만 로컬에서 하고, 빌드/테스트 검증은 후속jenkins-ci-loop단계가 원격(AI_server)에서 수행한다.
✅ 리뷰 항목 조치 완료
| # | 항목 | 결과 |
|---|------|------|
| 1 | {위치} - {내용 요약} | ✅ 수정 완료 |
| 2 | {위치} - {내용 요약} | ⚠️ 수동 확인 필요 |
{수정 상세 내용}
미조치 항목이 4개를 초과하면:
📋 추가 미조치 항목이 {N}건 있습니다.
계속 조치하시겠습니까?
AskUserQuestion으로 다음 4개 항목 제시.
다음 상황에서는 자동 수정하지 않고 사용자에게 안내한다:
⚠️ 다음 항목은 자동 수정이 어렵습니다:
| # | 항목 | 사유 |
|---|------|------|
| 1 | {내용} | 아키텍처 변경 필요 |
수동 조치 후 `/pr-review`로 재검증하세요.
# PR 리뷰 댓글 조회
gh pr view {number} -R owner/repo --json comments -q '.comments[].body'
# 현재 브랜치의 PR 조회
gh pr view --json number -q '.number'
pr-review: PR 리뷰 수행 및 댓글 등록branch-review: 브랜치 리뷰 보고서 생성