@simplysm/sd-claude 14.0.82 → 14.0.83

package/claude/skills/sd-skill/SKILL.md

@@ -5,9 +5,9 @@ description: 사용자가 정의한 작업 도메인을 SKILL.md + (필요 시)
 
 # 스킬 작성
 
-워크플로 = 아래 § 1~5 순서. 처음부터 끝까지 읽으며 그대로 수행.
+워크플로 = 아래 "1단계 ~ 5단계" 순서로 처음부터 끝까지 읽으며 그대로 수행.
 
-사용자 질문 시점 = § 1 의도 합의 + § 2 case `input` 발화 선택. § 2~5 의 그 외는 § 1 합의 기반 자동 진행, 부족 발견 시 § 1 회귀.
+사용자에게 질문하는 시점 = 1단계(의도 정의)의 의도 합의 + 2단계(Eval 케이스 정의)의 case `input` 발화 선택. 2~5단계의 그 외 작업은 1단계 합의를 기반으로 자동 진행, 부족 발견 시 1단계로 회귀.
 
 ## 1단계. 의도 정의
 
@@ -15,7 +15,7 @@ description: 사용자가 정의한 작업 도메인을 SKILL.md + (필요 시)
 
 - 스킬 목적은? (한 줄 동사형) + 커버 유즈케이스는?
 - 주요 사용자 입력 시나리오는? (호출 트리거 발화 형태)
-- 핵심 산출물은? (생성·수정 대상 파일·디렉토리 형태) — § 2 rubric 형식 검증 근거
+- 핵심 산출물은? (생성·수정 대상 파일·디렉토리 형태) — 2단계(Eval 케이스 정의)의 rubric 형식 검증 근거
 - 실행 스크립트 필요 / 지침만으로 충분?
 - 함께 포함할 참고 자료?
 
@@ -25,23 +25,23 @@ description: 사용자가 정의한 작업 도메인을 SKILL.md + (필요 시)
 
 ### 자동답변 환경
 
-Eval 실행 시 사용자 응답 불가. 대상 스킬은 입력 필요 시점마다 **스스로 답변**하며 끝까지 진행 (대화 흐름·산출물 형식 검증용). 케이스 설계는 이 제약 전제.
+Eval(자동 평가) 실행 시 사용자 응답 불가. 대상 스킬은 입력 필요 시점마다 **스스로 답변**하며 끝까지 진행 (대화 흐름·산출물 형식 검증용). 케이스 설계는 이 제약을 전제로 함.
 
-- `input` = 1턴 사용자 발화. 후속 응답 가정 X.
-- rubric = 자체 답변 가능 영역만 검증: 산출물 존재/형식/구조·흐름 진행 여부·frontmatter 키 등. *"사용자가 X 를 골랐을 때 Y 가 나오는가"* 처럼 특정 사용자 응답 값 의존 항목 금지 (자체 답변값은 매번 다름).
-- **사용자 응답 발생 자체 의존 rubric 금지**: 대상 스킬이 "사용자 질문"·"OPEN 처리/대기"·"임의 채움 금지" 룰 보유해도, 룰 발현 자체는 Eval 검증 불가. 자동답변 환경은 사용자 답변 즉시 생성·진행 → "사용자 질문/대기" 흐름 본질적으로 미발생.
+- `input` = 1턴 사용자 발화. 후속 응답 가정 안 함.
+- rubric(채점 항목) = 자체 답변 가능 영역만 검증: 산출물 존재 여부·형식·구조, 흐름 진행 여부, frontmatter 키 존재 여부 등. *"사용자가 X 를 골랐을 때 Y 가 나오는가"* 처럼 특정 사용자 응답 값에 의존하는 항목 금지 (자체 답변값은 매번 달라짐).
+- **사용자 응답 발생 자체에 의존하는 rubric 금지**: 대상 스킬이 "사용자 질문"·"OPEN 처리/대기"·"임의 채움 금지" 룰을 보유해도, 룰 발현 자체는 Eval 검증 불가. 자동답변 환경은 사용자 답변을 즉시 생성·진행 → "사용자 질문/대기" 흐름 본질적으로 발생하지 않음.
   - ❌ `"사용자에게 질문하거나 OPEN 처리하는 흐름이 등장하는가"` (자체 답변으로 채운 뒤 진행 = 위반 아니라 환경 정상 동작).
   - ❌ `"임의 채움 흔적이 없는가"` (자체 답변 자체가 "임의 채움" 으로 보임).
   - 대응: 케이스 재설계 또는 `input` 본문에 룰 강조 명시 (예: "모호 발견 시 보류 마커만 산출물에 박고 종료").
