Prayer_for_Relief_Docs/opus_5_evaluation_prompt_v.2.txt

※ placeholder 규칙: 본 프롬프트의 문자열 "<####>"는 분석 대상인 대한민국 민사소송 사건종류(예: 대여금 청구)로 사전 치환되어 제공된다. "<####>"가 미치환 상태로 남아 있으면 실행하지 말고 사용자에게 사건종류를 요청한다.
※ 경로 치환 규칙: 경로·파일명에서 사건종류의 공백·특수문자는 제거한다(예: "전부금 청구" → 전부금청구). 동명 폴더가 이미 존재하면 그 폴더명 표기를 그대로 따른다.
※ 다건 라운드(사건종류 2건 이상)면 사건종류 간 배리어 없는 Workflow pipeline으로 확장한다. 아래는 1건 기준 절차이고, <초기화> [0-A]는 라운드당 1회만 수행한다.

<role>대한민국 민사소송 실무 전문 법조인 겸 LLM 프롬프트 아키텍트</role>

<goal>
1차 드래프트 `사건종류_<####>/청구취지작성규칙_<####>_v1.md`(LLM용 decision tree 형식의 청구취지 작성 규칙)를 평가하여, v2 개정에 그대로 투입 가능한 평가서를 작성한다.
</goal>

<컨텍스트 예산 — 위반 금지>
- main agent는 MEMORY_Claude.md 전문, 점검표 파일, v1 전문 중 어느 것도 읽지 않는다. 읽기는 전부 shell과 sub-agent에 위임한다.
- main agent의 v1 직접 열람은 두 보고가 상충하는 절의 부분 열람(sed -n 'A,Bp')만 허용한다.
- 독립적인 도구 호출은 한 메시지에 묶어 병렬 실행한다. 순차 왕복 금지.
- 에이전트 보고는 <보고 스키마> 고정. 산문 보고를 받으면 병합 비용이 산출물 가치를 넘는다.
</컨텍스트 예산>

<초기화>
working directory: Default_Agent_청구취지기재방법. CLAUDE.md의 작업 원칙을 따른다.

[0-A] 점검표 캐시 (라운드당 1회. 내용을 main 컨텍스트에 올리지 않는다)
`tmp/MEMORY_점검표.md`가 존재하고 MEMORY_Claude.md보다 최신이면 그대로 재사용한다. 아니면 재생성한다.
 1) 원자료 추출은 shell로만 수행한다(출력을 읽지 않는다):
    awk '/^### .*(반복 결함 패턴|체크리스트)/{f=1} /^### /&&!/(반복 결함 패턴|체크리스트)/{f=0} f' MEMORY_Claude.md > tmp/_점검표_raw.md
 2) sub-agent 1개에 위임한다(그 에이전트는 하위 에이전트를 스폰하지 않는다): `tmp/_점검표_raw.md`를 읽고 `tmp/MEMORY_점검표.md`를 작성한다.
    (a) 누적 반복 결함 패턴 전량을 [번호 | 한 줄 정의 | 검출 방법] 3열 표로. MEMORY는 단일 절이 아니라 세션별 누적 분산 기록이므로 번호 총수를 고정하지 말고 실제 최대 번호까지 전수 수록하고, 후속 세션의 "정밀화·승격" 기술은 해당 번호에 병합한다.
    (b) 시리즈 공통 체크리스트를 [사건번호·법령 | 법리 요지 | 적용 대상 계열] 3열 표로 중복 제거하여 전량 수록한다.
    압축하되 번호·사건번호·조문번호는 무손실로 유지한다.

[0-B] 구조 사전스캔 (shell로만 수행. 결과는 파일로만 보관하고 읽지 않는다)
    V1="사건종류_<####>/청구취지작성규칙_<####>_v1.md"   # 실제 파일명이 다르면 폴더 내 실파일명을 그대로 쓴다
    grep -oE '(Gate ?[0-9]+|Q[0-9]+|Step ?[0-9]+|STOP-?[A-Z0-9]+|Branch ?[A-Z]|TYPE-?[A-Z0-9]+|FORM-?[A-Z0-9]+|[A-Z]{2,}-[A-Z0-9]+|[0-9]+\.[0-9]+(\.[0-9]+)?)' "$V1" | sort | uniq -c | sort -n | awk '$1==1' > "tmp/고아후보_<####>.txt"
문서 전체에서 1회만 등장하는 코드·절번호 = 유입 간선이 없는 고아 후보(패턴 ①⑬㉝ 검출용)다. 확정 결함이 아니라 에이전트가 전건 판정할 검증 대상 목록이다.
</초기화>

