원클릭으로 Manus에서 모든 스킬 실행

시작하기

review-action

스타0

포크1

업데이트2026년 5월 31일 08:53

PR 리뷰 결과의 조치 필요 항목을 파싱하여 리스트로 보여주고, 사용자가 선택한 항목을 수정하는 스킬입니다. 이 스킬은 "/review-action", "/review-action

설치

Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.

Manus에서 실행

출처

invigoworks

invigoworks/invigo-marketplace

GitHub 저장소 열기 Creator 저장소 보기

다운로드

Manus에서 실행

Review Action

Purpose

PR 리뷰 결과(pr-review 스킬로 생성된 댓글)에서 조치 필요 항목 테이블을 파싱하여 사용자에게 선택지를 제공하고, 선택된 항목을 수정한다.

Workflow

Step 0: PR 번호 확인

PR 번호를 다음 우선순위로 결정한다:

인자로 전달된 경우: /review-action #123 → #123
현재 브랜치의 PR 조회:
```
gh pr view --json number -q '.number'
```
사용자에게 질문: 위 방법으로 확인 불가 시

Step 1: PR 리뷰 댓글 조회

gh pr view {pr-number} -R invigoworks/bitda-back --json comments -q '.comments[].body'

가장 최근의 ## 🔍 PR 리뷰 결과 댓글을 찾는다.

Step 2: 조치 필요 항목 파싱

리뷰 댓글에서 ### 📋 조치 필요 항목 섹션의 테이블을 파싱한다:

| # | 심각도 | 분류 | 위치 | 내용 | 상태 | 비고 |
|---|--------|------|------|------|------|------|
| 1 | 심각 | 코드품질 | `파일:라인` | 설명 | ⬜ | N차 신규 |

파싱 결과:

#: 항목 번호
심각도: 심각/중간/낮음
분류: 코드품질, 테스트, 백엔드아키텍처, 아키텍처일관성
위치: 파일:라인 형식
내용: 지적 내용
상태: ⬜ (미조치) / ✅ (조치완료)

⬜ 상태인 항목만 목록에 포함한다.

Step 3: 항목 목록 표시 및 선택

AskUserQuestion 도구를 사용하여 사용자에게 선택지를 제공한다.

표시 형식:

📋 조치 필요 항목 ({N}건)

조치할 항목을 선택하세요.

옵션 구성:

첫 번째 옵션은 항상 "모두 조치" (미조치 항목 전체 처리)
나머지 옵션으로 개별 항목 제공 (최대 3개씩)
multiSelect: true로 여러 항목 동시 선택 가능
항목이 3개 초과 시 심각도 순으로 3개씩 배치

옵션 예시:

옵션 1: "모두 조치 ({N}건)" - "미조치 항목 전체를 순차적으로 조치합니다"
옵션 2: "[{심각도}] {위치} - {내용 요약 30자}" - "{내용 전체}"
옵션 3: "[{심각도}] {위치} - {내용 요약 30자}" - "{내용 전체}"
옵션 4: "[{심각도}] {위치} - {내용 요약 30자}" - "{내용 전체}"

"모두 조치" 선택 시:

모든 미조치 항목을 심각도 순(심각 → 중간 → 낮음)으로 처리
각 항목 수정 후 진행 상황 표시
자동 수정 불가 항목은 건너뛰고 마지막에 보고

Step 4: 선택된 항목 수정

사용자가 선택한 각 항목에 대해:

파일 읽기: 위치에서 파일 경로 추출 후 Read 도구로 읽기
문제 분석: 지적 내용을 바탕으로 문제점 파악
수정 수행: Edit 도구로 코드 수정
검증: 수정이 지적 사항을 해결했는지 확인

수정 시 준수 사항:

CLAUDE.md 아키텍처 규칙 준수
기존 코드 스타일 유지
최소한의 변경으로 문제 해결

⛔ 로컬 ./gradlew 절대 금지. 수정 검증을 위해 로컬에서 Gradle(ktlint/test/build)을 실행하지 마라. 로컬 Gradle은 데몬이 잔존하여 시스템을 느리게 만든다. 파일 편집만 로컬에서 하고, 빌드/테스트 검증은 후속 jenkins-ci-loop 단계가 원격(AI_server)에서 수행한다.

Step 5: 결과 보고

✅ 리뷰 항목 조치 완료

