contract-review

name	contract-review
version	1.0.0
category	productivity
description	계약서·약정서·발주서 등 문서를 고정 조항 체크리스트로 검토해 우리에게 불리한 위험 조항을 빠짐없이 드러낸다 — 조항별 존재/부재를 강제해 로컬 모델이 위험 조항을 조용히 '없음'으로 놓치는 실패를 막는다. Use when: 계약서/약정서/MOU/발주서/공급계약 검토, '이 계약 검토해줘', '독소조항', '이 조건 받아도 돼?', 계약 문서 첨부. NOT for: 단순 메일 분석(email-analysis), 일반 요약, 변호사 자문 대체(고액·장기·독점 건은 법무 검토 권고).
metadata	{"deneb":{"emoji":"📑","tags":["contract","계약","검토","독소조항","위험조항","법무","발주서","review"],"triggers":["계약서","계약 검토","독소조항","약정서","공급계약","발주서 검토","이 조건 받아도","mou"],"related_skills":["email-analysis","fact-check","decision-premortem"]}}
user-invocable	true

계약·문서 리스크 검토

계약서·약정서·발주서를 우리 입장에서 검토해 불리한 조항을 빠짐없이 드러낸다. 다른 분석 스킬과 달리 이건 자유형 분석이 아니라 체크리스트 검토다 — 이유가 있다.

왜 체크리스트인가

"위험한 조항 찾아줘" 같은 자유형 지시는 로컬 모델에서 위험 조항을 통째로 조용히 누락한다(있는 조항을 "해당 조항 없음"이라 답하는 false-negative). 실측에서 로컬·오픈 모델은 위험 조항의 20~30%를 이렇게 놓쳤다. 서명 결정에선 치명적이다 — 안 보인 게 아니라 안 짚은 것이 사고를 낸다.

그래서 이 스킬은 고정 조항 목록을 하나씩 훑으며 조항별로 존재/부재를 강제한다. "누락"을 "명시적 부재 표시"로 바꾸는 것이 핵심이다. 분류 작업이므로 과도한 추론(thinking)은 단순 조항을 오히려 꼬이게 하니, 차분히 항목별로 판정한다.

When to Use

• 계약서·약정서·MOU·발주서·공급계약 등을 검토해달라고 할 때
• "이 조건 받아도 돼?", "독소조항 있어?", "우리한테 불리한 데 짚어줘"
• 계약 문서가 첨부로 도착했을 때

쓰지 않는 경우: 단순 메일 분석(→ email-analysis), 일반 요약.

절차

1. 문서 전체 확보. 메일 첨부면 mail_archive의 attachment 액션으로 직접 열고, 파일이면 읽는다. 스캔본(이미지·스캔 PDF)은 OCR이 자동으로 붙는다 (PaddleOCR-VL → tesseract). 본문이 일부만 들어왔으면 전체를 읽어라 — 위험 조항은 보통 뒷장 일반조항·특약에 숨는다.

2. 우리 입장 확정. 같은 조항도 우리가 갑(발주·구매)이냐 을(공급·수급)이냐로 유불리가 뒤집힌다. 먼저 우리가 어느 쪽인지 정하고 그 기준으로 판정한다.

3. 조항 체크리스트 훑기. templates/clause-checklist.md의 항목을 전부 훑어 조항마다 네 가지를 채운다:

   • 존재여부 — 있음 / 없음 / 해당없음. 문서에서 못 찾으면 "없음"이 아니라 **"문서에서 찾지 못함"**으로 적는다(추측 금지).
   • 원문 인용 — 있으면 해당 문구를 짧게 따온다(나중에 다툼의 근거).
   • 불리 여부 — 우리에게 불리한가(예/아니오/조건부).
   • 한 줄 이유 — 왜 불리/유리한지.

4. 임원 결정만 추리기. 보일러플레이트까지 나열하지 말고, 서명 전에 협상하거나 결정해야 할 2~3개를 맨 앞에 둔다(비서실장 위임 원칙 — 임원이 직접 판단할 것만). 나머지는 체크리스트 표로 첨부한다.

Pitfalls

• "위험 조항 없음"이라고 단정하지 마라. 항상 "검토한 항목 중에서는 발견하지 못함"으로 적는다 — 로컬 모델의 누락 가능성을 사용자에게 남겨둔다.
• 고액·장기·독점·연대보증·무제한 손해배상이 걸린 건은 검토 결과와 함께 변호사/법무 검토를 권고한다. 이 스킬은 1차 스크리닝이지 법률 자문이 아니다.
• 금액·기간·요율 같은 숫자는 원문 그대로 인용한다. 지어내거나 반올림하지 마라.
• 불확실한 사실 주장이 섞이면 fact-check로, 받을지 말지 판단이 필요하면 decision-premortem으로 잇는다.

쓸 수 있는 것

• 첨부 읽기 — 메일 계약서는 mail_archive attachment로 연다(email-analysis와 동일 경로). 본문이 "계약서 첨부"라고만 하면 받아쓰지 말고 실제 첨부를 열어라.
• 거래 위키 갱신 — 검토로 확정된 핵심 조건(단가·납기·위약·보증)은 wiki의 거래 페이지에 변경 전후 병기로 남기고, 가장 임박한 기한을 due에 반영한다 (페이지 골격은 email-analysis의 templates/deal-page.md). 소관 부서 태그도 동일.

주의

지금 응답하는 곳이 곧 사용자의 채널이다 — 채널 상태를 추측하지 마라. 내부 토큰(<thinking>, NO_REPLY)이 새지 않게 하고, "좋은 질문입니다" 같은 빈 서두 없이 검토부터 시작한다. 근거 없는 조항·숫자는 비워 두고, 모르는 것은 모른다고 둔다.