danepps/legal-research-skills

라이브러리 구축

프로젝트를 위한 출처로 Zotero 컬렉션을 채웁니다. 허위 출처에 대한 두 가지 방어 계층: (1) 추가 전에 모든 후보를 실제 출처에 대해 확인; (2) 추가 후, 번들된 결정론적 검사기를 실행 — 검증되지 않은 항목은 통과되지 않습니다. 모든 전역 권위 규칙(인용을 절대 만들어내지 말고, 불확실함을 표시)이 전체 과정에 적용됩니다.

0. 0단계 — 다른 작업을 하기 전에 라이브러리 전체를 먼저 읽으십시오

범위를 정하기 전에, 검색하기 전에, 단 하나의 후보를 제안하기 전에, 대상 라이브러리를 덤프하고 전부 읽으십시오:

python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/library_inventory.py --group <ID>   # 또는 --user
python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/library_inventory.py --group <ID> --grep <용어>

최상위 항목당 한 줄: 연도, PDF 여부, 저자, 제목, 출판물, 항목 키. 100개 항목 라이브러리는 3k 토큰 미만입니다. 이를 건너뛸 예산적 이유는 없으며 대체할 수도 없습니다. 대규모 라이브러리(수천 개 항목)의 경우 전체 덤프를 파일에 저장하고 관련 --grep 조각과 전체 형태를 읽으십시오. 그러나 조정자는 여전히 확인을 책임지며, grep되지 않은 조각은 부재의 증거가 아닙니다.

이는 중복 확인의 일부가 아닌 0단계입니다. 라이브러리를 알면 무엇을 찾을지가 바뀌기 때문입니다. 이 단계를 건너뛴 실행은 사용자가 이미 소유한 항목을 제안하고, 이를 "새로 식별됨"이라고 설명하며, 컬렉션의 공백에 대해 잘못된 주장을 할 것입니다.

실제 실패(2026-08-01, 105개 항목 그룹 라이브러리)에서 비롯된 네 가지 엄격한 규칙:

1. 인벤토리 또는 중복 확인을 하위 에이전트에 위임하지 마십시오. 연구 하위 에이전트는 그룹에 "나열된 13개 항목과 소수의 관련 없는 저작물만" 있다고 보고했습니다. 실제로는 105개였습니다. 조정자는 이를 믿고 세 개의 중복 항목을 만들었습니다. 하위 에이전트는 후보를 찾는 데는 괜찮습니다; 조정자가 라이브러리를 아는 것을 책임집니다.
2. 하위 에이전트의 부정적 발견을 검증되지 않은 것으로 처리하십시오. "확인했는데 거기에 없습니다"는 바로 하위 에이전트가 틀리는 주장입니다. 부재는 좁은 검색 내에서 반증할 수 없기 때문입니다. "라이브러리에 없음" 주장은 항상 자신의 인벤토리와 다시 확인하십시오.
3. 모든 추가는 검사를 통과해야 하며, 늦게 추가된 항목도 포함됩니다. 세 개의 중복 항목 중 두 개는 세션 맨 끝에, 방금 읽은 기사의 각주에서 나온 것으로 추가되었습니다. 이는 메인 파이프라인 외부에 있었기 때문에 검사를 완전히 건너뛰었습니다. 너무 작거나 너무 늦은 후보는 없습니다; 이미 가지고 있는 인벤토리를 grep하십시오.
4. 인벤토리를 전달하십시오. 출처를 찾도록 요청받은 모든 하위 에이전트는 실제 목록(또는 필터링된 조각)을 프롬프트에 붙여넣어 받아야 합니다. 스스로 확인하라는 지시가 아닙니다.

라이브러리는 또한 증거입니다. "무엇이 누락되었는가"가 작업일 때, 사용자가 이미 소유한 것은 그들이 무엇에 관심이 있는지 알려주고 종종 답변을 재구성합니다. 이 규칙을 촉발한 실행에서 사용자의 라이브러리는 메모가 방금 설명한 다루어지지 않은 주제에 대한 형법 학술 자료의 깊은 선반을 포함하고 있는 것으로 밝혀졌습니다. 이는 "아무도 이것에 대해 쓰지 않았다"는 발견을 "이 두 문헌은 서로를 인용하지 않는다"로 바꾸었습니다. 중복 일치뿐만 아니라 프로젝트에 대해 말해주는 것을 위해 인벤토리를 읽으십시오.

