legal-writer について
契約書、訴状、メモなどの法的文書を DOCX 形式で作成するスキルです。各セクションの執筆後に検証を行い、判例や規制を調べるスクリプトも含みます。
主な機能
- 01DOCX 法的文書の作成
- 02セクション単位の検証
- 03文書種別ごとのテンプレートと指針
- 04CourtListener による判例検索
- 05eCFR と Federal Register の検索
活用シーン
- 01契約書や合意書の作成
- 02訴訟メモや準備書面の起草
- 03訴状や請求書簡の作成
- 04引用と規制情報の確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ kortix-ai/ kortix-registry --skill legal-writerインストール後、Claude Code で/legal-writerを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/bluebook.mddocument-types.mdscripts/courtlistener.pyecfr_lookup.pyverify-legal.py詳細
法的文書の作成
テスト駆動のワークフローで、出版品質の法的文書をDOCX(Word)形式で作成します。次のセクションへ進む前に、各セクションを検証します。契約書、メモ、訴答書面、訴状、請求書などに対応します。
同梱リソース
glob("**/KORTIX-legal-writer/") でスキルディレクトリを検索します。
| リソース | パス | 目的 |
|---|---|---|
| 検証ツール | scripts/verify-legal.py | TDD 検証スイート(10 項目) |
| 判例法 API | scripts/courtlistener.py | 判例引用の CourtListener 検索/照会 |
| 規制 API | scripts/ecfr_lookup.py | 法令・規則の eCFR および Federal Register 照会 |
| Bluebook リファレンス | references/bluebook.md | Bluebook 引用形式のクイックリファレンス |
| 文書種別リファレンス | references/document-types.md | 各文書種別のセクションテンプレート |
TDD のルール
文書の各セクションを書き終えるたびに:
1. WRITE section content
2. GENERATE: build/update the DOCX via the docx skill
3. VERIFY: python3 verify-legal.py legal/{slug}/
4. If FAIL → FIX → go to 2
5. If PASS → move to next section
文書は各段階で検証に合格する必要があります。エラーをまとめて処理してはいけません。
パイプラインの概要
Phase 1: SCAFFOLD → Create project, metadata.json, empty DOCX with structure
Verify: document exists and has correct sections ✓
Phase 2: RESEARCH → Case law, statutes, regulations (if litigation/regulatory doc)
Verify: citations are formatted correctly ✓
Phase 3: WRITE → Per-section drafting in logical order
Verify: verify-legal.py after EACH section ✓
Phase 4: POLISH → Self-reflection pass, strict verification, final DOCX
Verify: verify-legal.py --strict with zero warnings ✓
ファイルシステムの構成
legal/{document-slug}/
├── metadata.json # Document type, parties, jurisdiction, etc.
├── document.docx # The main document (generated via docx)
├── research/ # Case law, statutes, notes (optional)
│ ├── cases.json # CourtListener search results
│ ├── regulations.json # eCFR lookup results
│ └── notes.md # Research notes
└── versions/ # Prior versions (optional)
metadata.json
このファイルが検証を制御します。スキャフォールドの作成時に作成してください。
{
"type": "contract",
"title": "Services Agreement",
"jurisdiction": "State of Delaware",
"governing_law": "Delaware",
"date": "2025-01-15",
"parties": [
{"name": "Acme Corporation", "short_name": "Company", "role": "client"},
{"name": "Jane Smith Consulting LLC", "short_name": "Contractor", "role": "contractor"}
],
"word_limit": null,
"page_limit": null
}
訴答書面/申立書では、裁判所の規則に基づく word_limit または page_limit を含めてください。
フェーズ 1:スキャフォールド
1a. 文書種別を特定する
references/document-types.md を読み、依頼された文書種別に合うセクションテンプレートを確認します。主な文書種別は次のとおりです。
| 種別 | キー | 用途 |
|---|---|---|
| 法的覚書 | memo | 内部分析、予測 |
| 申立書面 | brief | 説得を目的とする裁判所への提出書面 |
| 契約書/合意書 | contract | 取引、二者間の義務 |
| 訴状/申立書 | complaint | 訴訟の開始 |
| 請求書 | demand | 訴訟前の請求 |
| 法的意見書 | opinion | 取引に関する正式な法的意見 |
| ディスカバリー要求 | discovery | 質問書、文書提出要求 |
| 和解契約書 | settlement | 紛争の解決 |
| 利用規約 | tos | ユーザー向け規約 |
| プライバシーポリシー | privacy | データプライバシーのコンプライアンス |
1b. プロジェクト構成を作成する
SLUG="document-slug-here"
mkdir -p "legal/$SLUG"/{research,versions}
1c. metadata.json を作成する
文書種別、当事者、管轄区域、および制約事項を含む JSON ファイルを作成します。
1d. 初期 DOCX を生成する
docx スキルを読み込みます。python-docx を使用して、次の設定で文書を作成します。
- 適切な見出しスタイル(セクション構成に Heading 1、2、3 を使用)
- 12pt のフォント(裁判所への提出書類には Times New Roman などのセリフ体)
- 1 インチの余白(管轄区域に応じて調整 — 裁判所の規則を参照)
- 申立書面/裁判所への提出書類はダブルスペース、契約書はシングルスペース
- 適切なページ番号
references/document-types.mdの文書種別テンプレートに一致するセクション見出し- プレースホルダーテキスト:各セクションに
[TO BE DRAFTED]
1e. 検証:最初のグリーン状態
python3 verify-legal.py legal/$SLUG/
スキャフォールドを作成した文書が存在し、構成が正しいことを確認します。この段階ではプレースホルダーがあるのが想定どおりです(--strict が指定されていない限り、失敗ではなく警告として扱われます)。
フェーズ 2:法的調査(該当する場合)
訴訟関連文書(メモ、申立書面、訴状)および規制関連文書では、執筆前に判例法と法令を調査します。
判例法の検索(CourtListener)
SKILL_DIR="..." # from glob
# Search for relevant cases
python3 "$SKILL_DIR/scripts/courtlistener.py" search "search terms" --after 2015 --limit 10
# Get specific opinion details
python3 "$SKILL_DIR/scripts/courtlistener.py" opinion 12345
# Format as Bluebook citation
python3 "$SKILL_DIR/scripts/courtlistener.py" bluebook 12345
結果を research/cases.json に保存します。文書で使用する重要な判示内容を抽出します。
注: CourtListener で高いレート制限を利用するには、無料の API トークンが必要です。環境変数 COURTLISTENER_API_TOKEN を設定してください。設定しない場合、1 日あたり 100 件までです。
法令/規則の照会(eCFR)
# Search regulations
python3 "$SKILL_DIR/scripts/ecfr_lookup.py" search "employment discrimination" --title 29
# Get specific CFR section
python3 "$SKILL_DIR/scripts/ecfr_lookup.py" section 16 444.1
# Search Federal Register for recent rules
python3 "$SKILL_DIR/scripts/ecfr_lookup.py" fedreg "data privacy"
API キーは不要です。
引用の書式
Bluebook の引用形式については、references/bluebook.mdを確認してください。主なルール:
- 判例: Party v. Party, Vol Reporter Page, Pin (Court Year)。
- 制定法: Title U.S.C. § Section (Year)。
- 規則: Title C.F.R. § Section (Year)。
- ピンポイント引用が必須 — 必ず具体的なページを引用してください。
- 初回の完全な引用の後の短縮形: Id.、supra、または当事者名+レポーター。
訴訟以外の文書(契約書、利用規約)では、通常、正式な引用は必要ありません。適用される法律を名称と条項で参照するだけで構いません。
フェーズ 3:セクションごとの執筆
文書の種類別の執筆順序
契約書: 定義 → 主要な義務 → 表明保証 → 補償 → 責任の制限 → 契約期間/解除 → 一般条項 → 前文/背景説明(適用範囲が明確になってから最後に作成)
メモ: 問題提起 → 簡潔な回答 → 事実の概要 → 検討(各争点について IRAC) → 結論
書面: 事実の概要 → 論拠(最も強い主張から) → はじめに/要約(述べる内容が明確になってから最後に作成) → 結論
訴状: 当事者 → 管轄/裁判地 → 事実の概要 → 請求原因 → 救済の請求
執筆の反復作業(各セクション)
1. READ all previously written sections for context
2. WRITE the section following document-type conventions
3. REGENERATE the DOCX (update via python-docx)
4. VERIFY: python3 verify-legal.py legal/{slug}/
5. If errors → FIX → go to 3
6. SELF-REFLECT:
- Is every legal assertion supported by authority? (litigation docs)
- Are defined terms used consistently?
- Any ambiguous language? ("reasonable" without standard, "timely" without deadline)
- Cross-references point to correct sections?
- No placeholder text remaining in this section?
7. REVISE if needed → regenerate → verify
8. Section DONE → next
法律文書の執筆基準
すべてのセクションで、以下を適用します。
形式より明瞭さを優先:
- 「prior to」ではなく「before」
- 「with respect to」ではなく「about」
- 「in the event that」ではなく「if」
- 「pursuant to」ではなく「under」
- 「in order to」ではなく「to」
正確さ:
- 「shall」=義務(当事者は X を行うものとする)
- 「will」=将来の出来事または宣言
- 「may」=許可(当事者は X を行ってもよい)
- 「must」=条件/要件
- 義務を課す以外の目的で「shall」を使用しないでください
定義語:
- 初出時に定義する:
"Effective Date" means [definition]. - 文書全体で一貫して大文字表記する:常に「Effective Date」とし、「effective date」は使用しない
- 定義セクションではアルファベット順に並べる
- 定義しすぎない(一般的な英単語を定義する必要はありません)
文の構成:
- 能動態:「The Contractor shall deliver」とし、「Delivery shall be made」としない
- 主語と動作を先に置く
- 契約書では一文につき一つの考えを述べる(義務ごとに一文)
- 段落は短くする(説得的な文書では最大 4~5 文)
数字と日付:
- 1~9 は綴りで表記し、10 以上は数字を使用する
- 日付:「January 15, 2025」(文書全体で統一)
- 金額:「$50,000」または「Fifty Thousand Dollars ($50,000)」(契約書では両方)
- 期間:契約書では「thirty (30) days」、メモ/書面では「30 days」
セクション別の指針
契約書:定義セクション
"Agreement" means this Services Agreement, including all exhibits and schedules.
"Confidential Information" means any information disclosed by one party to the
other that is designated as confidential or that reasonably should be understood
to be confidential given the nature of the information and the circumstances of
disclosure.
"Deliverables" means the work product to be delivered by Contractor as described
in Exhibit A.
契約書:責任の制限
IN NO EVENT SHALL EITHER PARTY BE LIABLE TO THE OTHER PARTY FOR ANY
INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES,
REGARDLESS OF THE CAUSE OF ACTION OR THE THEORY OF LIABILITY, EVEN IF
SUCH PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
THE TOTAL AGGREGATE LIABILITY OF [PARTY] UNDER THIS AGREEMENT SHALL NOT
EXCEED THE TOTAL FEES PAID BY [OTHER PARTY] DURING THE TWELVE (12) MONTH
PERIOD PRECEDING THE CLAIM.
メモ:IRAC による検討の構成
各法律上の争点について:
[ISSUE] The issue is whether [legal question under specific law/standard].
[RULE] Under [jurisdiction] law, [state the rule]. See [Authority]. The [court]
has held that [rule elaboration]. [Authority]. Courts consider [factors/elements]:
(1) [factor]; (2) [factor]; and (3) [factor]. [Authority].
[APPLICATION] Here, [apply each factor to the client's facts]. First, [fact]
satisfies [factor] because [reasoning]. See [analogous case]. Unlike in
[distinguishable case], where [different facts led to different outcome], here
[explain why our facts are more like the favorable case].
[CONCLUSION] Therefore, [conclusion on this issue]. A court would likely
[prediction].
書面:論拠の見出し
見出しは、説得力のある完全な文にしてください。
Good: "I. THE TRIAL COURT ERRED BY GRANTING SUMMARY JUDGMENT BECAUSE
GENUINE DISPUTES OF MATERIAL FACT EXIST."
Bad: "I. SUMMARY JUDGMENT"
Good: "A. Plaintiff's Deposition Testimony Creates a Triable Issue of Fact
Regarding Defendant's Knowledge of the Defect."
Bad: "A. Deposition Testimony"
訴状:番号付き段落
事実に関する主張は、それぞれ独立した番号付き段落にしてください。
12. On or about March 15, 2024, Plaintiff entered into a written agreement
with Defendant for the purchase of the Property (the "Purchase Agreement").
A true and correct copy of the Purchase Agreement is attached hereto as
Exhibit A and incorporated by reference.
13. Pursuant to Section 4.1 of the Purchase Agreement, Defendant represented
and warranted that the Property was free of all environmental contamination.
14. On or about June 1, 2024, Plaintiff discovered that the Property contained
significant levels of lead contamination in the soil.
フェーズ 4:推敲と最終確認
4a. 振り返り
文書全体を読み直し、次の点を確認します。
- 一貫性: 用語、当事者名、定義語が文書全体で統一されている
- 完全性: 文書の種類に必要なセクションがすべて含まれ、論理に抜けがない
- 相互参照: 並べ替え後の「Section X.Y」への参照がすべて正しい
- 定義語: 大文字で表記された用語がすべて定義され、すべての定義が使用されている
- 曖昧さ: 基準のない曖昧な用語や、指示対象が不明な代名詞がない
- プレースホルダー:
[INSERT]、[TBD]、[TODO]、空白行が残っていない - 日付と数字: 書式が文書全体で統一されている
- 引用: (訴訟文書の場合)すべての引用がピンポイントを含む Bluebook 形式になっている
4b. 厳格な検証
python3 "$SKILL_DIR/scripts/verify-legal.py" "legal/$SLUG/" --strict
すべてのチェックに合格する必要があります。
- 文書が存在し、十分な内容がある
- 定義語:すべて定義され、すべて使用され、一貫した大文字・小文字表記になっている
- 相互参照:条項/別紙/付属書への参照が有効である
- 引用:適切な形式である(訴訟書類のみ)
- プレースホルダー/TODO/草案の痕跡が一切ない
- 当事者名が一貫して使用されている
- 必須の定型条項が含まれている(契約書)
- 法助動詞の使い方が一貫している(shall/must/may/will)
- 語数が制限内である(準備書面)
- 日付形式が一貫している
4c. 最終出力
納品物は legal/{slug}/document.docx です。ユーザーが PDF を必要とする場合は、変換します。
# If libreoffice is available:
libreoffice --headless --convert-to pdf "legal/$SLUG/document.docx" --outdir "legal/$SLUG/"
# Or use python-docx2pdf:
pip install docx2pdf && python3 -c "from docx2pdf import convert; convert('legal/$SLUG/document.docx')"
DOCX の書式設定基準
DOCX を作成する際(docx スキル/python-docx を使用):
裁判所への提出書類(準備書面、申立書、訴状)
- フォント: Times New Roman、12pt(または Century Schoolbook、12pt)
- 行間: 本文はダブルスペース
- 余白: 四辺とも 1 インチ(現地の規則を確認してください。左側を 1.5 インチと定めている場合もあります)
- ページ番号: 下部中央
- 表題欄: 裁判所名、当事者、事件番号。裁判所が定める書式を使用してください
- 行番号: 一部の管轄区域で必須です(例:カリフォルニア州裁判所)
契約書および取引関連文書
- フォント: Times New Roman または Calibri、11~12pt
- 行間: シングルスペースまたは 1.15
- 余白: 四辺とも 1 インチ
- 条項番号: Article → Section:1.1、1.2、2.1 など
- 定義語: 初出時に太字にする
- 署名欄: 右揃えまたは中央揃えとし、署名/氏名/役職/日付の記入欄を設ける
- すべて大文字の表記: 使用は必要最低限にし、責任制限条項と免責条項に限る
- ヘッダー: 該当する場合は文書のタイトルと機密表示
- フッター: ページ番号、作業中の草案の場合は草案の日付
一般
- 見出しスタイル: Word の「見出し 1/2/3」スタイルを使用します(目次の自動生成が可能になります)
- 段落スタイル: 手動で書式設定せず、一貫した名前付きスタイルを使用します
- 改ページ: 主要な見出しの前に設定します(契約書では Article、準備書面では主要セクション)
- ウィドウ/オーファン制御: 有効にします(ページの上部/下部に行が単独で残らないようにします)
管轄区域ごとの注意事項
裁判所に文書を提出する前に、必ず現地の規則を確認してください。主な違いは次のとおりです。
| 管轄区域 | フォント | 行間 | 余白 | 特記事項 |
|---|---|---|---|---|
| 連邦控訴裁判所 | 14pt 比例セリフ体 | ダブル | 全辺 1" | 語数制限は巡回区によって異なる |
| 米国最高裁判所 | 12pt Century | 2pt の行送り | 専用テキスト欄 | 小冊子形式 |
| カリフォルニア州裁判所 | 13pt 以上の比例セリフ体 | ダブル | 左右 1.5" | 行番号が必須 |
| ニューヨーク州裁判所 | 12pt 以上の比例フォント | ダブル | 全辺 1" | 裁判所によって異なる |
| 大半の連邦地方裁判所 | 12pt TNR または同等のフォント | ダブル | 全辺 1" | 現地の規則を確認 |
迷った場合は、12pt の Times New Roman、ダブルスペース、1 インチの余白であれば、大半の裁判所で問題ありません。