@simplysm/sd-claude 14.0.79 → 14.0.81

package/claude/skills/sd-impl/references/spec-cross-check.md

@@ -1,82 +0,0 @@
-# spec 대조 (subagent 위탁)
-
-sd-impl 6단계 진입 시 Read.
-
-## 목적
-
-spec ↔ 코드 대조를 셀프 검증이 아닌 독립 subagent 에 위탁. 같은 LLM 셀프 검증의 표면 훑기 편향 제거. 차이를 4분류로 받아 분류별 처리 분기.
-
-## subagent 호출
-
-- 도구: `Agent`
-- `subagent_type`: `general-purpose`
-- `description`: `sd-impl spec 대조`
-- `prompt`: 아래 입력 패키지 (그대로 복사 후 `<…>` 부분만 채움)
-
-## 입력 패키지 (prompt 템플릿)
-
-```
-sd-impl 의 spec ↔ 코드 독립 대조를 수행해줘.
-
-**대상**:
-- spec.md 경로: <절대경로>
-- 단위 식별자: <§4.x / §5.x / §6.x>
-
-**참조 자료**:
-
-(1) 4단계 spec 분해 표 (인라인):
-
-| 항목 | spec 인용 | 현재 코드 상태 | 판정 | 매핑 파일 | 의존 |
-| ---- | --------- | -------------- | ---- | --------- | ---- |
-| ... | ... | ... | ... | ... | ... |
-
-(2) 현재 구현 파일 목록 (절대경로):
-- <file1>
-- <file2>
-- ...
-
-**작업**:
-
-1. spec.md 의 §<단위> 본문 + 참조 §5/§6/§7/§8/§9 항목을 다시 읽는다.
-2. 현재 구현 파일을 모두 읽는다.
-3. spec ↔ 코드를 항목 단위로 1:1 대조 (단위 전체 대상. "이번 변경분만" 스코프 제한 없음).
-4. 차이 발견 시 아래 4분류로 보고:
-
-   - (a) **코드 위반**: spec 명확한데 코드가 빠뜨림·다름.
-   - (b) **spec 내부 모순**: §A 정의 vs §B 정의 충돌. (인용 둘 다 명시)
-   - (c) **spec 텍스트 오류 의심**: spec 문구가 실제 코드 동작과 어긋나는데 코드가 더 합리적.
-   - (d) **spec 미정의 + 코드 임의 채움**: spec 본문에 정의·분기·경계 케이스 명시 없는데 코드가 채움.
-
-5. 보고 형식 (각 차이 1건마다):
-
-   ### 차이 N: <도메인 어휘로 표현된 한줄 요약>
-   - 분류: (a) / (b) / (c) / (d)
-   - spec 위치: §X.x line Y
-   - spec 인용: "..."
-   - 코드 위치: <file:line>
-   - 코드 동작: <도메인 어휘로>
-   - 비고: (b)(c) 면 모순 상대 인용도 함께
-
-6. 차이 0건이면 `차이 없음, 검증 통과` 1줄만 응답.
-
-**제약**:
-
-- 코드 식별자(변수명·SQL 함수명·타입 키워드 등) 보고 본문 노출 금지. 모두 도메인 어휘로 풀 것.
-- "코드가 spec 위반" 으로 단정 금지. 4분류 중 어디인지 명시.
-- spec 본문에 인용 가능한 문구가 없으면 (b)(c)(d) 후보.
-
-**산출**: 위 4분류 보고 목록 또는 `차이 없음, 검증 통과`.
-```
-
-## 결과 처리 (sd-impl 메인 LLM)
-
-subagent 출력을 받은 후 분류별 처리:
-
-- **(a) 코드 위반**: 5단계 사이클 재진입. 코드 수정.
-- **(b) spec 내부 모순**: 사용자에게 1건씩 보고 (모순 양쪽 인용 포함) + 처리 방향 묻기 (sd-spec 이관 / 즉시 spec 일부 수정 후 진행 / 보류).
-- **(c) spec 텍스트 오류 의심**: 사용자에게 1건씩 보고 (spec 인용 + 코드 동작 + 어느 쪽이 합리적인지 의견) + 처리 방향 묻기 (sd-spec 이관 / spec 문구 정정 / 코드 정정).
-- **(d) spec 미정의 + 코드 임의 채움**: 사용자에게 1건씩 질문 → 결정 받기 → spec.md 인라인 반영 → 5단계 사이클 재진입.
-
-(b)(c)(d) 모두 한꺼번에 묶음 보고 금지. 1건씩 합의 (`sd-base-rules.md` "응답당 선택지 세트 1개" 적용).
-
-처리 완료 후 6단계 재실행 (재대조). 차이 0건 확인 후 7단계 진입.