| # | 항목 | 결과 |
|---|------|------|
| 1 | {위치} - {내용 요약} | ✅ 수정 완료 |
| 2 | {위치} - {내용 요약} | ⚠️ 수동 확인 필요 |

{수정 상세 내용}

Step 6: 추가 항목 처리 (4개 초과 시)

미조치 항목이 4개를 초과하면:

📋 추가 미조치 항목이 {N}건 있습니다.
계속 조치하시겠습니까?

AskUserQuestion으로 다음 4개 항목 제시.

수정 불가 상황 처리

다음 상황에서는 자동 수정하지 않고 사용자에게 안내한다:

아키텍처 변경 필요: 파일 이동, 모듈 구조 변경 등
요구사항 확인 필요: 비즈니스 로직 관련 지적
테스트 작성 필요: 새 테스트 코드 작성이 필요한 경우

⚠️ 다음 항목은 자동 수정이 어렵습니다:

| # | 항목 | 사유 |
|---|------|------|
| 1 | {내용} | 아키텍처 변경 필요 |

수동 조치 후 `/pr-review`로 재검증하세요.

CLI Reference

# 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: 브랜치 리뷰 보고서 생성

이 저장소의 다른 Skills

같은 저장소

e2e-test-dev

invigoworks/invigo-marketplace

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 스킬 사용)

2026-06-160

gap-analyze

invigoworks/invigo-marketplace

plan-master(기획용 FE 코드 + docs/specs 기획서)와 bitda-back(구현된 BE 코드) 사이의 갭을 분석하여 누락된 기능·API·정책을 GitHub 이슈로 자동 생성하는 스킬입니다. 기획서→이슈 전달 과정에서 발생하는 누락을 방지하기 위해 FE 코드를 1차 소스로 사용합니다. "/gap-analyze", "/gap-analyze BOM", "/gap-analyze production" 등을 요청할 때 사용됩니다.

2026-06-060

gap-fe-code

invigoworks/invigo-marketplace

plan-master FE 코드만을 유일한 1차 소스로(기획서 .md 배제) 멀티팀 에이전트가 BE가 보장해야 할 비즈니스 로직과 FE 작업에 필요한 API 항목을 도출하고, 총괄 에이전트가 bitda-back BE 구현과 실측 대조하여 누락 갭을 발굴, 직렬 verifier로 확정한 뒤 GitHub 이슈로 생성하는 스킬입니다. gap-analyze의 변종으로, 기획서가 구현완료를 선언해 갭을 가리는 오염을 제거하기 위해 기획서를 의도적으로 보지 않습니다. /gap-fe-code 생산현황, 기획서 빼고 FE 코드로 갭 분석, FE 코드만 보고 누락 API 이슈 만들어 등을 요청할 때 사용됩니다.

2026-06-060

e2e-test

invigoworks/invigo-marketplace

실제 API 서버(8080 포트)를 실행하고 Keycloak OAuth 인증을 통해 E2E API 테스트를 수행하는 스킬입니다. 테스트 결과와 요청/응답을 docs/e2e-test/{test}/ 디렉토리에 markdown 형식으로 기록합니다. 이 스킬은 다음 상황에서 사용됩니다: - 특정 API의 실제 동작을 테스트하고 싶을 때 - API 변경 후 실제 환경에서 검증이 필요할 때 - 사용자가 "E2E 테스트", "API 테스트", "/e2e-test" 등을 요청할 때

2026-06-040

feature-planner

invigoworks/invigo-marketplace

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.

2026-06-020

api-to-notion-api

invigoworks/invigo-marketplace

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" 등을 요청할 때

2026-05-310

name	review-action
description	PR 리뷰 결과의 조치 필요 항목을 파싱하여 리스트로 보여주고, 사용자가 선택한 항목을 수정하는 스킬입니다. 이 스킬은 "/review-action", "/review-action

Review Action

Purpose

PR 리뷰 결과(pr-review 스킬로 생성된 댓글)에서 조치 필요 항목 테이블을 파싱하여 사용자에게 선택지를 제공하고, 선택된 항목을 수정한다.

Workflow

Step 0: PR 번호 확인

PR 번호를 다음 우선순위로 결정한다:

인자로 전달된 경우: /review-action #123 → #123
현재 브랜치의 PR 조회:
```
gh pr view --json number -q '.number'
```
사용자에게 질문: 위 방법으로 확인 불가 시

Step 1: PR 리뷰 댓글 조회

