cross-verifylisted

# 교차 검증 스킬 > 자동화가 아닌, **개발자가 의도적으로 멈추고 확인하는 행위를 구조화한 것**. > 도구가 측정할 수 없는 "의미적 판단"에 집중한다. --- ## 호출 방식 - `/cross-verify` 직접 호출 - 트리거 키워드: "교차 검증", "크로스 체크", "cross verify" ## 프로젝트 설정 연동 ops-agent 의 `config/cross-verify/profiles/` 디렉토리에서 프로젝트별 프로필을 자동 매칭한다. 프로필은 유저 스코프(`~/.claude/cross-verify/profiles/`)에 보관된다. 플러그인 업데이트와 독립적으로 유지된다. ### 프로필 탐색 절차 ```bash # 1. 유저 스코프에서 프로필 목록 탐색 ls ~/.claude/cross-verify/profiles/*.json 2>/dev/null ``` 1. 프로필 파일을 순회하며 각 프로필의 `project` 필드를 읽는다 2. 현재 프로젝트의 CLAUDE.md 또는 디렉토리명에서 프로젝트 식별자를 추출한다 3. `project` 필드와 매칭되는 프로필을 자동 선택한다 4. 매칭 실패 시 사용자에게 프로필 목록을 제시하고 선택을 요청한다 5. 프로필이 하나도 없으면 범용 4축 검증을 실행한다 (기존 동작) ### 프로필 적용 프로필이 매칭되면: 1. `conventions` 경로의 문서를 읽어 컨벤션 기준으로 검증 2. `designDocs` 위치를 참조하여 설계 문서 확인 3. `focusAxes`에 지정된 축만 실행 (생략 시 전체) 4. `customChecks`의 항목을 해당 축 검증에 추가 > 프로필 관리: `~/.claude/cross-verify/profiles/`에서 직접 편집 ## 동작 흐름 ### Phase 1: 대상 파악 사용자가 제시한 컨텍스트를 수집한다. **입력 유형:** - 파일 경로 (코드, 문서, 설정) - 커밋 범위 (`git diff`, `git log`) - 설계 문서 또는 위키 URL - 자유 텍스트 설명 컨텍스트가 불충분하면 사용자에게 질문한다: ``` 검증 대상이 명확하지 않습니다. 다음 중 해당하는 것을 알려주세요: - 검증할 파일 경로 - 관련 커밋 또는 PR - 검토 중인 설계/의사결정 내용 ``` ### Phase 2: 4축 검증 실행 각 축별로 대상을 읽고, 구조화된 질문과 관찰을 생성한다. --- #### 축 1: 의사결정 검증 > "왜 이 선택인가? 대안과 트레이드오프는?" **검증 포인트:** - 현재 선택의 근거가 명시되어 있는가? - 검토한 대안이 있는가? 왜 기각했는가? - **트레이드오프가 명시적인가?** — 이 선택으로 얻는 것과 포기하는 것이 기술되어 있는가? - **반대 선택도 합리적인가?** (Opposite Test — 반대편이 사소하다면 이것은 진짜 선택이 아니다) - 이 결정이 뒤집어질 수 있는 조건은 무엇인가? - 결정의 영향 범위를 인지하고 있는가? - **이 선택이 외부 공격에 노출되는 범위를 넓