package/claude/skills/sd-skill/evals/fixtures/with-existing-review/.claude/skills/review/SKILL.md

@@ -1,14 +0,0 @@
----
-name: review
-description: PR을 리뷰한다. Use when 사용자가 PR 또는 코드 변경사항에 대한 리뷰를 요청할 때
----
-
-# Review
-
-PR 또는 변경사항을 검토하고 피드백을 제공한다.
-
-## 워크 플로
-
-1. 변경사항 파악 - 어떤 파일이 어떻게 변경되었는지 확인
-2. 영향 범위 분석 - 변경이 다른 코드에 미치는 영향 검토
-3. 피드백 작성 - 개선 제안과 잠재적 이슈를 정리

package/claude/skills/sd-skill/references/eval-authoring.md

@@ -1,81 +0,0 @@
-# Eval 작성
-
-## 전제: 자동답변 환경
-
-Eval 실행 시 사용자 응답을 받을 수 없다. 대상 스킬은 입력이 필요한 모든 시점에 **스스로 답변**하며 끝까지 진행한다 (대화 흐름·산출물 형식 검증용). 케이스 설계는 이 제약을 전제로 한다.
-
-- **`input` 은 1턴짜리 사용자 발화**. 후속 응답을 가정하지 말 것.
-- **rubric 은 자체 답변 가능 영역만 검증**: 산출물 존재/형식/구조, 흐름 진행 여부, frontmatter 키 등. *"사용자가 X 를 골랐을 때 Y 가 나오는가"* 처럼 특정 사용자 응답 값에 의존하는 항목 금지 (자체 답변값이 매번 다를 수 있음).
-- **사용자 응답 발생 자체에 의존하는 rubric 금지**: 검증 대상 스킬이 "사용자에게 질문", "OPEN 처리/대기", "임의 채움 금지" 류 룰을 갖고 있어도, 그 룰의 발현 자체는 eval 로 검증 불가. 자동답변 환경은 사용자 답변을 즉시 생성해 진행하므로 "사용자 질문/대기" 흐름이 본질적으로 발생하지 않는다.
-  - 나쁜 예: `"사용자에게 질문하거나 OPEN 처리하는 흐름이 등장하는가"` (자체 답변으로 채운 뒤 진행 = 룰의 위반이 아니라 eval 환경의 정상 동작)
-  - 나쁜 예: `"임의 채움 흔적이 없는가"` (자체 답변 자체가 "임의 채움" 으로 보임)
-  - 대응: 케이스 자체를 재설계하거나, `input` 본문에 룰 강조 문장을 명시 (예: "모호 발견 시 OPEN 마커만 spec 에 박고 종료").
-- **fixture 는 자체 답변이 막히지 않게 구성**: 외부 시크릿·실시간 API 없이 진행 가능한 초기 상태로.
-
-## 근거 제약
-
-eval 입력/rubric 의 근거는 **검증 대상 SKILL.md (수정 시: 수정 후 버전) 명세뿐**. 이전 버전 동작·대화 메모리에 떠 있는 옛 컨텍스트는 인용 금지.
-
-- 검증 대상 명세에 없는 동작은 입력에도, rubric 에도 등장하지 않는다.
-- "이전 버전과 다르게 X 하는가" 형태의 negative rubric 금지. 현재 명세상 X 가 요구되면 `"X 하는가"` 로 직접 검증한다.
-
-## Golden 케이스 작성
-
-`evals/golden.jsonl` 에 한 줄당 한 케이스:
-
-```json
-{"id": "case-001", "input": "/<skill-name> ...", "rubric": ["체크 질문 1", "체크 질문 2"], "fixture": "<fixture-dir-name>"}
-```
-
-- `id`: 케이스 식별자.
-- `input`: 평가 대상 스킬에 전달할 사용자 입력.
-- `rubric`: PASS/FAIL 로 판정할 체크 질문 목록.
-- `fixture`: 케이스 시작 시점의 샌드박스 초기 상태 디렉토리 이름.
-
-**케이스 크기 제약**: 한 케이스가 요구하는 작업량이 단일 실행 컨텍스트를 소진할 정도로 크면 안 된다. eval 은 흐름·산출물 형식 검증이 목적이므로, 풀 구현·대량 분석을 요구하는 input 은 피하고 최소 시연 수준의 작업으로 좁힌다. 본질이 큰 풀구현 스킬은 input 의 평가 환경 단서로 rubric 검증에 불필요한 워크플로 단계를 명시 스킵한다.
-
-## Rubric 작성 요령
-
-각 항목은 **PASS/FAIL 로 판정 가능한 명확한 체크 질문**이어야 한다. 추상적 표현은 judge 가 매번 다르게 판단하므로 피한다.
-
-**모호한 부사·형용사 회피**: "잘", "적절히", "합리적으로", "명확히" 같은 표현은 기준이 사람마다 달라진다.
-
-- 나쁜 예: `"한국어 지원이 잘 되었는가?"` ("잘" 이 모호)
-- 좋은 예: `"본문에 한국어 응답 강제 지시가 명시적 문장으로 들어갔는가?"` (검증 기준 분명)
-
-**형식 검증을 선호하라**: 의미보다는 형식·존재 여부로 좁히면 judge 의 흔들림이 줄어든다.
-
-- 나쁜 예: `"description 이 트리거 조건을 명확히 표현하는가?"`
-- 좋은 예: `"description 끝에 'Use when ~' 형식 문장이 포함되었는가?"`
-
-**관찰 가능한 산출물에 묶어라**: 파일 존재, 특정 키 포함, 특정 디렉토리 구조 등 tree/events 에서 직접 확인 가능한 사실을 묻는다.
-
-- 좋은 예: `"기존 .claude/skills/review/SKILL.md 파일이 손실되지 않고 보존되었는가?"`
-- 좋은 예: `"SKILL.md 의 frontmatter 에 name 과 description 키가 모두 존재하는가?"`
-
-**명세 어휘 매칭 금지**: 명세에 등장하는 특정 단어를 rubric 에 그대로 박아 정확 매칭을 요구하지 말 것. LLM 응답은 동의어·다른 표현으로 동일 본질을 전달하므로, 어휘 정확 매칭은 본질-무관 FAIL 을 양산한다. rubric 은 본질(형식·구조·존재 여부)만 검증.
-
-- 나쁜 예: `"분해 표 첫 컬럼이 '항목' 인가"` (LLM 이 'ID'·'식별자' 로 출력해도 본질은 동일)
-- 좋은 예: `"분해 표가 마크다운 표 형식으로 출력되고 컬럼 6개가 모두 존재하는가"`
-
-**도구명 매칭 금지**: "events 에 특정 도구(Glob/Grep/Read 등) 호출이 있었는가" 는 그 도구의 사용 자체가 본질일 때만 사용. 본질이 "탐색·조사·읽기" 등 행위면 동등 효과의 다른 도구(Bash 의 ls/find/dir/cat 등)도 PASS 처리해야 한다.
-
-- 나쁜 예: `"events 에 Glob 또는 Grep 호출이 1회 이상 있는가"` (Bash ls/find 로 동등 효과인데 FAIL)
-- 좋은 예: `"events 에 코드베이스 탐색 흔적(Glob·Grep 호출 또는 Bash 의 ls/find/dir 등 동등 명령) 이 1회 이상 있는가"`
-
-## Fixtures 작성
-
-`evals/fixtures/<name>/` 는 케이스 시작 시점의 샌드박스 초기 상태이다. 케이스 실행 시 이 디렉토리가 통째로 샌드박스로 복사된다.
-
-- **빈 워크스페이스**: 디렉토리만 존재하면 됨 (`.gitkeep` 등으로 자리 표시).
-- **기존 스킬 수정 케이스**: 그 스킬의 SKILL.md 와 관련 파일을 미리 배치해 둔다.
-
-예시: `with-existing-review/.claude/skills/review/SKILL.md` — 케이스 시작 시 review 스킬이 이미 존재하는 상태.
-
-## 케이스 커버리지
-
-골든 셋은 단순 PASS 케이스 외에 다음 분기를 커버하면 회귀 감지가 강해진다:
-
-- 신규 작성 / 기존 수정 각각.
-- 워크플로의 주요 분기점 (예: 스크립트 필요/불필요, 참조 파일 분리 필요/불필요).
-- 과거에 실패한 패턴 — FAIL 케이스의 reason 분석 후 재발 방지용으로 추가한다.

