| name | discover-repo-governance |
| description | iOS 프로젝트의 CLAUDE.md, rules, hooks, governance 구조를 셋업하거나 개선할 때 현재 저장소 상태를 진단한다. 파일 생성 없이 discovery만 수행한다. |
| allowed-tools | Read Grep Glob Bash |
목적
이 저장소의 현재 governance 및 하네스 상태를 진단한다.
이 skill은 discovery 전용이다. 파일 생성이나 수정은 하지 않는다.
이미 /init 산출물이 있으면 그것부터 확인하고, 기존 governance 입력으로 취급한다.
하네스 엔지니어링 관점에서의 역할
이 skill의 목적은 단순한 파일 목록 수집이 아니다.
이 skill의 목적은 다음 질문에 답할 수 있는 진단 자료를 만드는 것이다.
- 이 저장소에서 에이전트가 항상 알아야 할 정보는 무엇인가
- 특정 경로나 작업에서만 필요한 정보는 무엇인가
- 현재 문서/규칙/설정 구조가 원하는 상태를 향하고 있는가
- 사람의 확인 없이 추론하면 위험한 영역은 어디인가
- 어떤 실패를 줄이기 위해 governance가 설계되어야 하는가
즉, 이 skill은 “문서를 무엇을 만들까”보다 먼저
“이 프로젝트에서 하네스가 무엇을 통제하고 보호해야 하는가”를 파악하기 위한 진단 단계다.
무엇을 확인할 것인가
1. 저장소 구조
- 기본적으로 깊이 3 수준에서 디렉터리 트리를 스캔한다.
- 프로젝트가 더 깊게 중첩되어 보이면, 관련 하위 트리만 추가로 추적한다.
- 앱 타깃, feature 모듈, shared core 모듈, tools, scripts, CI, docs 영역을 식별한다.
2. 기존 governance 아티팩트
다음을 확인한다.
CLAUDE.md.claude/CLAUDE.mdCLAUDE.local.md.claude/rules/.claude/settings.json.claude/settings.local.json.claude/hooks/.claude/skills//init 기반 bootstrap 흔적 또는 기존 governance 주석
3. iOS 프로젝트 경계 신호
다음을 찾는다.
Package.swift.xcodeproj.xcworkspace- Tuist manifest
- project generation script
- feature-module convention
- test target naming pattern
4. Build / Test / Lint / Format 신호
다음 명령과 엔트리포인트를 식별한다.
- build
- unit test
- UI test
- lint
- format
- project generation
반드시 저장소 근거만 사용한다.
5. 기존 문서 신호
최소한의 범위에서 다음을 읽는다.
README*- ADR
CHANGELOG*- architecture 문서
- onboarding 문서
- engineering guideline
이 중 governance와 직접 관련 있는 신호만 추출한다.
- architecture rule
- coding pattern
- workflow expectation
- 이미 문서화된 domain policy
6. desired state 진단 신호
가능하면 아래도 함께 추출한다.
- 자주 반복되는 경고, 금지, 승인 요구사항
- 모듈 경계가 이미 코드에서 강하게 드러나는지 여부
- 테스트/검증 루프가 문서화되어 있는지 여부
- 전역 문서에 과도하게 많은 세부 규칙이 몰려 있는지 여부
- 특정 도메인 규칙이 코드에는 드러나지만 문서에는 없는지 여부
출력 형식
반드시 아래 4개 섹션을 반환한다.
A. 확실한 것
저장소 파일이나 문서로 직접 뒷받침되는 사실.
B. 추론 가능한 것
저장소 패턴상 합리적이지만 아직 확인되지 않은 가설.
C. 반드시 사용자에게 물어야 할 것
저장소 근거만으로는 신뢰성 있게 답할 수 없는 질문.
D. 하네스 관점의 위험 신호
원하는 상태를 방해할 수 있는 구조적 위험 또는 공백.
예:
- 전역 문서에 세부 정책이 몰릴 가능성
- 특정 도메인 정책이 문서화되지 않아 추측 생성 위험이 큰 영역
- hook이 더 적합해 보이는 보호 정책
- path-scoped rule로 분리해야 할 신호
규칙
- 이 skill 안에서 사용자에게 직접 질문하지 않는다.
- 어떤 파일도 생성하거나 수정하지 않는다.
- 명시적 문서가 없는 제품/도메인 규칙을 추측하지 않는다.
- 장황한 나열보다 간결하고 신호가 높은 결과를 우선한다.
- 근거가 충돌하면 조용히 한쪽을 택하지 말고 충돌 자체를 드러낸다.
- desired state에 대한 판단은 “가능한 위험 신호” 수준으로만 표현하고, 확정 규칙처럼 쓰지 않는다.
좋은 출력 형태
각 섹션 아래에 bullet로 정리한다.
반드시 사용자에게 물어야 할 것은 governance 파일의 배치나 문구에 직접 영향을 줄 수 있는 구체적인 결정 질문 형태로 작성한다.