1. Zotero 연결

zotero / zotero-group MCP 도구는 읽기 전용입니다(중복 확인 및 검색에 좋음). 모든 쓰기는 ~/.claude.json의 zotero 항목에 있는 키(env.ZOTERO_API_KEY; 개인 라이브러리, <USER_ID> 및 사용하는 모든 그룹 라이브러리에 쓰기 액세스 권한이 있는 것으로 확인됨)를 사용하여 Zotero Web API v3를 통해 이루어집니다.

• 컬렉션: GET /users/<USER_ID>/collections?limit=100 → 대상 키를 찾습니다. 사용자가 새 컬렉션을 원하면(이름 먼저 확인) POST /collections로 생성합니다.
• 중복 확인 — 먼저 인벤토리(§0), 후보 목록 선별(§2a), 추가 전 최종 확인: 전체 라이브러리를 미리 읽고(§0); 확인 또는 PDF 작업 전에 후보 목록 중복을 제거하고(§2a); 그런 다음 POST /items 직전에 가벼운 최종 확인을 백스톱으로 유지합니다. 이는 동일한 실행에서 이전에 추가된 항목과 이전 검사가 놓친 정확한 판 충돌을 잡아냅니다. 실행 중 일회성 조회의 경우 library_inventory.py --grep <용어>가 mcp__zotero__zotero_search_items보다 낫습니다. 이미 보유한 목록을 검색하기 때문에 새로운 좁은 쿼리를 발행하지 않습니다.
• 항목 생성: POST /users/<USER_ID>/items에 JSON 배열(최대 50개/요청)을 사용합니다. 응답의 success/failed 맵을 확인하십시오. 필드가 확실하지 않은 경우 GET https://api.zotero.org/items/new?itemType=book에서 빈 템플릿을 가져옵니다.
• 규칙: 삽화가/“함께” 크레딧 → contributor 생성자 및 extra 노트 추가(Zotero 책에는 삽화가 역할이 없음); 편집자 → editor; 판의 실제 출판사/임프린트(예: "Penguin"이 아닌 Sentinel); 확인된 경우 전체 발행일, 그렇지 않으면 연도; 책에는 항상 ISBN, 기사에는 항상 DOI.

1a. 법률 리뷰 기사 메타데이터 — Zotero-Connector 결함 수정(저자, 2026-07-16)

Claude는 Web API를 통해 항목을 생성하므로 사용자의 Zotero Connector가 지속적으로 잘못 가져오는 부분을 올바르게 처리할 수 있습니다. 추가된 모든 법률 리뷰 기사에 적용하십시오. Hein(§4a)은 올바른 데이터를 표시하므로 해당 필드를 가져옵니다.

1. 선행 "The"/"A"/"An": 기사를 자연스러운 앞 위치에 유지 — 제목 The Common Law, Connector의 정렬 반전 Common Law, The가 아닙니다.
2. 연도 = 호의 연도, 권의 범위가 아님. Connector는 종종 전체 권의 날짜 범위를 가져옵니다; Hein의 인용이 제공하는 특정 호의 연도를 사용하십시오.
3. 후행 물음표: 보존하십시오 — Are Judges Political?, Are Judges Political이 아닙니다.
4. 제목의 이탤릭체: Zotero 제목 필드는 인라인 HTML을 허용합니다 — 사건 이름(및 기타 Bluebook 이탤릭체 용어)을 <i>…</i>로 감싸십시오. 예: The Real Meaning of <i>Erie</i> 또는 Rethinking <i>Chevron</i> Deference. Zotero는 이를 이탤릭체로 렌더링하고 내보냅니다(사용자가 수동으로 추가하는 <i>사건 이름</i>입니다).
5. 제목에서 추가된 부분/심포지엄 레이블을 제거하되, 실제 Bluebook 지정은 extra에 보존하십시오. Connector는 Essay, Comment, Note, Foreword, Book Review, Symposium: <이름> 등의 지정을 제목에 덧붙입니다. 기사의 실제 제목만 유지하십시오(원문에서 제목을 시작하는 대로 / Bluebook 인용에 나타나는 대로). 후행 텍스트가 실제 부제인지 추가된 레이블인지 확실하지 않은 경우 첫 페이지를 확인하십시오.
   • 학생 노트 및 논평(및 Bluebook이 저자와 제목 사이에 인쇄하는 기타 지정 — Recent Development, Essay, Foreword, Book Review 등): 레이블을 그냥 버리지 마십시오. 항목의 extra 필드에 genre: 줄로 기록하십시오 — 학생 노트의 경우 genre: Note, 논평의 경우 genre: Comment(제목 대문자; 스타일은 어쨌든 제목 대문자로 표시하지만 깔끔하게 저장하십시오). Bluebook 스타일은 이를 올바른 위치에 삽입합니다(Jane Doe, Note, <i>Title</i>, 120 Harv. L. Rev. 1627 (2007)). 위와 같이 제목에서 제거 하고 genre: 줄을 추가하십시오 — 이 두 가지는 이러한 항목의 경우 함께 사용됩니다.
   • 익명 학생 노트(저자 없음): 생성자를 비워두고 여전히 genre: Note를 설정하십시오. extra 필드에 이미 다른 줄(예: Verified-URL:)이 있는 경우 새 줄에 genre: Note를 추가하십시오. 덮어쓰지 마십시오.