package/claude/skills/sd-skill/references/eval-run.md

@@ -1,32 +0,0 @@
-# Eval 실행
-
-## 입력
-
-`python .claude/skills/sd-skill/scripts/run_eval.py <대상-스킬-이름>`
-
-대상 스킬에 `evals/golden.jsonl` + `evals/fixtures/<fixture-name>/` 가 있어야 한다.
-
-## 동작
-
-각 케이스마다:
-
-1. 격리된 작업 공간 준비 (`.claude/` 복사 + fixture 오버레이)
-2. 대상 스킬 실행. `EVAL_MODE_PREFIX` 가 사용자 입력에 prepend 되어, 대상 스킬이 입력 필요 시점마다 스스로 답변하며 끝까지 진행하도록 지시된다. 자체 답변은 사용자의 명시적 발언과 동등하게 취급된다 (다이얼로그 기반 스킬도 평가 가능, 단 자체 답변이라 흐름·형식 검증용)
-3. 에이전트 동작 기록과 종료 시점 파일 트리 수집
-4. 별도 평가 에이전트가 rubric 항목별 PASS/FAIL 채점 → 모두 PASS 시 케이스 PASS
-
-## 출력
-
-stdout: summary JSON
-- `run_id`, `results_dir`
-- `summary`: total / pass / fail / error
-- `cases[]`: 케이스별 verdict + 결과 dir 경로
-
-각 케이스 결과 파일 (`results_dir/cases/<id>/`):
-- `judge_output.json` — rubric 항목별 PASS/FAIL + reason
-- `events.json` — 에이전트 이벤트 시퀀스
-- `tree.json` — 샌드박스 종료 시 파일 트리
-
-## FAIL 분석
-
-위 결과 파일 읽어 reason 확인 → 스킬/eval 어느 쪽 문제인지 판단.