-- fixture = 자체 답변 미차단되게 구성. 외부 시크릿·실시간 API 없이 진행 가능한 초기 상태로.
+- fixture = 자체 답변이 차단되지 않게 구성. 외부 시크릿·실시간 API 없이 진행 가능한 초기 상태로.
 
 ### 근거 제약
 
-Eval 입력/rubric 의 근거 = **§ 1 에서 합의된 의도뿐**. 이전 버전 동작·대화 메모리의 옛 컨텍스트, **타 스킬의 `evals/golden.jsonl` rubric** 인용 금지.
+Eval 입력 및 rubric 의 근거 = **1단계(의도 정의)에서 합의된 의도뿐**. 이전 버전 동작·대화 메모리의 옛 맥락, **타 스킬의 `evals/golden.jsonl` rubric** 인용 금지.
 
-- 합의된 의도에 없는 동작 → 입력·rubric 둘 다 등장 X.
-- "이전 버전과 다르게 X 하는가" negative rubric 금지. 현재 의도상 X 요구 → `"X 하는가"` 로 직접 검증.
-- **타 스킬 rubric 답습 금지**: 비슷한 도메인 스킬이라도 rubric 은 본 스킬 § 1 에서 합의된 의도에서 직접 도출. 타 스킬 rubric 을 참고용으로 열어보는 것도 X (복제 유혹 차단).
+- 합의된 의도에 없는 동작은 입력·rubric 둘 다 등장 금지.
+- "이전 버전과 다르게 X 하는가" 형태의 부정형(negative) rubric 금지. 현재 의도상 X 가 요구되면 `"X 하는가"` 로 직접 검증.
+- **타 스킬 rubric 답습 금지**: 비슷한 도메인의 스킬이라도 rubric 은 본 스킬의 1단계에서 합의된 의도에서 직접 도출. 타 스킬 rubric 을 참고용으로 열어보는 것도 금지 (복제 유혹 차단).
 
 ### 골든 케이스
 
