legal-writer
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseLegal Document Writer
法律文档撰写工具
Draft publication-quality legal documents in DOCX (Word) format with a test-driven workflow: every section is verified before moving to the next. Covers contracts, memos, briefs, complaints, demand letters, and more.
采用测试驱动工作流生成可用于发布的DOCX(Word)格式法律文档:每完成一个章节就进行验证,再进入下一章节。涵盖合同、备忘录、案情摘要、起诉状、催款函等多种文档类型。
Bundled Resources
配套资源
Find the skill directory via .
glob("**/KORTIX-legal-writer/")| Resource | Path | Purpose |
|---|---|---|
| Verifier | | TDD verification suite (10 checks) |
| Case law API | | CourtListener search/lookup for case citations |
| Regulation API | | eCFR + Federal Register lookup for statutes/regs |
| Bluebook ref | | Bluebook citation format quick reference |
| Doc type ref | | Section templates for every document type |
通过查找工具目录。
glob("**/KORTIX-legal-writer/")| 资源 | 路径 | 用途 |
|---|---|---|
| 验证器 | | TDD验证套件(包含10项检查) |
| 判例法API | | 用于判例引用的CourtListener搜索/检索工具 |
| 法规API | | 用于法规检索的eCFR + 联邦公报查询工具 |
| Bluebook参考指南 | | Bluebook引用格式速查手册 |
| 文档类型参考 | | 各类文档的章节模板 |
The TDD Rule
TDD规则
After writing every section of the document:
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 sectionThe document must pass verification at every step. Never batch errors.
完成文档的每个章节后:
1. 撰写章节内容
2. 生成:通过docx工具构建/更新DOCX文档
3. 验证:执行 python3 verify-legal.py legal/{slug}/
4. 若验证失败 → 修复问题 → 返回步骤2
5. 若验证通过 → 进入下一章节文档必须在每一步都通过验证,禁止批量处理错误。
Pipeline Overview
流程概述
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 ✓阶段1:搭建框架 → 创建项目、metadata.json、带结构的空白DOCX文档
验证:文档存在且章节结构正确 ✓
阶段2:法律调研 → 检索判例法、法规(适用于诉讼/合规类文档)
验证:引用格式正确 ✓
阶段3:分章撰写 → 按逻辑顺序逐章撰写内容
验证:每完成一个章节就执行verify-legal.py ✓
阶段4:打磨优化 → 自我复盘、严格验证、生成最终DOCX文档
验证:执行verify-legal.py --strict,确保零警告 ✓Filesystem Architecture
文件系统架构
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)legal/{document-slug}/
├── metadata.json # 文档类型、参与方、管辖区域等信息
├── document.docx # 主文档(通过docx工具生成)
├── research/ # 判例法、法规、笔记(可选)
│ ├── cases.json # CourtListener搜索结果
│ ├── regulations.json # eCFR检索结果
│ └── notes.md # 调研笔记
└── versions/ # 历史版本(可选)metadata.json
metadata.json
This file drives verification. Create it during scaffold:
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
}For briefs/motions, include or from court rules.
word_limitpage_limit该文件驱动验证流程,需在搭建框架阶段创建:
json
{
"type": "contract",
"title": "服务协议",
"jurisdiction": "特拉华州",
"governing_law": "特拉华州",
"date": "2025-01-15",
"parties": [
{"name": "Acme Corporation", "short_name": "甲方", "role": "客户"},
{"name": "Jane Smith Consulting LLC", "short_name": "乙方", "role": "承包商"}
],
"word_limit": null,
"page_limit": null
}对于案情摘要/动议文档,需添加法院规则要求的或字段。
word_limitpage_limitPhase 1: Scaffold
阶段1:搭建框架
1a. Identify document type
1a. 确定文档类型
Read for the section template matching the requested document type. The major types:
references/document-types.md| Type | Key | Use Case |
|---|---|---|
| Legal memorandum | | Internal analysis, predictive |
| Motion brief | | Persuasive, court filing |
| Contract/Agreement | | Transactional, bilateral obligations |
| Complaint/Petition | | Initiating litigation |
| Demand letter | | Pre-litigation claim |
| Legal opinion | | Formal legal opinion for transaction |
| Discovery requests | | Interrogatories, doc requests |
| Settlement agreement | | Resolving dispute |
| Terms of Service | | User-facing terms |
| Privacy Policy | | Data privacy compliance |
查阅,匹配请求文档类型的章节模板。主要文档类型如下:
references/document-types.md| 类型 | 标识 | 使用场景 |
|---|---|---|
| 法律备忘录 | | 内部分析、预测性文档 |
| 动议案情摘要 | | 说服性文档、法院提交文件 |
| 合同/协议 | | 交易类文档、双边义务约定 |
| 起诉状/请愿书 | | 启动诉讼程序 |
| 催款函 | | 诉前索赔 |
| 法律意见书 | | 交易类正式法律意见 |
| 证据开示请求 | | 质询、文件请求 |
| 和解协议 | | 纠纷解决 |
| 服务条款 | | 用户端条款 |
| 隐私政策 | | 数据合规文档 |
1b. Create project structure
1b. 创建项目结构
bash
SLUG="document-slug-here"
mkdir -p "legal/$SLUG"/{research,versions}bash
SLUG="document-slug-here"
mkdir -p "legal/$SLUG"/{research,versions}1c. Create metadata.json
1c. 创建metadata.json
Write the JSON file with document type, parties, jurisdiction, and any constraints.
编写JSON文件,包含文档类型、参与方、管辖区域及其他约束条件。
1d. Generate initial DOCX
1d. 生成初始DOCX文档
Load the skill. Use to create the document with:
docxpython-docx- Proper heading styles (Heading 1, 2, 3 for section structure)
- 12pt font (Times New Roman or similar serif for court filings)
- 1-inch margins (adjust per jurisdiction — see court rules)
- Double-spacing for briefs/court filings, single for contracts
- Proper page numbering
- Section headers matching the document type template from
references/document-types.md - Placeholder text: in each section
[TO BE DRAFTED]
加载工具,使用创建满足以下要求的文档:
docxpython-docx- 正确的标题样式(Heading 1、2、3对应章节结构)
- 12号字体(诉讼文件使用Times New Roman或类似衬线字体)
- 1英寸页边距(可根据管辖区域调整,需查阅法院规则)
- 案情摘要/诉讼文件采用双倍行距,合同采用单倍行距
- 正确的页码设置
- 章节标题与中的文档类型模板匹配
references/document-types.md - 每个章节填充占位符文本:
[待撰写]
1e. VERIFY: First green state
1e. 验证:初始合格状态
bash
python3 verify-legal.py legal/$SLUG/The scaffolded document should exist and have correct structure. Placeholders are expected at this stage (they'll be flagged as warnings, not failures, unless ).
--strictbash
python3 verify-legal.py legal/$SLUG/搭建完成的文档需存在且结构正确。此阶段的占位符属于预期内容(仅会被标记为警告,而非失败,除非使用参数)。
--strictPhase 2: Legal Research (if applicable)
阶段2:法律调研(如适用)
For litigation documents (memos, briefs, complaints) and regulatory documents, research case law and statutes before writing.
对于诉讼类文档(备忘录、案情摘要、起诉状)和合规类文档,需先检索判例法和法规再开始撰写。
Case Law Search (CourtListener)
判例法检索(CourtListener)
bash
SKILL_DIR="..." # from globbash
SKILL_DIR="..." # 来自glob命令结果Search for relevant cases
检索相关判例
python3 "$SKILL_DIR/scripts/courtlistener.py" search "search terms" --after 2015 --limit 10
python3 "$SKILL_DIR/scripts/courtlistener.py" search "搜索关键词" --after 2015 --limit 10
Get specific opinion details
获取具体判例详情
python3 "$SKILL_DIR/scripts/courtlistener.py" opinion 12345
python3 "$SKILL_DIR/scripts/courtlistener.py" opinion 12345
Format as Bluebook citation
转换为Bluebook引用格式
python3 "$SKILL_DIR/scripts/courtlistener.py" bluebook 12345
Save results to `research/cases.json`. Extract key holdings for use in the document.
**Note:** CourtListener requires a free API token for higher rate limits. Set `COURTLISTENER_API_TOKEN` env var. Without it, limited to 100 requests/day.python3 "$SKILL_DIR/scripts/courtlistener.py" bluebook 12345
将结果保存至`research/cases.json`,提取关键判决要点用于文档撰写。
**注意:** CourtListener需要免费API令牌以提高请求限制。设置环境变量`COURTLISTENER_API_TOKEN`即可使用。无令牌时,每日请求限制为100次。Statute/Regulation Lookup (eCFR)
法规检索(eCFR)
bash
undefinedbash
undefinedSearch regulations
搜索法规
python3 "$SKILL_DIR/scripts/ecfr_lookup.py" search "employment discrimination" --title 29
python3 "$SKILL_DIR/scripts/ecfr_lookup.py" search "就业歧视" --title 29
Get specific CFR section
获取特定CFR章节
python3 "$SKILL_DIR/scripts/ecfr_lookup.py" section 16 444.1
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"
No API key required.python3 "$SKILL_DIR/scripts/ecfr_lookup.py" fedreg "数据隐私"
无需API密钥。Citation Formatting
引用格式规范
Read for Bluebook citation format. Key rules:
references/bluebook.md- Cases: Party v. Party, Vol Reporter Page, Pin (Court Year).
- Statutes: Title U.S.C. § Section (Year).
- Regulations: Title C.F.R. § Section (Year).
- Pinpoint cites required — always cite to the specific page.
- Short forms after first full citation: Id., supra, or party name + reporter.
For non-litigation documents (contracts, ToS), formal citations are generally not needed — just reference applicable law by name and section.
查阅了解Bluebook引用格式。核心规则:
references/bluebook.md- 判例: 当事人诉当事人,卷数 判例汇编 页码,精准引用(法院 年份)。
- 法规: 卷数 U.S.C. § 条款号(年份)。
- 规章: 卷数 C.F.R. § 条款号(年份)。
- 必须使用精准引用 —— 始终指向具体页码。
- 首次引用后的简写形式: Id.、supra,或当事人名称+判例汇编。
对于非诉讼类文档(合同、服务条款),通常无需正式引用,只需提及适用法律的名称和条款号即可。
Phase 3: Per-Section Writing
阶段3:分章撰写
Writing Order by Document Type
按文档类型确定撰写顺序
Contract: Definitions → Core obligations → Reps & warranties → Indemnification → Limitation of liability → Term/termination → General provisions → Preamble/recitals (last, once scope is clear)
Memo: Question Presented → Brief Answer → Statement of Facts → Discussion (IRAC per issue) → Conclusion
Brief: Statement of Facts → Argument (strongest points first) → Introduction/Summary (last, once you know what to say) → Conclusion
Complaint: Parties → Jurisdiction/Venue → Statement of Facts → Causes of Action → Prayer for Relief
合同: 定义条款 → 核心义务 → 陈述与保证 → 赔偿条款 → 责任限制 → 期限与终止 → 通用条款 → 前言/叙述条款(最后撰写,待范围明确后)
备忘录: 提出问题 → 简要回答 → 事实陈述 → 讨论(按IRAC框架分问题) → 结论
案情摘要: 事实陈述 → 论点(先阐述最有力的观点) → 引言/摘要(最后撰写,待内容确定后) → 结论
起诉状: 当事人信息 → 管辖与地点 → 事实陈述 → 诉讼请求 → 救济请求
The Writing Loop (for each section)
单章节撰写循环
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 → next1. 阅读所有已撰写章节以获取上下文
2. 遵循文档类型规范撰写当前章节
3. 重新生成DOCX文档(通过python-docx更新)
4. 验证:执行python3 verify-legal.py legal/{slug}/
5. 若存在错误 → 修复问题 → 返回步骤3
6. 自我复盘:
- 所有法律主张是否有权威依据?(诉讼类文档)
- 定义术语是否使用一致?
- 是否存在模糊表述?(如未明确标准的“合理”、未设定期限的“及时”)
- 交叉引用是否指向正确章节?
- 当前章节是否无剩余占位符?
7. 如需修改 → 重新生成 → 验证
8. 章节完成 → 进入下一章节Legal Writing Standards
法律撰写标准
Apply these throughout all sections:
Clarity over formality:
- "before" not "prior to"
- "about" not "with respect to"
- "if" not "in the event that"
- "under" not "pursuant to"
- "to" not "in order to"
Precision:
- "shall" = duty/obligation (the party SHALL do X)
- "will" = future event or declaration
- "may" = permission (the party MAY do X)
- "must" = condition/requirement
- Never use "shall" for anything other than imposing a duty
Defined terms:
- Define on first use:
"Effective Date" means [definition]. - Capitalize consistently throughout: always "Effective Date", never "effective date"
- Alphabetize in definitions section
- Don't over-define (common English words don't need definitions)
Sentence structure:
- Active voice: "The Contractor shall deliver" not "Delivery shall be made"
- Front-load: put the actor and action first
- One idea per sentence in contracts (each obligation = one sentence)
- Short paragraphs (max 4-5 sentences in persuasive writing)
Numbers and dates:
- Spell out numbers 1-9, use digits for 10+
- Dates: "January 15, 2025" (consistent throughout)
- Money: "$50,000" or "Fifty Thousand Dollars ($50,000)" (for contracts, both)
- Time periods: "thirty (30) days" in contracts; "30 days" in memos/briefs
所有章节均需遵循以下标准:
清晰优先于正式:
- 使用“before”而非“prior to”
- 使用“about”而非“with respect to”
- 使用“if”而非“in the event that”
- 使用“under”而非“pursuant to”
- 使用“to”而非“in order to”
精准性:
- “shall” = 义务/责任(一方SHALL做某事)
- “will” = 未来事件或声明
- “may” = 许可(一方MAY做某事)
- “must” = 条件/要求
- “shall”仅用于设定义务,不得用于其他场景
定义术语:
- 首次使用时定义:
"生效日"指[定义内容]。 - 全程保持大写:始终使用“生效日”,而非“生效日”小写形式
- 定义条款按字母顺序排列
- 避免过度定义(通用英文词汇无需定义)
句子结构:
- 使用主动语态:“承包商应交付”而非“交付应由承包商完成”
- 前置核心信息:将行为主体和动作放在句首
- 合同中一句表达一个含义(每项义务对应一个句子)
- 说服性文档中段落简短(最多4-5个句子)
数字与日期:
- 1-9用英文拼写,10及以上用阿拉伯数字
- 日期格式:“January 15, 2025”(全程保持一致)
- 金额:合同中使用“$50,000”或“Fifty Thousand Dollars ($50,000)”两种格式;备忘录/案情摘要中使用“$50,000”
- 期限:合同中使用“thirty (30) days”;备忘录/案情摘要中使用“30 days”
Section-Specific Guidance
分章节撰写指南
Contracts: Definitions Section
合同:定义条款示例
"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."协议"指本服务协议,包括所有附件和附表。
"保密信息"指一方披露给另一方的、标记为保密的信息,或根据信息性质和披露场景可合理判断为保密的信息。
"交付成果"指承包商需交付的工作成果,详见附件A。Contracts: Limitation of Liability
合同:责任限制条款示例
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.无论基于何种诉因或责任理论,即使一方已被告知可能发生此类损害,任何一方均不对另一方承担任何间接、附带、特殊、 consequential或惩罚性损害赔偿。
[一方]在本协议项下的全部累计赔偿责任,不得超过[另一方]在索赔发生前12个月内支付的总费用。Memos: IRAC Discussion Structure
备忘录:IRAC讨论结构示例
For each legal issue:
[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].针对每个法律问题:
[问题] 争议焦点为[特定法律/标准下的法律问题]。
[规则] 根据[管辖区域]法律,[陈述规则]。参见[权威依据]。[法院]曾判决[规则阐述]。[权威依据]。法院考量以下[因素/要件]:
(1) [因素1]; (2) [因素2]; (3) [因素3]。[权威依据]。
[适用] 本案中,[将每个因素应用于客户事实]。首先,[事实]满足[因素],因为[推理过程]。参见[类似判例]。与[可区分判例]不同(该案中[不同事实导致不同结果]),本案中[解释为何我方事实更接近有利判例]。
[结论] 因此,[本问题的结论]。法院很可能[预测结果]。Briefs: Argument Headings
案情摘要:论点标题示例
Headings should be complete persuasive sentences:
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"标题应为完整的说服性句子:
正确示例: "I. 初审法院准予简易判决存在错误,因为存在重大事实争议。"
错误示例: "I. 简易判决"
正确示例: "A. 原告的 deposition 证词就被告对缺陷的知情情况创造了可审判的事实争议。"
错误示例: "A. Deposition 证词"Complaints: Numbered Paragraphs
起诉状:编号段落示例
Every factual allegation gets its own numbered paragraph:
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.每个事实主张单独列为一个编号段落:
12. 约2024年3月15日,原告与被告就该房产的购买签订书面协议(“购买协议”)。购买协议的真实副本作为附件A附于本文并纳入参考。
13. 根据购买协议第4.1条,被告陈述并保证该房产无任何环境污染。
14. 约2024年6月1日,原告发现该房产土壤中含有大量铅污染。Phase 4: Polish & Final Verification
阶段4:打磨优化与最终验证
4a. Self-Reflection Pass
4a. 自我复盘检查
Re-read the entire document and check:
- Consistency: Same terminology, same party names, same defined terms throughout
- Completeness: All required sections present for document type, no gaps in logic
- Cross-references: Every "Section X.Y" reference is correct after any reordering
- Defined terms: Every capitalized term is defined, every definition is used
- Ambiguity: No vague terms without standards, no dangling pronouns
- Placeholders: Zero ,
[INSERT],[TBD], or blank lines remaining[TODO] - Dates and numbers: Consistent format throughout
- Citations: (for litigation docs) All citations in Bluebook format with pinpoints
通读全文并检查以下内容:
- 一致性: 术语、当事人名称、定义术语全程保持一致
- 完整性: 文档类型要求的所有章节齐全,逻辑无漏洞
- 交叉引用: 所有“第X.Y条”引用在章节调整后仍正确
- 定义术语: 所有大写术语均已定义,所有定义均已使用
- 模糊性: 无未明确标准的模糊术语,无指代不明的代词
- 占位符: 无、
[INSERT]、[TBD]或空白行残留[TODO] - 日期与数字: 格式全程一致
- 引用: (诉讼类文档)所有引用均为带精准页码的Bluebook格式
4b. Strict Verification
4b. 严格验证
bash
python3 "$SKILL_DIR/scripts/verify-legal.py" "legal/$SLUG/" --strictAll checks must pass:
- Document exists and is non-trivial size
- Defined terms: all defined, all used, consistent capitalization
- Cross-references: section/exhibit/schedule references valid
- Citations: proper format (litigation docs only)
- Zero placeholders / TODOs / draft artifacts
- Party names used consistently
- Required boilerplate provisions present (contracts)
- Modal verb consistency (shall/must/may/will)
- Word count within limits (briefs)
- Date format consistency
bash
python3 "$SKILL_DIR/scripts/verify-legal.py" "legal/$SLUG/" --strict所有检查必须通过:
- 文档存在且大小符合要求
- 定义术语:全部已定义、已使用、大写一致
- 交叉引用:章节/附件/附表引用有效
- 引用格式:符合规范(仅适用于诉讼类文档)
- 无占位符/TODO/草稿残留
- 当事人名称使用一致
- 合同必备通用条款齐全
- 情态动词使用一致(shall/must/may/will)
- 字数符合限制(案情摘要)
- 日期格式一致
4c. Final Output
4c. 最终输出
The deliverable is . If the user needs PDF, convert:
legal/{slug}/document.docxbash
undefined交付物为。若用户需要PDF格式,可进行转换:
legal/{slug}/document.docxbash
undefinedIf libreoffice is available:
若安装了libreoffice:
libreoffice --headless --convert-to pdf "legal/$SLUG/document.docx" --outdir "legal/$SLUG/"
libreoffice --headless --convert-to pdf "legal/$SLUG/document.docx" --outdir "legal/$SLUG/"
Or use python-docx2pdf:
或使用python-docx2pdf:
pip install docx2pdf && python3 -c "from docx2pdf import convert; convert('legal/$SLUG/document.docx')"
undefinedpip install docx2pdf && python3 -c "from docx2pdf import convert; convert('legal/$SLUG/document.docx')"
undefinedDOCX Formatting Standards
DOCX格式标准
When generating the DOCX (via skill / ):
docxpython-docx通过工具/生成DOCX文档时,需遵循以下标准:
docxpython-docxCourt Filings (briefs, motions, complaints)
法院提交文件(案情摘要、动议、起诉状)
- Font: Times New Roman, 12pt (or Century Schoolbook 12pt)
- Spacing: Double-spaced body text
- Margins: 1 inch all sides (check local rules — some require 1.5" left)
- Page numbers: Bottom center
- Caption: Court name, parties, case number — use the court's required format
- Line numbers: Required in some jurisdictions (e.g., California state courts)
- 字体: Times New Roman,12号(或Century Schoolbook 12号)
- 行距: 正文双倍行距
- 页边距: 四边均为1英寸(需查阅当地规则——部分法院要求左侧1.5英寸)
- 页码: 底部居中
- 标题栏: 法院名称、当事人、案号——使用法院要求的格式
- 行号: 部分管辖区域要求(如加利福尼亚州法院)
Contracts and Transactional Documents
合同与交易类文档
- Font: Times New Roman or Calibri, 11-12pt
- Spacing: Single-spaced or 1.15
- Margins: 1 inch all sides
- Section numbering: Article → Section: 1.1, 1.2, 2.1, etc.
- Defined terms: Bold on first definition
- Signature blocks: Right-aligned or centered, with lines for signature/name/title/date
- All-caps: Use sparingly — limitation of liability and disclaimer sections only
- Headers: Document title + confidential marking if applicable
- Footers: Page numbers, draft date if working draft
- 字体: Times New Roman或Calibri,11-12号
- 行距: 单倍行距或1.15倍行距
- 页边距: 四边均为1英寸
- 章节编号: 编章→条款:1.1、1.2、2.1等
- 定义术语: 首次定义时加粗
- 签名栏: 右对齐或居中,预留签名/姓名/职位/日期的空白行
- 全大写: 谨慎使用——仅用于责任限制和免责条款
- 页眉: 文档标题+保密标记(如适用)
- 页脚: 页码、草稿日期(如为工作草稿)
General
通用要求
- Heading styles: Use Word Heading 1/2/3 styles (enables auto TOC)
- Paragraph styles: Use consistent named styles, not manual formatting
- Page breaks: Before major section headings (Articles in contracts, main sections in briefs)
- Widow/orphan control: Enabled (no single lines at page top/bottom)
- 标题样式: 使用Word的Heading 1/2/3样式(支持自动生成目录)
- 段落样式: 使用一致的命名样式,避免手动格式调整
- 分页符: 主要章节标题前插入分页符(合同中的编章、案情摘要中的主要部分)
- 孤行控制: 启用(避免页面顶部/底部出现单行文本)
Jurisdiction-Specific Notes
管辖区域特定说明
Always check local rules before filing any court document. Key variations:
| Jurisdiction | Font | Spacing | Margins | Special |
|---|---|---|---|---|
| Federal appellate | 14pt proportional serif | Double | 1" all | Word limit varies by circuit |
| U.S. Supreme Court | 12pt Century | 2pt leading | Special text field | Booklet format |
| California state | 13pt+ proportional serif | Double | 1.5" left/right | Line numbers required |
| New York state | 12pt+ proportional | Double | 1" all | Varies by court |
| Most federal district | 12pt TNR or similar | Double | 1" all | Check local rules |
When in doubt: 12pt Times New Roman, double-spaced, 1-inch margins is safe for most courts.
提交法院文档前务必查阅当地规则。主要差异如下:
| 管辖区域 | 字体 | 行距 | 页边距 | 特殊要求 |
|---|---|---|---|---|
| 联邦上诉法院 | 14号比例衬线字体 | 双倍 | 四边1英寸 | 字数限制因巡回法院而异 |
| 美国最高法院 | 12号Century字体 | 2pt行距 | 特殊文本字段 | 小册子格式 |
| 加利福尼亚州法院 | 13号及以上比例衬线字体 | 双倍 | 左右1.5英寸 | 要求行号 |
| 纽约州法院 | 12号及以上比例字体 | 双倍 | 四边1英寸 | 因法院而异 |
| 多数联邦地区法院 | 12号Times New Roman或类似字体 | 双倍 | 四边1英寸 | 查阅当地规则 |
如有疑问:12号Times New Roman字体、双倍行距、1英寸页边距适用于大多数法院。