package/claude/skills/sd-skill/references/skill-authoring.md

@@ -1,70 +0,0 @@
-# 스킬 본문 작성
-
-## SKILL.md 템플릿
-
-```markdown
----
-name: skill-name
-description: 기능에 대한 간단한 설명. Use when [활용상황]
----
-
-# 스킬 이름
-
-## 워크플로
-
-[단계별 절차]
-```
-
-## description 작성
-
-description 은 에이전트의 라우팅 진입점이다. 에이전트가 description 을 읽고 사용자의 요청에 맞는 스킬을 골라 호출한다.
-
-**목표**: 에이전트가 다음 두 가지를 판단할 수 있을 만큼의 정보를 제공하라.
-
-1. 이 스킬의 목적은 무엇인가?
-2. 언제/왜 트리거 해야 하는가 (구체적인 맥락)
-
-다른 스킬들과 이 스킬을 구분할 단서를 에이전트에게 제공해야 한다.
-
-**형식**:
-
-- 최대 200자, 한 줄로 작성
-- 3인칭으로 작성
-- 첫 문장: 입력 → 산출물(또는 효과) 한 줄. 내부 처리 단계 금지.
-- 두 번째 문장: "Use when [활용상황]"
-
-**금지**: 내부 단계·알고리즘·사용 도구·로직 흐름은 description 에 쓰지 않는다 (그건 SKILL.md 본문 워크플로의 몫). description 은 외부에서 관찰 가능한 경계(입력·산출물·트리거 맥락)만 노출한다.
-
-## 스크립트를 추가해야 할 때
-
-다음의 경우에 유틸리티 스크립트를 추가하라:
-
-- 동작이 결정론(deterministic)적일 경우 (validation, formatting)
-- 코드 생성이 매번 동일할 경우
-- 에러를 명시적으로 처리해야 할 경우
-
-스크립트를 사용하면 언제나 토큰이 절약되고, 안정성이 개선된다.
-
-## 스크립트 작성 원칙
-
-- 스크립트는 Python(`.py`)으로 작성한다.
-- 스크립트 내부에서 에러를 처리하지 않는다. 에러는 즉시 throw 되어야 한다.
-
-## 파일을 분리해야 할 때
-
-다음의 경우에 별도 파일로 분리하라:
-
-- SKILL.md 분량이 에이전트가 한 자리에서 워크플로 흐름을 인식하기 어려울 만큼 디테일이 누적된 경우
-- 명백히 다른 도메인을 다루는 경우
-- 거의 사용되지 않는 고급 기능
-
-## SKILL.md 리뷰 체크리스트
-
-초안 작성 후 다음을 확인한다:
-
-- [ ] description 에 트리거가 포함되어 있는가? ("Use when ~")
-- [ ] description 에 내부 단계·알고리즘·도구가 들어가 있지 않은가?
-- [ ] SKILL.md 분량이 에이전트가 한 자리에서 워크플로를 인식할 수 있는가? (가이드: 100줄 이내)
-- [ ] 용어 사용이 일관적인가?
-- [ ] 구체적인 예시가 포함되어 있는가?
-- [ ] 참조 깊이가 한 단계인가? (SKILL.md → references/X.md 까지만 허용. references 파일 안에서 또 다른 파일을 참조하지 말 것)