6. 접미사("Jr.", "III", "Sr."): Zotero에는 접미사 필드가 없습니다 — 접미사를 이름 필드에 인코딩하고, 쉼표와 공백 없음으로 이름 뒤에 추가하십시오(lastName은 성만 유지; 접미사를 성에 추가하거나 두 번째 저자를 추가하지 마십시오). 접미사 앞의 !는 그 앞에 쉼표를 렌더링할지 여부를 제어합니다(citeproc-js 마크업, 저자 당):
   • "John Smith Jr."(쉼표 없음) → firstName: "John,Jr.", lastName: "Smith"
   • "John Smith, Jr."(쉼표 있음) → firstName: "John,!Jr.", lastName: "Smith" 중간 이름/이니셜을 포함한 이름은 쉼표 앞에 옵니다(예: John B.,Jr.). 숫자/기타 접미사에도 동일한 메커니즘 — John,III 대 John,!III, John,Sr. 등. 저자/출처가 사용하는 쉼표 형식과 일치시키십시오.
7. 저널 약어(Bluebook, 혼합 대소문자): 항상 Zotero journalAbbreviation 필드(UI의 "Journal Abbr")를 저널의 Bluebook 약어(표 T13)로 일반 혼합 대소문자로 채우십시오 — Colum. L. Rev., Harv. L. Rev., Nw. U. L. Rev., J. Sup. Ct. Hist., Sup. Ct. Rev. — 모두 대문자가 아닙니다. 인용 스타일이 소문자 대문자를 자체적으로 적용하므로 Colum. L. Rev.를 저장하고 COLUM. L. REV.는 절대 안 됩니다. 전체 이름은 publicationTitle에 유지됩니다; 약어는 journalAbbreviation에 들어갑니다. Hein의 인용 표시는 대문자/소문자 대문자로 렌더링합니다("62 COLUM. L. REV. 633") — 표현은 사용하되 혼합 대소문자로 변환하십시오; 익숙하지 않은 저널의 경우 추측하지 말고 T13 형식을 확인하십시오. 온라인 동반자/보충판의 경우 Bluebook에 따라 약어화된 보충판 이름을 추가하십시오 — Forum → F. (예: Harv. L. Rev. F.), 반면 Colloquy는 짧은 형식이 없습니다 (Nw. U. L. Rev. Colloquy). 알려진 이름별 예외(이것들을 "수정"하지 마십시오): California Law Review → Calif. L. Rev. (Cal.이 아님, 캘리포니아가 다른 곳에서 Cal.이더라도). Calif.의 특이성은 해당 저널에만 해당됩니다 — 대조적으로 Southern California Law Review → S. Cal. L. Rev. 는 여기서 캘리포니아가 일반적인 Cal.을 취합니다.

2. 후보 찾기

요청이 개방적인 경우 사용자와 범위를 정하십시오(어떤 판사/학자/시대; 책만 또는 기사도 포함; 일반 서적 대 교과서/논문 — 암묵적으로 결정하지 말고 보고서에 판단 호출을 표시). §0 후에 이 작업을 수행하고, 절대 그 전에 하지 마십시오 — 인벤토리는 사용자가 이미 무엇을 가지고 있는지 알려주며, 이는 무엇을 찾을 가치가 있는지 바꿉니다.

