@simplysm/sd-claude 14.0.78 → 14.0.80

package/claude/skills/sd-unpack/scripts/handlers/pdf_handler.py

@@ -36,6 +36,10 @@ def run(input_path: Path, out_dir: Path) -> None:
             ]
             if counts["tables"]:
                 parts.append(f"tables {counts['tables']} (cells {counts['table_cells']})")
+            if counts["form_fields"]:
+                parts.append(f"form_fields {counts['form_fields']}")
+            if counts["annotations"]:
+                parts.append(f"annotations {counts['annotations']}")
             page_summaries.append(" — ".join([parts[0], ", ".join(parts[1:])]))
 
         # 임베드된 첨부 (embedded files)
@@ -82,8 +86,17 @@ def _pdf_page_to_jsonl(
     추출:
     1. get_text("dict") 의 모든 블록 (text_block·image_block) — 표 영역 겹쳐도 그대로 보존
     2. find_tables() 로 표 셀 단위 노드 추가 (블록과 중복 가능, Claude 가 양쪽 비교 판단)
+    3. page.widgets() 로 form field 노드 (양식 입력란)
+    4. page.annots() 로 annotation 노드 (주석·highlight·sticky note)
     """
-    counts = {"text_blocks": 0, "image_blocks": 0, "tables": 0, "table_cells": 0}
+    counts = {
+        "text_blocks": 0,
+        "image_blocks": 0,
+        "tables": 0,
+        "table_cells": 0,
+        "form_fields": 0,
+        "annotations": 0,
+    }
 
     # 블록 추출 (모든 블록 보존)
     page_dict = page.get_text("dict")
@@ -100,16 +113,13 @@ def _pdf_page_to_jsonl(
             for line in blk.get("lines", []):
                 spans = line.get("spans", [])
                 line_text = "".join(span.get("text", "") for span in spans)
-                if line_text.strip():
-                    text_lines.append(line_text)
-            text = "\n".join(text_lines).strip()
-            if not text:
-                continue
+                text_lines.append(line_text)
+            text = "\n".join(text_lines)
             node_lines.append({
                 "page": page_num,
                 "block": block_idx,
                 "type": "text_block",
-                "bbox": [round(c, 2) for c in bbox],
+                "bbox": list(bbox),
                 "text": text,
             })
             counts["text_blocks"] += 1
@@ -127,7 +137,7 @@ def _pdf_page_to_jsonl(
                 "page": page_num,
                 "block": block_idx,
                 "type": "image_block",
-                "bbox": [round(c, 2) for c in bbox],
+                "bbox": list(bbox),
                 "ref": ref,
             })
             counts["image_blocks"] += 1
@@ -159,17 +169,75 @@ def _pdf_page_to_jsonl(
                     "table_bbox": t_bbox,
                     "row": r_idx,
                     "col": c_idx,
-                    "text": str(cell_text).strip(),
+                    "text": str(cell_text),
                 })
                 counts["table_cells"] += 1
 
+    # form fields (양식 입력란)
+    try:
+        widgets = page.widgets() or []
+        for widget in widgets:
+            try:
+                rect = list(widget.rect)
+            except Exception:
+                rect = [0, 0, 0, 0]
+            value = widget.field_value
+            if value is None:
+                value = ""
+            field_type = widget.field_type_string or str(widget.field_type)
+            name = widget.field_name or ""
+            node_lines.append({
+                "page": page_num,
+                "type": "form_field",
+                "name": name,
+                "field_type": field_type,
+                "value": str(value),
+                "bbox": rect,
+            })
+            counts["form_fields"] += 1
+    except Exception:
+        pass
+
+    # annotations (주석·highlight·sticky note 등)
+    try:
+        annots = page.annots() or []
+        for annot in annots:
+            try:
+                rect = list(annot.rect)
+            except Exception:
+                rect = [0, 0, 0, 0]
+            atype = annot.type
+            subtype = atype[1] if isinstance(atype, (tuple, list)) and len(atype) > 1 else str(atype)
+            info = annot.info or {}
+            node = {
+                "page": page_num,
+                "type": "annotation",
+                "subtype": subtype,
+                "bbox": rect,
+            }
+            content = info.get("content")
+            if content:
+                node["content"] = content
+            author = info.get("title")  # info["title"] = author
+            if author:
+                node["author"] = author
+            subject = info.get("subject")
+            if subject:
+                node["subject"] = subject
+            node_lines.append(node)
+            counts["annotations"] += 1
+    except Exception:
+        pass
+
     meta = {
         "_meta": {
             "page": page_num,
-            "size": [round(page.rect.width, 2), round(page.rect.height, 2)],
+            "size": [page.rect.width, page.rect.height],
             "blocks": counts["text_blocks"] + counts["image_blocks"],
             "tables": counts["tables"],
             "table_cells": counts["table_cells"],
+            "form_fields": counts["form_fields"],
+            "annotations": counts["annotations"],
         }
     }
     lines = [json.dumps(meta, ensure_ascii=False)]

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@simplysm/sd-claude",
-  "version": "14.0.78",
+  "version": "14.0.80",
   "description": "심플리즘 패키지 - Claude Code 셋업",
   "author": "심플리즘",
   "license": "Apache-2.0",

package/claude/output-styles/sd-tone.md

@@ -1,128 +0,0 @@
----
-name: sd-tone
-description: simplysm 워크스페이스 기본 톤·표현 규칙
-keep-coding-instructions: true
----
-
-# 톤·표현 규칙
-
-**적용**: 모든 응답 + 산출물(spec.md·문서·코드 주석 등 Write/Edit 본문).
-
-**자가 점검** (매 응답·Write/Edit 직전):
-
-- 압축 룰을 적용했는가?
-- 한국어 모국어 사용자가 한 번 읽고 흐름대로 이해되는가?
-
-## 도메인 어휘로 풀이
-
-- 산출물 소비자의 도메인 어휘로 응답.
-- 시스템 내부 용어 회피.
-- 간결·명확.
-- 다음은 단독 노출 금지 — 옆에 의미 동반 또는 도메인 어휘·시나리오로 풀이:
-  - 식별자 — 실제 의미를 옆에 표기 (원본 없이도 문장만으로 의미 전달):
-    - 코드 심볼
-    - 영문 변수명·함수명 (예: `surplus`·`isCompleted`·`joinSingle`)
-    - 약어·라벨
-    - 번호·§번호
-  - 수식·계산식 (예: `(A − B) − C`) — 값 대입 시나리오 1건 동반
-  - SQL·프레임워크·구현 용어 (예: "LEFT JOIN 깊이 1 자르기"·"subagent 위탁") — 도메인 흐름으로 풀이
-- "이해 못함"·"무슨 소리야" 피드백 시 같은 내용 반복 X. 도메인 시나리오로 재풀이.
-
-## 응답·산출물 표현
-
-**구조 선호** (산문체 회피·세로 정돈):
-
-- 2개 이상의 정보·예시·항목은 라벨/헤더 + bullet 으로. 줄글로 풀지 말 것.
-- 한 bullet 안 열거가 3개 이상이거나 한 줄이 시각적으로 길면 sub-bullet 으로 세로 분리.
-  - 예외: 짧은 토큰(부연 없는 단어급)만의 묶음은 시각적 길이 기준만 적용.
-- 라벨/헤더 뒤 부연이 두 절(clause) 이상이면 bullet 으로 분리.
-
-**압축 룰**:
-
-- 어미·조사 압축 — "~할 수도 있을 것 같습니다" → "~ 가능"
-- 접속어 제거. 인과는 화살표 `X → Y` 로 표현. 예시 접속어:
-  - 인과: 그래서·따라서
-  - 대등·역접: 또한·하지만
-- 1단어 가능 시 1단어
-- preamble·sign-off 금지. 예시:
-  - 인사
-  - 작업 개시
-  - 마무리
-- 키워드+기호 구조 권장 — `원인: X → Y` · `해결: Z`
-- 중복 bullet 병합
-
-**절대 보존** (압축·약어화·재서술 X):
-
-- 코드 심볼·함수명
-- API명·에러 문자열
-- URL·파일경로
-- 명령어
-- 기술 용어·고유명사
-- 날짜·버전
-- 숫자·환경변수
-- 사용자 발언 verbatim 인용
-- 도메인 어휘 (위 "도메인 어휘로 풀이" 룰)
-- 구조 (보존하고 안의 텍스트만 압축 룰 적용):
-  - 헤딩
-  - bullet 계층·numbered
-  - 표·frontmatter
-  - 질문 구조 `[맥락+선택지+추천+질문]`
-
-**압축 미적용 조건** (표준 톤 응답):
-
-- 보안 경고·되돌릴 수 없는 작업 컨펌
-- 다단계 시퀀스에서 압축이 오독 위험
-- 압축 자체가 기술 모호함 생성
-
-## 한국어 가독성 가드
-
-원칙:
-
-- 압축 강도 유지.
-- 영어 직역체로 인한 가독성 저하만 차단.
-
-**직역체 회피**:
-
-- 어순 — 한국어 SOV: 중요 정보·결론은 문장 뒤.
-- 수동태 — `X 가 Y 에 의해 Z 되었다` → `Y 가 X 를 Z 했다`.
-- 직역 패턴:
-  - `~에 의해(서)` → 주어를 능동형으로
-  - `~에 대하여`·`~에 관하여` → 생략 또는 `~을/를`
-  - `~로부터` → `~에서`
-  - `~을 통해` → `~로`·`~으로써`·동사로 풀이
-  - `~에 있어` → `~에`·`~에서`
-  - `~하기 위해` → `~하려고`·`~할`
-  - `~로 인해` → `~때문에`
-  - `~의 경우` (첫머리) → `~는/은`·생략
-  - `X 를 가진`·`가지고 있다` → `X 가 있다`·`X 다`
-  - `~하는 중이다` → 현재형
-  - `~에도 불구하고` → `~지만`·`~인데도`
-  - `위치하다` → `있다`
-
-**남용 회피**:
-
-- 대명사 (그·그것·그녀·그들) — 명사 반복 또는 생략
-- 복수 표지 `들` — 한국어는 단수형으로 다수 표현 가능
-- `의` — 띄어쓰기 가능 시 생략
-
-**허용**:
-
-- 일상 한국어 단어 — 일상에 정착한 압축어(예: `비추`) 포함
-- 명사구 종결 — 압축 일관성 유지
-
-## ASCII 그림
-
-적용 대상 — 모든 ASCII 그림:
-
-- 다이어그램
-- 구성도
-- 와이어프레임 등
-
-룰:
-
-- 이모지(✏ ☐ ❌ ⭐ ♥ 등) 금지 — 렌더러별 1칸/2칸 변동 → 정렬 깨짐.
-- 그 외 폭 안정 문자 허용:
-  - ASCII·한글
-  - 박스 라인 ┌─┐ │ └┘ ├┤
-  - 도형 ▲ ▼ ► ◄
-  - 화살표 ← → ↑ ↓

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/evals/golden.jsonl

@@ -1,5 +0,0 @@
-{"id": "create-basic-001", "input": "/sd-skill 현재 디렉토리의 README.md 가 'Title', 'Description', 'Installation', 'Usage' 4개 섹션을 모두 포함하는지 검증하는 스킬을 만들어줘", "rubric": [".claude/skills/ 아래에 새 스킬 디렉토리가 정확히 하나 생성되었고 그 안에 SKILL.md 가 존재하는가?", "SKILL.md 의 frontmatter 가 '---' 로 감싸져 있고 'name', 'description' 키가 모두 존재하며 'name' 값이 디렉토리명과 정확히 일치하는가?", "frontmatter 의 description 에 'Use when' 문구가 포함되어 있는가?", "SKILL.md 본문이 100줄 이내인가?", "생성된 스킬의 evals/golden.jsonl 파일이 존재하고, 모든 라인이 유효한 JSON 이며 각 라인이 id/input/rubric/fixture 4개 키를 모두 포함하는가?", "golden.jsonl 의 각 케이스가 참조하는 fixture 명과 동일한 이름의 디렉토리가 evals/fixtures/<name>/ 경로에 실제로 존재하는가?", "에이전트의 events 에 Bash 도구로 'run_eval.py' 를 실행하려는 호출이 1회 이상 존재하는가?"], "fixture": "empty"}
-{"id": "create-with-script-001", "input": "/sd-skill SKILL.md frontmatter 가 유효한지(name 키 존재, description 키 존재, description 에 'Use when' 포함, 본문 100줄 이내) 결정론적으로 검증하는 스킬을 만들어줘", "rubric": [".claude/skills/ 아래에 새 스킬 디렉토리가 정확히 하나 생성되었고 그 안에 SKILL.md 가 존재하는가?", "SKILL.md 의 frontmatter 에 'name', 'description' 키가 모두 존재하며 description 에 'Use when' 문구가 포함되는가?", "스킬 디렉토리 아래 scripts/ 폴더가 존재하고 그 안에 .py 또는 .sh 파일이 1개 이상 존재하는가?", "SKILL.md 본문에서 scripts/ 아래 추가된 스크립트 파일 경로 또는 파일명을 명시적으로 참조(언급)하는가?", "스크립트 본문에 frontmatter 의 'name' 또는 'description' 키 존재 여부를 검사하는 로직(문자열 검색이든 파싱이든)이 포함되어 있는가?", "생성된 스킬의 evals/golden.jsonl 과 evals/fixtures/<name>/ 디렉토리가 골든셋과 정합성 있게 존재하는가?"], "fixture": "empty"}
-{"id": "modify-rule-add-001", "input": "/sd-skill review 스킬에 응답을 항상 한국어로 하라는 강제 조건을 추가해줘", "rubric": [".claude/skills/review/SKILL.md 파일이 여전히 존재하는가?", "수정 후 SKILL.md 의 frontmatter 'name' 값이 'review' 로 유지되어 있는가?", "기존 워크플로 항목 표현 3개('변경사항 파악', '영향 범위 분석', '피드백 작성') 가 SKILL.md 본문에 모두 그대로 남아있는가?", "한국어 응답을 강제하는 새 지시 문장이 SKILL.md 본문에 추가되었는가? (본문에 '한국어' 키워드를 포함하는 강제 어조의 문장 1개 이상)"], "fixture": "with-existing-review"}
-{"id": "modify-add-script-001", "input": "/sd-skill review 스킬에 'git diff origin/main...HEAD' 로 변경 파일 목록과 diff 본문을 자동으로 가져오는 스크립트를 추가하고, SKILL.md 워크플로에서 그 스크립트를 사용하도록 갱신해줘", "rubric": [".claude/skills/review/SKILL.md 파일이 여전히 존재하고 frontmatter 의 'name' 값이 'review' 로 유지되는가?", "기존 워크플로 항목 표현 3개('변경사항 파악', '영향 범위 분석', '피드백 작성') 가 SKILL.md 본문에 모두 그대로 남아있는가?", ".claude/skills/review/scripts/ 디렉토리가 새로 생성되었고 그 안에 'git diff' 문자열을 포함하는 스크립트 파일이 1개 이상 존재하는가?", "수정된 SKILL.md 본문에서 새로 추가한 스크립트 파일을 사용/실행하라는 안내 문장이 추가되었는가? (스크립트 파일명 또는 'scripts/' 경로를 본문에서 언급)"], "fixture": "with-existing-review"}
-{"id": "create-large-split-001", "input": "/sd-skill PR 코드리뷰 가이드 스킬을 만들어줘. 다음 4개 영역의 상세 체크리스트와 각 영역별 코드 예시 3개를 포함해야 한다: (1) 보안(SQL injection, XSS, CSRF), (2) 성능(N+1, 메모리 누수, 캐싱), (3) 테스트 커버리지(단위/통합/E2E), (4) DB 마이그레이션 안전성.", "rubric": [".claude/skills/ 아래에 새 스킬 디렉토리가 정확히 하나 생성되었고 그 안에 SKILL.md 가 존재하는가?", "SKILL.md frontmatter 에 'name', 'description' 키가 모두 존재하고 description 에 'Use when' 문구가 포함되는가?", "SKILL.md 본문이 100줄 이내인가? (sd-skill 분리 룰: 100줄 초과 시 references/ 로 분리해야 함)", "스킬 디렉토리 아래 references/ 폴더가 존재하고 그 안에 .md 파일이 1개 이상 존재하는가?", "SKILL.md 본문에서 references/ 폴더의 파일 1개 이상을 마크다운 링크 또는 경로 문자열로 명시적으로 참조하는가?", "생성된 스킬의 evals/golden.jsonl 과 evals/fixtures/<name>/ 디렉토리가 골든셋과 정합성 있게 존재하는가?"], "fixture": "empty"}

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 파일 안에서 또 다른 파일을 참조하지 말 것)