@@ -52,22 +52,22 @@ Eval 입력/rubric 의 근거 = **§ 1 에서 합의된 의도뿐**. 이전 버
 ```
 
 - `id`: 케이스 식별자.
-- `input`: 평가 대상 스킬에 전달할 사용자 입력. § 1 시나리오 기반으로 LLM 이 발화 후보 제시 → 사용자 선택.
+- `input`: 평가 대상 스킬에 전달할 사용자 입력. 1단계의 시나리오를 기반으로 LLM 이 발화 후보를 제시한 뒤 사용자가 선택.
 - `rubric`: PASS/FAIL 판정 항목 목록.
-- `fixture`: 케이스 시작 시점 샌드박스 초기 상태 디렉토리 이름.
+- `fixture`: 케이스 시작 시점의 샌드박스 초기 상태 디렉토리 이름.
 
-**케이스 크기**: 한 케이스 작업량이 단일 실행 컨텍스트 소진 정도로 크면 X. Eval = 흐름·산출물 형식 검증 목적 → 풀 구현·대량 분석 요구 input 회피, 최소 시연 수준으로 좁힘. 본질이 큰 풀구현 스킬은 input 의 평가 환경 단서로 rubric 검증에 불필요한 워크플로 단계를 명시 스킵.
+**케이스 크기**: 한 케이스의 작업량이 단일 실행 컨텍스트를 소진할 정도로 크면 안 됨. Eval 목적 = 흐름·산출물 형식 검증 → 풀 구현·대량 분석을 요구하는 input 은 회피하고 최소 시연 수준으로 좁힘. 본질이 큰 풀 구현 스킬의 경우, input 에 평가 환경임을 알리는 단서를 포함해 rubric 검증에 불필요한 워크플로 단계를 명시적으로 건너뛰게 함.
 
 ### Rubric 작성
 
-각 항목 = **PASS/FAIL 판정 가능한 명확한 검증 항목**. 추상 표현 → judge 판단 흔들림 → 회피.
+각 항목은 **PASS/FAIL 판정이 가능한 검증 항목**으로 작성. 추상 표현은 judge(채점 에이전트) 판단이 흔들리므로 회피.
 
 **모호 부사·형용사 회피** ("잘"·"적절히"·"합리적으로"·"명확히" → 기준이 사람마다 다름):
 
 - ❌ `"한국어 지원이 잘 되었는가?"` ("잘" 모호).
 - ✅ `"본문에 한국어 응답 강제 지시가 명시적 문장으로 들어갔는가?"`.
 
-**형식 검증 선호** (의미보다 형식·존재 여부 → judge 흔들림 ↓):
+**형식 검증 선호** (의미보다 형식·존재 여부 기준으로 작성하면 judge 흔들림이 줄어듦):
 
 - ❌ `"description 이 트리거 조건을 명확히 표현하는가?"`.
 - ✅ `"description 끝에 'Use when ~' 형식 문장이 포함되었는가?"`.
@@ -77,36 +77,36 @@ Eval 입력/rubric 의 근거 = **§ 1 에서 합의된 의도뿐**. 이전 버
 - ✅ `"기존 .claude/skills/review/SKILL.md 파일이 손실되지 않고 보존되었는가?"`.
 - ✅ `"SKILL.md frontmatter 에 name·description 키 모두 존재하는가?"`.
 
-**명세 어휘 매칭 금지**: 명세 특정 단어를 rubric 에 그대로 박아 정확 매칭 요구 X. LLM 응답은 동의어·다른 표현으로 동일 본질 전달 → 어휘 정확 매칭 = 본질-무관 FAIL 양산. rubric 은 본질(형식·구조·존재 여부)만 검증.
+**명세 어휘 매칭 금지**: 명세의 특정 단어를 rubric 에 그대로 박아 정확 매칭을 요구하지 말 것. LLM 응답은 동의어·다른 표현으로 동일 본질을 전달하므로, 어휘 정확 매칭은 본질과 무관한 FAIL 을 양산함. rubric 은 본질(형식·구조·존재 여부)만 검증.
 
 - ❌ `"분해 표 첫 컬럼이 '항목' 인가"` (LLM 이 'ID'·'식별자' 로 출력해도 본질 동일).
 - ✅ `"분해 표가 마크다운 표 형식으로 출력되고 컬럼 6개 모두 존재하는가"`.
 
-**도구명 매칭 금지**: "events 에 특정 도구(Glob/Grep/Read 등) 호출이 있는가" 는 그 도구 사용 자체가 본질일 때만. 본질이 "탐색·조사·읽기" 등 행위면 동등 효과의 다른 도구(Bash 의 ls/find/dir/cat 등) 도 PASS.
+**도구명 매칭 금지**: "events(에이전트 이벤트 시퀀스)에 특정 도구(Glob/Grep/Read 등) 호출이 있는가" 형태의 rubric 은 그 도구 사용 자체가 본질일 때만 사용. 본질이 "탐색·조사·읽기" 등 행위라면 동등한 효과를 내는 다른 도구(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>/` = 케이스 시작 시점 샌드박스 초기 상태. 케이스 실행 시 통째로 샌드박스 복사.
+`evals/fixtures/<name>/` 디렉토리는 케이스 시작 시점의 샌드박스 초기 상태. 케이스 실행 시 샌드박스로 통째로 복사됨.
 
-- **빈 워크스페이스**: 디렉토리만 (`.gitkeep` 등 자리 표시).
-- **기존 스킬 수정 케이스**: 그 스킬의 SKILL.md + 관련 파일 미리 배치.
+- **빈 워크스페이스**: 디렉토리만 둠 (`.gitkeep` 등으로 자리 표시).
+- **기존 스킬 수정 케이스**: 그 스킬의 SKILL.md 및 관련 파일을 미리 배치.
 
-예: `with-existing-review/.claude/skills/review/SKILL.md` — 케이스 시작 시 review 스킬 기존 존재 상태.
+예: `with-existing-review/.claude/skills/review/SKILL.md` — 케이스 시작 시 review 스킬이 이미 존재하는 상태.
 
 ### 케이스 커버리지
 
