spec-guardlisted

# spec-guard ## 이 스킬이 고치는 것 | 증상 | 원인 | 처리 | |---|---|---| | 중요한 얘기를 뒤에서 흘림 | 긴 세션에서 앞 컨텍스트 우선순위 하락 | rules 상시 로드 + 훅 리마인더 | | 확인 없이 가정하고 진행 | silent assumption | 규칙 1 | | 아까는 5점이라더니 다시 보니 3점 | 채점이 재현 불가능 — 근거를 안 남겼고, 고친 사람이 바로 채점 | 규칙 2·3·4 | | 돈·위험을 물어봐야 그제서야 답함 | 위험 스캔이 요청 기반 | 규칙 6 | | git·백업 같은 전제가 깨진 채 방치 | 아무도 확인 안 함 | 규칙 4 + 세션 시작 점검 | | PRD 위험을 나중에야 알게 됨 | 기획 시점에 훑지 않음 | `RULES-prd.md` (기획 문서 열 때만 로드) | 규칙 전문은 `RULES.md`에 있다. 설치 시 프로젝트의 `.claude/rules/spec-guard.md`로 복사되어 **세션 시작에 한 번 로드**된다. --- ## 설정 (프로젝트당 1회) 사용자가 이 스킬을 부르면 아래를 **순서대로** 한다. ### 1. `.claude/SPEC-LOCK.md` 만들기 세 가지를 묻고 채운다. 길게 쓰지 말고 **검증 가능한 문장**으로. ```markdown # SPEC-LOCK — {프로젝트명} 갱신: {YYYY-MM-DD} ## 🔒 불변 원칙 <!-- 절대 어기면 안 되는 것 3~5개. 어기려면 사용자 승인 필요. --> ## ✅ 합격 기준 <!-- "만점"이 뭔지 정의. 반드시 O/X로 판정 가능하게. 애매하면 숫자를 넣어라. --> ## ⚠️ 위험 요소 <!-- 전에 데인 것, 놓치기 쉬운 것. 관련 작업 시작 시 먼저 꺼낸다. --> ## 📌 확정된 결정 <!-- 다시 논의하지 않기로 한 것. "왜"를 같이 적어야 나중에 안 뒤집힌다. --> ``` **합격 기준 판정법**: 각 줄을 읽고 "이거 O인지 X인지 지금 판단 가능한가?" 물어라. 불가능하면 다시 써야 한다. "완성도·퀄리티·잘 만든" 같은 단어가 있으면 거의 실패다. - ❌ `완성도 높은 웹` - ✅ `모바일 375px에서 가로 스크롤 0` **40줄 안쪽으로 유지.** 세션마다 로드되므로 길면 비용이 늘고, 길면 어차피 안 지켜진다. ### 2. 규칙 파일 복사 (2개) ```bash mkdir -p .claude/rules cp ~/.claude/skills/spec-guard/RULES.md .claude/rules/spec-guard.md cp ~/.claude/skills/spec-guard/RULES-prd.md .claude/rules/spec-guard-prd.md ``` `spec-guard-prd.md`에는 `paths:` 프론트매터가 있어 **PRD·기획·요구사항 문서를 읽을 때만** 로드된다. 기획 안 할 땐 컨텍스트에 없다. `.claude/rules/*.md`는 세션 시작에 로드되고 프롬프트 캐시를 타므로, 매 턴