병렬로 검색: WebSearch; Open Library (search.json?title=&author=가 bare q=보다 나음); Wikipedia 정보 상자 (/w/index.php?title=<페이지>&action=raw, 정보 상자 grep) 주요 도서의 출판사/날짜/ISBN 확인; 출판사 페이지. 법률 학술 자료의 경우 HeinOnline(§4). Google Books API는 공유 익명 할당량이 있어 자주 소진됩니다 — 이를 백본이 아닌 보너스로 취급하십시오.

2a. 라이브러리에서 후보 선별

인벤토리를 손에 넣은 후, 비용이 많이 드는 확인 → 다운로드 → 추가 파이프라인(§3+) 전에 후보 목록의 중복을 제거하십시오. 메타데이터를 확인하고 PDF를 가져오는 것은(Hein curl 체인, attach_pdf.py) 실행에서 가장 비용이 많이 드는 부분입니다; 이미 라이브러리에 있는 출처에 대해 이를 수행하는 것은 순전한 낭비입니다.

1. 각 후보를 먼저 저자 + 연도, 그 다음 제목으로 인벤토리와 일치시키십시오 — 제목은 다양하지만(부제, "Part I", 정렬 반전 관사, HTML 엔티티) 저자-플러스-연도 충돌은 더 자세히 살펴봐야 할 신뢰할 수 있는 신호입니다.
2. 명확한 일치(동일한 저작물이 이미 존재함)는 제거하십시오 — 확인하거나 다운로드하지 마십시오.
3. 애매한 근접 일치(동일 저자, 유사하지만 동일하지 않은 제목; 다른 판/인쇄; 기사 대 온라인 동반자)는 조용히 제거하지 말고 표시하십시오. 확인 중에만 정확한 판을 특정할 수 있는 경우가 있으므로 진정한 가능성을 가지고 진행하고 보고서에 기록하여 추측으로 제거하지 마십시오.

생존한 항목만 §3을 거칩니다. §1의 추가 전 백스톱은 실행 내 중복 및 정확한 판 충돌을 잡아냅니다.

중복을 생성한 경우, 삭제하기 전에 병합하십시오. 기존 항목에는 사용자의 PDF, 주석, 태그 및 컬렉션 멤버십이 있을 수 있습니다; 새 항목에는 더 나은 메타데이터가 있을 수 있습니다. 기존 항목에 좋은 필드를 PATCH한 다음, 자신의 항목을 DELETE하십시오. 이전 레코드를 절대 삭제하지 마십시오. (2026-08-01 정리에서 이는 실제 결함을 복구했습니다: 사용자의 Kahan 항목은 issue 필드에 "10.2307" 문자열이 있고 DOI가 없었습니다.)

워크플로 규칙(저자, 2026-07-16): 모든 법률 리뷰 출처를 HeinOnline을 통해 확인하십시오. Hein은 깨끗하고 자율적인 경로입니다(§4a: IP 인증, 봇 장벽 없음, 게이트 없음). Hein이 제공하지 않고 어떤 오픈 리포지토리도 제공하지 않는 출처는 확인된 레코드 없이 추가되지 않고 (§5) 보고됩니다.

3. 확인 → 추가 → 결정론적 검사(논의 불가)

추가 전: 작성하는 모든 필드는 가져온 출처(Open Library 판 기록(/isbn/<isbn>.json), 출판사 페이지, Wikipedia 정보 상자, 서점 목록)에서 가져와야 합니다. 기억에서 그럴듯한 ISBN/날짜/출판사를 절대 쓰지 마십시오. 손상된 OL 판 기록(ISBN 뒤에 잘못된 책이 있는 경우)을 조심하십시오; 놀라운 내용은 두 번째 출처와 교차 확인하십시오.

추가 후, Zotero에 실제로 들어간 내용에 대해 번들된 검사기를 실행하십시오:

python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/check_source.py --collection <KEY>   # 전체 컬렉션
python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/check_source.py --keys K1,K2,K3      # 새 항목만

각 항목의 ISBN을 5개의 독립적인 카탈로그(Open Library 판 + 검색 인덱스, Google Books, Harvard Library, Library of Congress) 또는 DOI를 Crossref를 통해 확인하고 제목/저자/연도의 정규화된 문자열 비교를 수행합니다. 판정: PASS, FAIL(확인되었지만 불일치), UNRESOLVED(식별자가 확인된 모든 카탈로그에서 발견되지 않음 — 재확인 신호, 허위 제작 증거가 아님: 카탈로그는 불완전하고 때로는 다운됨), BAD_ISBN(체크섬), NO_IDENTIFIER. --stdin은 Zotero 형식 항목의 JSON 배열을 받아 추가 전에 후보를 미리 확인합니다.

