菜单
프로젝트의 모든 verify 스킬을 순차 실행하여 통합 검증 보고서를 생성합니다. 기능 구현 후, PR 전, 코드 리뷰 시 사용.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | verify-implementation |
| description | 프로젝트의 모든 verify 스킬을 순차 실행하여 통합 검증 보고서를 생성합니다. 기능 구현 후, PR 전, 코드 리뷰 시 사용. |
| disable-model-invocation | true |
| argument-hint | [선택사항: 특정 verify 스킬 이름] |
프로젝트에 등록된 모든 verify-* 스킬을 순차적으로 실행하여 통합 검증을 수행합니다:
이 스킬이 순차 실행하는 검증 스킬 목록입니다. /manage-skills가 스킬을 생성/삭제할 때 이 목록을 자동 업데이트합니다.
| # | 스킬 | 설명 |
|---|---|---|
| 1 | verify-ui-patterns | UI 컴포넌트 사용 일관성 검증 (toast, TableWrapper, SortableHeader, import 순서, 숫자 컬럼 정렬, 상세 기본정보 그리드) |
| 2 | verify-badge-consistency | StatusBadge 사용 일관성 및 뱃지 색상 타입 안전성 검증 |
| 3 | verify-production | 생산관리 모듈 구조 검증 (barrel export, 타입-목데이터, 명명 규칙, screen code) |
| 4 | verify-routing | 라우팅 및 네비게이션 검증 (라우트-페이지 매핑, 미등록 페이지, 경로 접두사) |
| 5 | verify-plan-implementation | 기획문서 요구사항의 구현 반영 검증 (비즈니스 규칙, 데이터 필드, AC 조건, 컴포넌트 스펙) |
| 6 | verify-plan-changes | 기획 변경사항의 코드 전파 검증 (필드명 변경, 공식 수정, 조건 추가, 상수 업데이트) |
| 7 | verify-dialog-safety | Dialog/Sheet 안전성 검증 (sibling dialog 가드, isDirty 연쇄 방지, state 초기화, DialogDescription, destructive variant, ScrollArea flex 충돌) |
| 8 | verify-data-consistency | 타입-스키마 동기화, mock 데이터 비즈니스 규칙 준수, 레코드/품목 레벨 속성 정합성 검증 |
| 9 | verify-runtime-data | 런타임 데이터 불일치 검증 (availableQty/currentQty, stocks 빈 배열, formatDate NaN, purchaseDate 접근, entity 필수 필드, refId UUID 노출) |
| 10 | verify-dev-server-health | Dev 서버/HMR 런타임 에러 진단 (@fs 404, dynamic import 실패, 포트 충돌, stale HMR) |
| 11 | verify-service-match | 실서비스(data/bitda-front, data/bitda-back)와 현재 구현 간 정합성 검증 — UI(P1 |
위의 실행 대상 스킬 섹션에 나열된 스킬을 확인합니다.
선택적 인수가 제공된 경우, 해당 스킬만 필터링합니다.
등록된 스킬이 0개인 경우:
## 구현 검증
검증 스킬이 없습니다. `/manage-skills`를 실행하여 프로젝트에 맞는 검증 스킬을 생성하세요.
이 경우 워크플로우를 종료합니다.
등록된 스킬이 1개 이상인 경우:
실행 대상 스킬 테이블의 내용을 표시합니다:
## 구현 검증
다음 검증 스킬을 순차 실행합니다:
| # | 스킬 | 설명 |
|---|------|------|
| 1 | verify-<name1> | <description1> |
| 2 | verify-<name2> | <description2> |
검증 시작...
실행 대상 스킬 테이블에 나열된 각 스킬에 대해 다음을 수행합니다:
해당 스킬의 .claude/skills/verify-<name>/SKILL.md를 읽고 다음 섹션을 파싱합니다:
Workflow 섹션에 정의된 각 검사를 순서대로 실행합니다:
각 스킬 실행 완료 후 진행 상황을 표시합니다:
### verify-<name> 검증 완료
- 검사 항목: N개
- 통과: X개
- 이슈: Y개
- 면제: Z개
[다음 스킬로 이동...]
모든 스킬 실행 완료 후, 결과를 하나의 보고서로 통합합니다:
## 구현 검증 보고서
### 요약
| 검증 스킬 | 상태 | 이슈 수 | 상세 |
|-----------|------|---------|------|
| verify-<name1> | PASS / X개 이슈 | N | 상세... |
| verify-<name2> | PASS / X개 이슈 | N | 상세... |
**발견된 총 이슈: X개**
모든 검증 통과 시:
모든 검증을 통과했습니다!
구현이 프로젝트의 모든 규칙을 준수합니다:
- verify-<name1>: <통과 내용 요약>
- verify-<name2>: <통과 내용 요약>
코드 리뷰 준비가 완료되었습니다.
이슈 발견 시:
각 이슈를 파일 경로, 문제 설명, 수정 권장 사항과 함께 나열합니다:
### 발견된 이슈
| # | 스킬 | 파일 | 문제 | 수정 방법 |
|---|------|------|------|-----------|
| 1 | verify-<name1> | `path/to/file.ts:42` | 문제 설명 | 수정 코드 예시 |
| 2 | verify-<name2> | `path/to/file.tsx:15` | 문제 설명 | 수정 코드 예시 |
이슈가 발견된 경우 AskUserQuestion을 사용하여 사용자에게 확인합니다:
---
### 수정 옵션
**X개 이슈가 발견되었습니다. 어떻게 진행할까요?**
1. **전체 수정** - 모든 권장 수정사항을 자동으로 적용
2. **개별 수정** - 각 수정사항을 하나씩 검토 후 적용
3. **건너뛰기** - 변경 없이 종료
사용자 선택에 따라 수정을 적용합니다.
"전체 수정" 선택 시:
모든 수정을 순서대로 적용하며 진행 상황을 표시합니다:
## 수정 적용 중...
- [1/X] verify-<name1>: `path/to/file.ts` 수정 완료
- [2/X] verify-<name2>: `path/to/file.tsx` 수정 완료
X개 수정 완료.
"개별 수정" 선택 시:
각 이슈마다 수정 내용을 보여주고 AskUserQuestion으로 승인 여부를 확인합니다.
수정이 적용된 경우, 이슈가 있었던 스킬만 다시 실행하여 Before/After를 비교합니다:
## 수정 후 재검증
이슈가 있었던 스킬을 다시 실행합니다...
| 검증 스킬 | 수정 전 | 수정 후 |
|-----------|---------|---------|
| verify-<name1> | X개 이슈 | PASS |
| verify-<name2> | Y개 이슈 | PASS |
모든 검증을 통과했습니다!
여전히 이슈가 남은 경우:
### 잔여 이슈
| # | 스킬 | 파일 | 문제 |
|---|------|------|------|
| 1 | verify-<name> | `path/to/file.ts:42` | 자동 수정 불가 — 수동 확인 필요 |
수동으로 해결한 후 `/verify-implementation`을 다시 실행하세요.
다음은 문제가 아닙니다:
verify-로 시작하지 않으므로 실행 대상에 포함되지 않음| File | Purpose |
|---|---|
.claude/skills/manage-skills/SKILL.md | 스킬 유지보수 (이 파일의 실행 대상 스킬 목록을 관리) |
CLAUDE.md | 프로젝트 지침 |
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" 등을 요청할 때