菜单
PR 리뷰 결과의 조치 필요 항목을 파싱하여 리스트로 보여주고, 사용자가 선택한 항목을 수정하는 스킬입니다. 이 스킬은 "/review-action", "/review-action
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| 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: 브랜치 리뷰 보고서 생성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" 등을 요청할 때