추가한 모든 항목은 PASS로 끝나야 합니다. PASS가 아닌 경우에 대한 대처법:

• 하나의 출처에서만 FAIL → 일반적으로 카탈로그 손상; 검사기는 이미 다른 출처를 시도하므로 지속적인 FAIL은 일반적으로 데이터가 잘못되었음을 의미합니다 — 열린 권위 있는 페이지를 다시 확인하고 항목을 PATCH하십시오(If-Unmodified-Since-Version: <항목 버전> 보내기). 열린 페이지가 데이터를 확인하면 "수정"하는 대신 Verified-URL:로 기록하고 보고서에 그렇게 명시하십시오.
• UNRESOLVED/카탈로그에 비해 너무 새로운 책(약 <1년) → 가져올 수 있는 권위 있는 페이지를 extra의 Verified-URL:로 추가하고 보고서에 이를 설명하십시오.
• 검사기 스스로를 다시 실행하십시오 — 때로는 일시적인 카탈로그 다운이 문제입니다.
• --keys 플래그를 사용하면 전체 컬렉션을 다시 확인하지 않고도 개별 항목을 검사할 수 있습니다.

4. 출처별 지침

4a. HeinOnline (법률 리뷰의 주요 출처)

대부분의 법률 리뷰 기사는 Hein에서 확인할 수 있습니다. 이것은 의존해야 하는 가장 안정적인 파이프라인입니다. 귀하(Claude)는 각 작업에 대해 개별적으로 인증할 수 없습니다. 대신 사용자에게 (i) 로컬 시스템에 배치되고 귀하의 하위 프로세스 작업 디렉토리에서 액세스 가능한 hein_cookie.txt, 또는 (ii) 그룹 라이브러리의 경우 그룹 라이브러리의 ~/.claude.json에 있는 hein_cookie 키 아래에 저장된 Heinzinger 쿠키 파일이 있다고 가정하십시오.

Hein 쿠키 확인: 두 가지 방법으로 가능합니다:

• CHECK_HEIN_COOKIE=true CLAUDE_PLUGIN_ROOT=<...> python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/check_hein_cookie.py — 이는 쿠키의 유효성을 검사하고 세션의 짧은 세부 정보(도서관 이름, 기관 제휴)를 반환합니다. 항상 이 작업을 수행하십시오. (Hein은 기관 프록시를 통해 IP 기반 액세스를 제공합니다. 사용자가 IP 인증된 네트워크에 있는 경우 쿠키가 전혀 필요하지 않을 수 있습니다. check_hein_cookie.py는 이를 감지하고 표시합니다.)
• 사용자에게 "내 HeinOnline 쿠키가 여전히 유효한가요?"라고 물어보십시오. 그들은 확인합니다.

모든 것은 get_hein_document.py를 통해 이루어집니다:

python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/get_hein_document.py --help

긴 도움말을 읽거나 작동 방식을 확인하려면 실행하십시오.

일반적인 호출:

python3 ${CLAUDE_PLUGIN_ROOT}/skills/build-library/get_hein_document.py --citation "62 Colum. L. Rev. 633" --fields metadata,citation,first-page

--verbose는 전체 페이지 텍스트를 덤프합니다. --sleep는 각 요청 전에 지연 시간을 추가합니다. --fields는 반환할 정보 종류를 제어합니다. 전체 세부 정보는 --help를 참조하십시오.

Hein 체인: 기사가 앞 기사의 각주에 있는 경우, 건너뛰지 마십시오. --first-page로 시작하여 각 기사를 추출하십시오. 전체 URL을 구성하는 방법에 대한 get_hein_document.py --help를 참조하십시오.

Hein PDF 다운로드: --attach-pdf 플래그를 포함하면 도구가 PDF를 저장하고 경로를 반환합니다. 이 PDF를 그대로 항목의 메인 PDF로 첨부할 수 있습니다(ensure_full_text_pdf.py 또는 zotero_attach_file.py의 다른 PDF 다운로더를 통해). --attach-text는 텍스트 추출을 수행합니다.

5. 출력 및 보고서