-골든 셋이 단순 PASS 외 다음 분기 커버 시 회귀 감지 강화:
+골든 셋이 단순 PASS 외에 다음 분기를 커버하면 회귀 감지가 강화됨:
 
-- 신규 작성 / 기존 수정 각각.
+- 신규 작성 케이스와 기존 수정 케이스 각각.
 - 워크플로 주요 분기점 (예: 스크립트 필요/불필요, 참조 파일 분리 필요/불필요).
-- 과거 실패 패턴 — FAIL 케이스 reason 분석 후 재발 방지용 추가.
+- 과거 실패 패턴 — FAIL 케이스의 reason(실패 사유)을 분석한 뒤 재발 방지용으로 추가.
 
 ## 3단계. 스킬 작성
 
-간결·명확한 SKILL.md + 별도 참고 파일 (필요 시) + 유틸리티 스크립트 (필요 시).
+간결·명확한 SKILL.md 와 별도 참고 파일(필요 시), 유틸리티 스크립트(필요 시)로 구성.
 
 ### 디렉토리 구조
 
@@ -138,9 +138,9 @@ description: 기능 설명. Use when [활용상황]
 
 본문은 다음 "본문 작성 원칙" 따름.
 
-### description
+### description (frontmatter 의 description 필드)
 
-에이전트의 라우팅 진입점. 에이전트가 description 으로 사용자 요청에 맞는 스킬 호출.
+에이전트의 라우팅 진입점. 에이전트가 description 을 보고 사용자 요청에 맞는 스킬을 호출함.
 
 **전달 정보**:
 
@@ -150,47 +150,47 @@ description: 기능 설명. Use when [활용상황]
 
 **형식**:
 
-- 최대 200자, 한 줄.
-- 3인칭.
-- 첫 문장: 입력 → 산출물(또는 효과). 내부 처리 단계 금지.
-- 두 번째 문장: "Use when [활용상황]".
+- 최대 200자, 한 줄로 작성.
+- 3인칭으로 작성.
+- 첫 문장: 입력에서 산출물(또는 효과)로의 변환을 기술. 내부 처리 단계 기술 금지.
+- 두 번째 문장: "Use when [활용상황]" 형식.
 
-**금지**: 내부 단계·알고리즘·사용 도구·로직 흐름 → SKILL.md 본문 워크플로의 몫. description 은 외부 관찰 경계(입력·산출물·트리거)만 노출.
+**금지**: 내부 단계·알고리즘·사용 도구·로직 흐름은 SKILL.md 본문 워크플로의 몫. description 은 외부에서 관찰 가능한 경계(입력·산출물·트리거)만 노출.
 
 ### 본문 작성 원칙
 
