discover-repo-governance

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.md
• CLAUDE.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 파일의 배치나 문구에 직접 영향을 줄 수 있는 구체적인 결정 질문 형태로 작성한다.