작업 완료 시 각 추가된 항목을 요약하십시오. 확인할 수 없어 추가되지 않은 항목에 대한 이유를 포함하십시오(라이브러리에 이미 있음; 확인할 수 없음; 식별자 없음). 결정론적 검사 결과를 포함하십시오.

선호되는 형식 — 보고서 템플릿:

## 추가된 항목
- [저자], [제목]([연도]) → PASS
- [저자], [제목]([연도]) → PASS (수동 확인 후)

## 추가되지 않음
- [저자], [제목] — 이미 라이브러리에 있음
- [저자], [제목] — HeinOnline에서 확인 불가, 다른 곳에서 찾을 수 없음

PASS하지 않은 항목을 "추가됨" 아래에 두지 마십시오. PASS하지 않은 항목은 그대로 배송되지 않습니다.

데이터가 유효하지만 확인할 수 없는 드문 경우(매우 새로운 책, 다운된 카탈로그) 보고서에 명확하게 표시하십시오: "이 항목에 대한 결정론적 확인이 불가능합니다. 출처를 신뢰할 수 있지만 데이터를 [출처]와 직접 확인하십시오." 필요한 경우 기존 도구를 사용하여 수동 확인에 도움이 되는 PDF를 첨부할 수 있습니다.

6. 하위 에이전트 사용

하위 에이전트는 후보 찾기, PDF 추출 수행, 및 기타 병렬화 가능한 작업에 사용될 수 있습니다. 조정자는 여전히 라이브러리 상태, 중복 검사, 최종 결정론적 검사의 최종 책임을 집니다.

하위 에이전트 사용 규칙

1. 하위 에이전트에게 정확히 무엇을 할지 알려주고, 정보를 주입하십시오. "라이브러리 확인"이 아니라 "이 [목록]에서 어떤 항목을 찾을 수 있는지 확인하십시오"라고 말하십시오.
2. 하위 에이전트의 결과를 항상 사실과 비교하여 확인하십시오. 하위 에이전트는 "거기에 없습니다"라고 말할 수 있지만 실수할 수 있습니다. 부정적인 발견을 조정자의 라이브러리 지식과 교차 확인하십시오.
3. 하위 에이전트가 메타데이터를 생성하도록 허용하지 마십시오. 모든 메타데이터는 가져온 출처에서 가져와야 하며 하위 에이전트의 기억에서 추측하지 않아야 합니다.
4. 하위 에이전트에 현재 인벤토리를 전달하십시오. 라이브러리 목록을 붙여넣거나 --grep 결과를 제공하십시오. 스스로 확인하도록 요청하지 마십시오.

7. 프로젝트 기록 및 컨텍스트

프로젝트 기억을 위해 extra 필드를 사용하십시오. 각 항목의 extra 필드는 관련 메모를 저장하는 곳입니다. 작업 실행 전반에 걸친 정보를 전달하는 주요 메커니즘입니다. 줄 바꿈으로 구분된 키-값 쌍을 포함하며, 일반적으로 다음과 같습니다:

Verified-URL: https://...
genre: Note
Project: 국제 인권법 연구
Added: 2026-08-17

각 항목이 추가되면 Project: 줄을 포함하여 이 항목이 속한 프로젝트를 표시하고 Added: 줄을 포함하여 추가 날짜를 기록하십시오. 이는 나중에 이 스킬을 다시 실행할 때 프로젝트별로 필터링하는 데 도움이 됩니다.

기존 항목을 절대 수정하지 마십시오. 메타데이터를 업데이트해야 하는 경우(예: 확인된 URL 추가) 기존 콘텐츠를 덮어쓰지 마십시오. 대신 기존 라인을 보존하면서 새 라인을 추가하십시오.

8. 프로젝트 범위 및 언어

사용자는 종종 영어 및/또는 비영어 권위 자료가 필요한 특정 프로젝트에 대해 이 작업을 요청할 것입니다. 이 규칙을 따르십시오:

언어 = 중립적. 스킬 자체에 대한 지침은 번역되지 않습니다. 그러나 원하는 언어로 된 지식 작업입니다. 예를 들어, 사용자가 프랑스어 자료를 수집하도록 요청하면 저자는 프랑스어로 검색하고 데이터를 프랑스어로 추가해야 합니다(메타데이터는 출처 언어를 유지).

권위 = 출처별. 권위가 특정 언어나 관할권에 국한된 경우 사용자와 확인하십시오. 여러 관할권이 관련된 경우 각각에 대해 적절한 출처를 사용하십시오.