gh pr view {pr-number} -R invigoworks/bitda-back --json comments -q '.comments[].body'

가장 최근의 ## 🔍 PR 리뷰 결과 댓글을 찾는다.

Step 2: 조치 필요 항목 파싱

리뷰 댓글에서 ### 📋 조치 필요 항목 섹션의 테이블을 파싱한다:

| # | 심각도 | 분류 | 위치 | 내용 | 상태 | 비고 |
|---|--------|------|------|------|------|------|
| 1 | 심각 | 코드품질 | `파일:라인` | 설명 | ⬜ | N차 신규 |

파싱 결과:

#: 항목 번호
심각도: 심각/중간/낮음
분류: 코드품질, 테스트, 백엔드아키텍처, 아키텍처일관성
위치: 파일:라인 형식
내용: 지적 내용
상태: ⬜ (미조치) / ✅ (조치완료)

⬜ 상태인 항목만 목록에 포함한다.

Step 3: 항목 목록 표시 및 선택

AskUserQuestion 도구를 사용하여 사용자에게 선택지를 제공한다.

표시 형식:

📋 조치 필요 항목 ({N}건)

조치할 항목을 선택하세요.

옵션 구성:

첫 번째 옵션은 항상 "모두 조치" (미조치 항목 전체 처리)
나머지 옵션으로 개별 항목 제공 (최대 3개씩)
multiSelect: true로 여러 항목 동시 선택 가능
항목이 3개 초과 시 심각도 순으로 3개씩 배치

옵션 예시:

옵션 1: "모두 조치 ({N}건)" - "미조치 항목 전체를 순차적으로 조치합니다"
옵션 2: "[{심각도}] {위치} - {내용 요약 30자}" - "{내용 전체}"
옵션 3: "[{심각도}] {위치} - {내용 요약 30자}" - "{내용 전체}"
옵션 4: "[{심각도}] {위치} - {내용 요약 30자}" - "{내용 전체}"

"모두 조치" 선택 시:

모든 미조치 항목을 심각도 순(심각 → 중간 → 낮음)으로 처리
각 항목 수정 후 진행 상황 표시
자동 수정 불가 항목은 건너뛰고 마지막에 보고

Step 4: 선택된 항목 수정

사용자가 선택한 각 항목에 대해:

파일 읽기: 위치에서 파일 경로 추출 후 Read 도구로 읽기
문제 분석: 지적 내용을 바탕으로 문제점 파악
수정 수행: Edit 도구로 코드 수정
검증: 수정이 지적 사항을 해결했는지 확인

수정 시 준수 사항:

CLAUDE.md 아키텍처 규칙 준수
기존 코드 스타일 유지
최소한의 변경으로 문제 해결

⛔ 로컬 ./gradlew 절대 금지. 수정 검증을 위해 로컬에서 Gradle(ktlint/test/build)을 실행하지 마라. 로컬 Gradle은 데몬이 잔존하여 시스템을 느리게 만든다. 파일 편집만 로컬에서 하고, 빌드/테스트 검증은 후속 jenkins-ci-loop 단계가 원격(AI_server)에서 수행한다.

Step 5: 결과 보고

✅ 리뷰 항목 조치 완료

| # | 항목 | 결과 |
|---|------|------|
| 1 | {위치} - {내용 요약} | ✅ 수정 완료 |
| 2 | {위치} - {내용 요약} | ⚠️ 수동 확인 필요 |

{수정 상세 내용}

Step 6: 추가 항목 처리 (4개 초과 시)

미조치 항목이 4개를 초과하면:

📋 추가 미조치 항목이 {N}건 있습니다.
계속 조치하시겠습니까?

AskUserQuestion으로 다음 4개 항목 제시.

수정 불가 상황 처리

다음 상황에서는 자동 수정하지 않고 사용자에게 안내한다:

아키텍처 변경 필요: 파일 이동, 모듈 구조 변경 등
요구사항 확인 필요: 비즈니스 로직 관련 지적
테스트 작성 필요: 새 테스트 코드 작성이 필요한 경우

⚠️ 다음 항목은 자동 수정이 어렵습니다:

| # | 항목 | 사유 |
|---|------|------|
| 1 | {내용} | 아키텍처 변경 필요 |

수동 조치 후 `/pr-review`로 재검증하세요.

CLI Reference

# 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: 브랜치 리뷰 보고서 생성