<method>
[1] sub-agent 2개를 단일 메시지로 동시 병렬 실행한다(subagent_type: general-purpose). v1 원문 정독은 전적으로 에이전트가 수행한다.
공통 전달 항목: v1 경로 / 사건종류 / `tmp/MEMORY_점검표.md` 경로 / `tmp/고아후보_<####>.txt` 경로 / 아래 <검증축>·<검증 실무 지식>·<보고 스키마> 전문.
- 에이전트 A(공식 조사): 아래 공식 출처만 사용하여 "<####>" 청구취지 작성 정보를 수집하고 v1을 평가한다.
  · 국가법령정보센터 https://www.law.go.kr — 판례·조문·등기예규 검증은 DRF API(precSeq·lsId·admRulSeq, 선고일 범위 검색) 우선
  · 대한민국 법원 https://www.scourt.go.kr
  · 세계법제정보센터 https://world.moleg.go.kr
  · scourt 계열 하위 사이트(pro-se·ecfs·glaw·help 등)는 클라우드에서 차단될 수 있다 — 실패 시 law.go.kr로 대체한다.
- 에이전트 B(일반 조사): 공식 출처를 제외한 웹 검색으로 동일 작업. 실무 빈발 유형, 최근 3년 판례 동향, 개정 예고 스캔을 포함한다.
- 두 에이전트 공통: 독립 조회는 배치로 병렬 실행한다. 실패 시 1회만 재시도하고, 그래도 실패하면 "미검증"으로 표기한다 — 결과를 추론으로 메우지 않는다.
- **두 에이전트 공통(필수): 하위 에이전트를 스폰하지 않는다. 조사·검증·판정을 자기 컨텍스트 안에서 끝내고 <보고 스키마> 3부를 직접 반환한다.**
  이유: sub-agent가 스폰한 하위 에이전트는 부모에게 회신하지 못한다(SendMessage가 `No agent named 'general-purpose' is reachable`로 전건 실패). 그 결과가 부모를 건너뛰고 최상위 세션으로 올라오면 보고 스키마 밖의 산문이 main 컨텍스트에 유입되고, 부모는 자기 하위 조사 결과를 반영하지 못한 채 보고를 마친다. 조사량이 많아도 분할하지 말고 검색 예산 안에서 우선순위를 정해 처리하며, 예산이 부족하면 미조사 항목을 S3에 "미조사"로 명시한다.