-YAGNI — § 2 케이스가 통과되는 최소 본문만. 케이스가 검증하지 않는 절·예시·옵션 추가 X.
+YAGNI(You Aren't Gonna Need It) 원칙 — 2단계 케이스가 통과되는 최소 본문만 작성. 케이스가 검증하지 않는 절·예시·옵션 추가 금지.
 
-- **워크플로 단위 어휘 통일**: "사이클" (반복형) 또는 "단계" (순차형) 중 선택해 본문 전체 일관.
-- **본문 어휘 일관**: 같은 개념은 같은 단어로. 동의어 혼용 X.
-- **자가검증 게이트** (해당 시): 출력 직전 자문 항목을 본문에 명시 — 스킬 고유 형식·근거·단순화 차단 점검.
-- **모범 예시 인용** (해당 시): 형식 따라야 할 산출물 있으면 `references/example-X.md` 보관 + 본문에서 한 줄 참조.
-- **도구명 박기 금지**: 본문에 Glob·Grep 등 도구명 직접 박지 X. "코드베이스 탐색"·"파일 읽기" 등 동등 행위 표현 (§ 2 rubric "도구명 매칭 금지" 와 일관).
+- **워크플로 단위 어휘 통일**: "사이클"(반복형) 또는 "단계"(순차형) 중 하나를 선택해 본문 전체에서 일관 사용.
+- **본문 어휘 일관**: 같은 개념은 같은 단어로 표기. 동의어 혼용 금지.
+- **스스로 검증 게이트**(해당 시): 출력 직전 자문 항목을 본문에 명시하여 스킬 고유의 형식·근거·단순화 차단을 점검.
+- **모범 예시 인용**(해당 시): 형식을 따라야 할 산출물이 있으면 `references/example-X.md` 에 보관하고 본문에서 한 줄로 참조.
+- **도구명 박기 금지**: 본문에 Glob·Grep 등 도구명을 직접 박지 않음. "코드베이스 탐색"·"파일 읽기" 등 동등한 행위 표현으로 작성 (2단계 rubric 의 "도구명 매칭 금지" 와 일관).
 
 ### 스크립트 추가 기준
 
-다음 시 유틸리티 스크립트 추가:
+다음 조건에 해당하면 유틸리티 스크립트 추가:
 
-- 동작이 결정론(deterministic)적 (validation·formatting).
-- 코드 생성이 매번 동일.
-- 에러 명시 처리 필요.
+- 동작이 결정론적(deterministic)인 경우 (validation·formatting 등).
+- 코드 생성 결과가 매번 동일한 경우.
+- 에러를 명시적으로 처리해야 하는 경우.
 
-스크립트 → 토큰 절약 + 안정성 개선.
+스크립트는 토큰 절약과 안정성 개선에 기여.
 
 **작성 원칙**:
 
 - Python(`.py`) 으로 작성.
-- 내부 에러 처리 X. 에러 즉시 throw.
+- 내부 에러 처리 금지. 에러는 즉시 throw.
 
 ### 파일 분리 기준
 
-다음 시 별도 파일 분리:
+다음 조건에 해당하면 별도 파일로 분리:
 
-- SKILL.md 분량이 에이전트가 한 자리에서 워크플로 흐름 인식 어려울 만큼 누적.
-- 명백히 다른 도메인.
-- 거의 안 쓰는 고급 기능.
+- SKILL.md 분량이 에이전트가 한 자리에서 워크플로 흐름을 인식하기 어려울 만큼 누적된 경우.
+- 명백히 다른 도메인을 다루는 경우.
+- 거의 사용되지 않는 고급 기능인 경우.
 
-**참조 깊이 한 단계**: SKILL.md → `references/X.md` 까지만. references 파일 안에서 또 다른 파일 참조 X.
+**참조 깊이 한 단계 제한**: SKILL.md 에서 `references/X.md` 까지만 참조 허용. references 파일 안에서 또 다른 파일을 참조하는 것 금지.
 
 ## 4단계. Eval 실행
 
@@ -198,48 +198,48 @@ YAGNI — § 2 케이스가 통과되는 최소 본문만. 케이스가 검증
 
 `python .claude/skills/sd-skill/scripts/run_eval.py <대상-스킬-이름>`.
 
-대상 스킬에 `evals/golden.jsonl` + `evals/fixtures/<fixture-name>/` 필요.
+대상 스킬에 `evals/golden.jsonl` 과 `evals/fixtures/<fixture-name>/` 가 모두 존재해야 함.
 
 ### 동작
 
-케이스마다:
+케이스마다 다음 순서로 실행:
 
-1. 격리 작업 공간 준비 (`.claude/` 복사 + fixture 오버레이).
-2. 대상 스킬 실행. `EVAL_MODE_PREFIX` 가 사용자 입력 앞에 붙어, 대상 스킬이 입력 필요 시점마다 스스로 답변하며 끝까지 진행하도록 지시. 자체 답변은 사용자 명시 발언과 동등 취급 (다이얼로그 기반 스킬도 평가 가능, 단 자체 답변이라 흐름·형식 검증용).
-3. 에이전트 동작 기록 + 종료 시점 파일 트리 수집.
-4. 별도 평가 에이전트가 rubric 항목별 PASS/FAIL 채점 → 모두 PASS 시 케이스 PASS.
+1. 격리 작업 공간 준비 (`.claude/` 복사 후 fixture 오버레이).
+2. 대상 스킬 실행. `EVAL_MODE_PREFIX`(자동 평가 모드 안내 문구)가 사용자 입력 앞에 붙어, 대상 스킬이 입력 필요 시점마다 스스로 답변하며 끝까지 진행하도록 지시. 자체 답변은 사용자의 명시적 발언과 동등하게 취급됨 (다이얼로그 기반 스킬도 평가 가능. 단, 자체 답변이므로 흐름·형식 검증용으로 한정).
+3. 에이전트 동작 기록 및 종료 시점의 파일 트리 수집.
+4. 별도의 평가 에이전트가 rubric 항목별로 PASS/FAIL 을 채점하고, 모든 항목이 PASS 일 때 케이스 PASS 로 판정.
 
 ### 출력 구조
 
-stdout: summary JSON.
+stdout 으로 summary JSON 출력. 포함 필드는 다음과 같음.
 
 - `run_id`, `results_dir`.
-- `summary`: total / pass / fail / error.
-- `cases[]`: 케이스별 verdict + 결과 dir 경로.
+- `summary`: total / pass / fail / error 카운트.
+- `cases[]`: 케이스별 verdict(판정 결과)와 결과 디렉토리 경로.
 
 각 케이스 결과 파일 (`results_dir/cases/<id>/`):
 
-- `judge_output.json` — rubric 항목별 PASS/FAIL + reason.
+- `judge_output.json` — rubric 항목별 PASS/FAIL 판정과 reason(사유).
 - `events.json` — 에이전트 이벤트 시퀀스.
-- `tree.json` — 샌드박스 종료 시 파일 트리.
+- `tree.json` — 샌드박스 종료 시점의 파일 트리.
 
 ## 5단계. 개선 및 리뷰
 
 ### FAIL 처리
 
-- 보고: 전체 PASS/FAIL 카운트 + FAIL 케이스 목록.
-- FAIL reason 분석:
-  - 결과 파일 (`judge_output.json`·`events.json`·`tree.json`) 읽기.
-  - 스킬/Eval 어느 쪽 문제인지 판단:
-    - **스킬 측**: 본문 명세대로 동작해도 FAIL → 명세 빈/모호 → 본문 보강.
-    - **Eval 측**: 본문 명세 만족하는데 rubric 이 본질 외(어휘 매칭·도구명 매칭 등) 으로 FAIL → rubric 수정 (§ 2 rubric 안티패턴 인용).
-    - **모호 시**: 사용자 질문.
-- 수정 → 같은 골든 셋 전체 § 4 재실행.
-- **수렴 한도**: 같은 케이스 3회 연속 FAIL 시 진행 중단 + 사용자 보고 (무한 루프 방지).
-- 새 실패 패턴은 골든 셋에 케이스 추가.
+- 보고: 전체 PASS/FAIL 카운트와 FAIL 케이스 목록.
+- FAIL reason(실패 사유) 분석:
+  - 결과 파일(`judge_output.json`·`events.json`·`tree.json`) 읽기.
+  - 스킬 본문과 Eval rubric 중 어느 쪽 문제인지 판단:
+    - **스킬 측 문제**: 본문 명세대로 동작했는데도 FAIL → 명세가 비어있거나 모호함 → 본문 보강.
+    - **Eval 측 문제**: 본문 명세를 만족했는데 rubric 이 본질 외 요소(어휘 매칭·도구명 매칭 등)로 FAIL → rubric 수정 (2단계 rubric 안티패턴 참조).
+    - **모호한 경우**: 사용자에게 질문.
+- 수정 후 같은 골든 셋 전체로 4단계 재실행.
+- **수렴 한도**: 같은 케이스가 3회 연속 FAIL 시 진행 중단하고 사용자에게 보고 (무한 루프 방지).
+- 새로운 실패 패턴은 골든 셋에 케이스로 추가.
 
 ### 리뷰
 
-PASS 후 sd-review 호출. 적용 룰: sd-base-rules + § 3 본문 작성 원칙·파일 분리 기준.
+전 케이스 PASS 후 sd-review 호출. 적용 룰: sd-base-rules 와 3단계의 "본문 작성 원칙"·"파일 분리 기준".
 
-수정 시 § 4 재실행.
+리뷰 결과로 수정 발생 시 4단계 재실행.

package/claude/skills/sd-skill/evals/fixtures/existing-skill/.claude/skills/todo-format/SKILL.md

@@ -7,7 +7,7 @@ description: 자유 형식 할일 텍스트를 마크다운 표로 변환한다.
 
 ## 1단계. 입력 파싱
 
-자유 형식 할일 라인 분해.
+자유 형식 할일을 줄 단위로 분해.
 
 ## 2단계. 표 출력