d3ro-voice/.claude/skills/harness-gate/SKILL.md

name	description
harness-gate	규칙 거버넌스 메타 게이트. 사용자가 새 원칙·가이드·규칙을 제시하거나, 기존 규칙(CLAUDE.md 코딩 규칙 / settings.json 강제 규칙 훅 / memory 피드백)과 충돌 가능한 요청을 할 때, 또는 "이제부터 ~하자" "앞으로 ~해줘" "~하지 마" 등 지속 규칙성 발언을 할 때 반드시 발동. 드리프트를 감지해 규칙 갱신 여부를 게이트한다. 트리거: "이제부터", "앞으로", "규칙", "원칙", "방침", "항상", "절대", "새 규칙", "정책 변경", "방향 바꾸자".

harness-gate — 규칙 거버넌스 메타 스킬

D3RO-VOICE 규칙 SSOT 3계층

규칙은 아래 3곳에 나뉘어 산다. 어디를 고칠지 결정하는 것이 이 스킬의 핵심 역할.

계층	위치	담당
L1 코드/아키텍처 규칙	CLAUDE.md 「코딩 규칙」 섹션	any 금지, console.log 금지, 싱글톤+EventEmitter, IPC 네이밍, 테마 SSOT, i18n 등
L2 매 턴 강제 주입 규칙	.claude/settings.json UserPromptSubmit 훅의 [D3RO-VOICE 강제 규칙] 1~13	설계서 참조 의무, 상태머신 분리, 팝업 Vanilla JS 등
L3 소통/작업 방식 피드백	memory/user_preferences.md 등 memory 파일	대화 스타일, 작업 순서 선호, 갱신 의무

동기화 주의: L1과 L2는 내용이 겹친다 (예: any 금지는 양쪽 모두 존재). 한쪽을 완화/제거하면 반드시 다른 쪽도 확인해서 모순을 남기지 않는다. 설계 변경(서비스 인터페이스, IPC 타입 등)은 규칙 변경이 아니라 docs/design/00~03 설계 문서 수정이다 — 이 스킬 대상 아님.

언제 발동하는가

1. 새 지속 규칙 감지: 사용자가 "이제부터 X", "앞으로 Y", "항상 Z", "절대 W 금지" 같은 문형을 씀
2. 기존 규칙 완화 요청: "이번엔 console.log 써도 돼", "hex 하드코딩 잠깐 괜찮음" 등 L1/L2에 반하는 예외 요청
3. 규칙 시스템 언급: "규칙 추가", "정책", "방침 바꾸자" 키워드
4. memory와 요청 불일치: memory/project_status.md의 현재 상태와 실제 작업 요청이 어긋나 보일 때

실행 단계

STEP 1. 충돌·드리프트 분류

유형 A: 기존 L1/L2/L3 규칙과 정면 충돌하는 완화 요청
  → STRICT 모드. 거부 기본값. 사용자가 강하게 고집하면 RELAX 처리

유형 B: 기존 규칙 없는 신규 원칙
  → 등록 위치(L1/L2/L3) 판단 후 등록 제안

유형 C: 일회성 요청 (지속 규칙 아님)
  → 게이트 통과, 규칙 파일 건드리지 않음. 단순 실행.

유형 D: 이미 규칙화된 내용의 재확인
  → "이미 CLAUDE.md 코딩 규칙 N번 / 강제 규칙 N번에 있습니다"라고 알리고 통과

STEP 2. 사용자 확인 (AskUserQuestion)

유형 A·B일 때만 확인. C는 질문 없이 바로 실행.

예시 (유형 B):

방금 주신 가이드가 앞으로도 지속 적용될 규칙인가요?

[옵션]
- 네, 정식 등록 → 위치(CLAUDE.md / settings.json 훅 / memory) 판단해서 등록
- 이번만 적용 → 단순 실행 (규칙 파일 불변)
- 잘 모르겠음 → 3회 반복까지 관찰 후 재판단

예시 (유형 A):

이 요청은 기존 규칙 「테마 SSOT: hex 하드코딩 금지」(CLAUDE.md 코딩 규칙 + 강제 규칙 11)와 충돌합니다.
규칙 근거: d3roPalette 단일 소스, 라이트/다크 테마 전환 안전성.

[옵션]
- 이번만 예외 (규칙 유지) → 해당 라인에 // RULE-EXCEPT: 사유 주석
- 규칙 완화 (RELAX) → 규칙 문구에 "단, NN 상황 예외" 추가 (L1·L2 양쪽 동기화)
- 규칙 제거 (REMOVE) → L1·L2 양쪽에서 삭제
- 요청 철회

STEP 3. 유형별 조치

• 유형 A RELAX/REMOVE: 해당 규칙이 있는 모든 계층(L1·L2 겹침 확인) 수정. 규칙 파일 변경은 단독 커밋으로 분리 (chore(rules): ...) — 변경 이력은 git이 담당.
• 유형 B ADD:
  • 코드/아키텍처 규칙 → CLAUDE.md 「코딩 규칙」에 추가. 매 턴 강제가 필요할 만큼 위반이 잦은 규칙이면 settings.json 훅 목록에도 추가.
  • 소통/작업 방식 → memory 파일 (user_preferences.md 갱신 또는 신규 memory + MEMORY.md 인덱스 갱신). Why: / How to apply: 형식 준수.
• 유형 C PASS-THROUGH: 이 스킬 종료, 사용자 요청대로 진행.
• 유형 D NOTIFY: 기존 규칙 위치와 본문 인용 후 통과.

STEP 4. 요약 리포트

사용자에게 3줄 이내로:

[harness-gate]
분류: 유형 B (신규 원칙)
조치: CLAUDE.md 코딩 규칙에 등록 + settings.json 훅 14번으로 추가. 커밋 분리 완료.

이 스킬이 발동하지 말아야 하는 경우

• "이 버튼 색깔 바꿔줘" 같은 단순 UI 작업
• "이 버그 고쳐줘" 같은 단건 수정
• 이미 implement-phase / refactor-wave 등 전용 스킬이 발동한 맥락 (그 스킬 내부에서 필요하면 호출)

메타 원칙

"Harness serves the work, not the other way around."

규칙이 작업을 방해하면 잘못 설계된 것. 빠른 분류 + 빠른 통과가 기본. 정말 중요한 드리프트만 사용자에게 묻는다.

참조

• CLAUDE.md — 코딩 규칙 (L1)
• .claude/settings.json — UserPromptSubmit 훅 [D3RO-VOICE 강제 규칙] (L2)
• memory/MEMORY.md + memory/*.md — 피드백/선호 (L3)
• docs/design/00~03 — 설계 SSOT (규칙 아님, 설계 변경은 별도)