<검증 실무 지식> (검증된 사실. 재발견하지 말고 그대로 적용한다)
- 판례 링크는 evtNo형보다 precSeq형이 안정적이다. evtNo형이 다른 사건을 반환한 실측 사례가 있으므로 precSeq형 교체를 기본 권고한다.
- 조문 링크 joNo의 앞 4자리 = 조번호(예: 030100000 = 제301조). 링크는 JS 렌더링이라 열람만으로 오연결이 보이지 않는다 — joNo로 판정한다. lsJoLnkSeq형도 다른 조문을 표시할 수 있어 전수 실측이 필요하다.
- lsiSeq 고정형 URL은 '현행'이 아니라 특정 공포본을 가리킨다(미시행 장래본 포함). 한글 자동조회 URL(law.go.kr/법령/○○법)로 교체를 권고한다.
- 등기예규 호수 상충은 DRF 현행연혁구분으로 즉결한다. 2차 자료·scourt 게시본은 구번호나 선반영 번호를 자주 준다.
- www.scourt.go.kr/sjudge/*.pdf 직링크는 curl 다운로드 후 pdftotext -raw로 사건번호·선고일 판독이 가능하다. WebFetch 텍스트 추출 실패가 곧 링크 불량은 아니다.
- 판례속보 페이지의 제목 자동추출은 신뢰하지 않는다 — 사건번호·선고일·인용 선례 대조로만 판정한다.
- DRF OC=test가 0건을 반환해도 판례 부존재의 근거가 되지 않는다.
- 개정 성립 여부 상충은 현행 조문 본문의 '<개정 일자>' 표기로 즉결한다(의안정보 스냅샷보다 우선).
</검증 실무 지식>

<검증축> (두 에이전트 공통)
1. 판례 인용 5요소 교차 검증: 사건번호 + 선고일 + 판결유형(전합 여부) + 링크가 실제 가리키는 사건 + 해당 판례를 변경·폐기한 후속 전합의 존부.
2. 링크 판정 기준: "열리는가"가 아니라 "현행·정식 등재 원문을 반환하는가". 법령 링크는 시행일이 기준일 이전인지까지 확인한다(미시행 장래본을 '현행'으로 라벨한 것은 결함).
3. 인용-파생 규칙 방향 일치: 인용 4요소가 정확해도 그로부터 파생된 본문 규칙이 판시와 반대이거나 판시의 절반만 반영했는지 대조한다.
4. 근원 전합·반대 법리: 강한 원칙 규칙마다 리딩 전합 인용 여부와 예외·반대 판례의 존부를 독립 항목으로 점검한다.
5. 트리 양방향 검산: (a) 전 노드에 유입 간선이 있는가(전달받은 고아 후보 목록 전건 판정), (b) 전 문형이 트리에서 도달 가능한가, (c) 특수 경로가 본류 질문으로 복귀하여 필수 후속 판정을 받는가.
6. 조문 전사 정합: 선택 요건("각 호의 어느 하나")이 누적 요건으로 오독되게 나열되지 않았는지 각 호의 연결 구조를 대조한다. 부칙·경과규정의 시적 기준, 소급효 예외(민법 제1015조 등)로 인한 시적 게이트 오탈락도 함께 본다.
7. 금전청구 4대 공통 게이트: 도산(회생·파산) 게이트 / 소촉법 장래이행 단서 / 약정이율-특례이율 대소 비교 규칙(민법 제397조 제1항 단서, 소촉법 제3조 제1항 본문 괄호 — 부재 시 규칙 준수가 곧 과소청구) / '연대하여'·'공동하여' 용법.
8. 전달받은 점검표의 반복 결함 패턴을 전수 적용하고, 시리즈 공통 체크리스트 판례가 이 문서에 반영되어야 하는지 판정한다.
</검증축>

<보고 스키마> (두 에이전트 공통. 아래 3부만 작성하고 서론·요약·소감은 쓰지 않는다)
S1. 결함 대장 — 표, 심각도 내림차순, 최대 25행
| # | 위치(§/노드) | 패턴코드 | 결함 요지(1문장) | 근거(사건번호·조문·URL) | 검증상태(원문대조/2차자료/미검증) | 심각도(1~3) | v2 수정문(그대로 붙여넣을 수 있는 문장) |
S2. 인용 대장 — 표, 문서의 판례·법령·예규 링크 전수
| 인용 | 5요소 판정(OK 또는 오류 내용) | 교체·보완 권고 |
S3. 부재 쟁점 / 잘 작성된 부분 — 각 5항목 이내 불릿
</보고 스키마>

[2] 병합 규칙
- 두 조사가 독립적으로 지목한 결함은 최우선 순위로 배치한다.
- 법률 출처 상충 시 공식 DB 원문 대조 결과를 우선한다. "일반 웹 확인 실패 ≠ 판례 부존재" — 의심 판례는 공식 DB 원문 대조 후에만 삭제를 권고한다.
- "실재 검증"과 "인용 취지 일치 검증"을 분리해 판정한다. 실재하나 판시가 다르면 삭제가 아니라 용도 변경이다.
- 두 보고의 판시 요약이 정반대로 보이면 한 판례가 원칙과 예외를 함께 판시한 경우일 수 있다 — 원문 재확인 후 양면 라벨화한다.
- 검색 스니펫의 precSeq는 인접 판례로 어긋나는 일이 잦다 — 원문 재확인 전 교체 채택 금지.
- 결함의 '정도'가 갈리면(항 누락 vs 문형 자체 부재) 가벼운 쪽을 택하지 말고 해당 절만 부분 열람하여 확정한다(전문 정독 금지는 유지).
- 에이전트 1개가 실패(과부하 등)하면 실패한 에이전트만 재실행한다. 재실행도 실패하면 단독 보고 기반임을 평가서에 명시하고, 발견되었을 내용을 추론하지 않는다.
</method>

<output>
`사건종류_<####>/청구취지작성규칙_<####>_평가서_opus5_v1.md` 생성·저장. 구조:
0. 한 줄 요약 + 결함 대장(병합 확정본. 심각도·패턴코드·위치·근거·검증상태·v2 수정문 표)
1. 잘 작성된 내용 — 항목별 간략 서술
2. 개선해야 할 점과 그 이유 — 항목별 간략 서술. 각 항목에 근거와 검증상태를 명시한다
3. 개정 방식 — 항목별로 v2에 바로 적용 가능한 수준(교체 문장·추가 노드·삭제 대상)으로 서술
저장 후 파일 존재와 바이트 수를 확인하여 보고한다.
</output>

<마무리>
- CLAUDE.md Memory System 규칙에 따라 MEMORY_Claude.md에 이번 task 교훈 1건(상단 한 줄 요약 포함)을 기록한다. 신규 반복 결함 패턴은 기존 최대 번호의 다음 번호로 승격하고, 기존 패턴의 정밀화는 해당 항목을 갱신한다. 기존과 중복이면 갱신만 하고 신규만 추가한다. 병행 작업으로 쓰기 충돌 우려 시 순차 기록한다.
- MEMORY_Claude.md를 갱신했으면 `tmp/MEMORY_점검표.md`는 다음 라운드에서 자동 재생성된다([0-A] 신선도 비교).
</마무리>