OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add cat-xierluo/legal-skills --skill legal-proposal-generator
根据案件材料或沟通记录生成诉讼方案、非诉方案、建议书、咨询报告、结案汇报等法律服务文档；对外方案可直接生成带设计版式、可编辑的 Word（C/D/E/F 四款封面，可选团队与律所附页）。用户需要法律服务文档或设计版 Word 方案时使用。
npx skills add cat-xierluo/legal-skills --skill legal-proposal-generator
从案件材料或沟通记录生成专业法律服务文档。支持多种文档类型，采用模块化架构自动匹配场景。
对外服务方案的主交付形态为逐案 Markdown 源稿 + 可编辑设计版 Word。需要不再修改、直接发送的 HTML/PDF 时，另用 legal-proposal-designer 渲染同一份内容；该 Skill 的其他设计化能力继续独立演进。
核心原则：
适用场景：客户已明确委托诉讼，需要展示完整的服务思路和工作计划
核心特点：
模板文件：templates/litigation-proposal.md
适用场景：初次法律咨询后，客户需要问题梳理和行动指引
核心特点：
模板文件：templates/consultation-report.md
适用场景：非诉项目（如合规、交易、尽职调查等），需要分阶段、模块化服务
核心特点：
模板文件：templates/non-litigation-proposal.md
适用场景：与客户线下沟通后，需要正式提交方案建议
核心特点：
模板文件：templates/service-proposal.md
适用场景：复杂案件的全面记录，需要完整的分析框架
核心特点：
模板文件：templates/communication-report.md
适用场景：案件以判决、调解、和解、撤诉等方式收口后，需要向客户系统汇报结案结果、实际履行情况、客户授权条件与最终结果差异
核心特点：
模板文件：templates/case-closing-report.md
适用场景：需要团队其他律师协助核实问题、讨论策略或跨部门协作
核心特点：
模板文件：templates/internal-communication-report.md
适用场景：收到案件原始材料（聊天记录、录音转写、证据材料等），需要快速提取关键信息、梳理案情
核心特点：
模板文件：templates/case-analysis-summary.md
文档类型的选择应综合考虑案件性质（诉讼 vs 非诉）、客户阶段和文档目的。
优先级规则（必须严格遵守）：
常见场景：
| 输入内容 | 客户阶段 | 文档目的 | 推荐类型 |
|---|---|---|---|
| 诉讼/争议案件材料 | 任何阶段 | 展示服务思路和工作计划 | 诉讼服务方案 |
| 非诉项目背景材料 | 任何阶段 | 分阶段服务规划、团队配置 | 非诉服务方案 |
| 用户明确要求"建议书" | 沟通后争取签约 | 说服客户、展示专业能力 | 法律服务建议书 |
| 初次咨询沟通记录 | 初次咨询 | 问题梳理、证据收集指引 | 咨询报告 |
| 多次沟通记录 | 复杂案件、全面分析 | 完整分析框架、成本效益评估 | 客户沟通报告 |
| 已结案材料 | 结案收口 | 向客户汇报结案结果 | 结案汇报 |
| 需要团队协作/协助核实 | 团队协作 | 内部分析、请求协助、讨论策略 | 内部沟通报告 |
| 原始案件材料（聊天记录、录音转写等） | 案件初期 | 快速提取关键信息、梳理案情 | 案件分析摘要 |
关键判断因素：
根据文档类型选择 templates/ 中的对应模板。
对于诉讼服务方案、非诉服务方案、法律服务建议书三类对外方案文档，读取 config/team-config.md 获取主办律师介绍、律所简介和合作伙伴信息，填入模板的团队相关章节。
images/avatar-xxx.png）是相对于 skill config 目录的相对路径，在输出文档中无法解析。生成文档时，须将所有 images/ 开头的图片 src 替换为本 skill 的绝对路径前缀，即 SKILL_DIR/config/images/（其中 SKILL_DIR 为本 skill 所在目录的绝对路径）。例如 images/avatar-example.png 应替换为 /path/to/your/skills/legal-proposal-generator/config/images/avatar-example.png按模板结构生成内容，遵循以下写作要求：
通用写作要求：
可视化扩展（可选）：
可根据需要使用 Mermaid 图表辅助说明，详见 可视化指南。
外部可视化 skill 配图（推荐）：
对于案件时间轴、主体关系、程序流程、证据链、服务阶段、风险矩阵等需要正式图表的段落，优先扫描当前可用的可视化类 skill（如 legal-visualization、canvas-design 等），按 可视化指南 · 外部可视化 skill 路由 的规则选用最合适的一个产出 PNG/SVG/PDF 等高保真图件，再以  形式插入正文。不要硬编码到某个具体 skill；如果当前环境没有合适的可视化 skill，退回 Mermaid 内联方案。
结案汇报补充要求：
先保存 Markdown 源稿，文件名格式为文档类型+案件/项目名称。诉讼服务方案、非诉服务方案和法律服务建议书如需向客户交付，默认再生成设计版 Word；用户只要 Markdown 时仅交付源稿。其他文档类型按用户指定格式处理。
Word 源稿须在顶部提供 law_firm、client、lawyer、date，首个 # 为封面标题；也可在命令行补充这些字段。正文可用章/节标题、段落、简单列表、表格、引文和加粗。不要在 Word 源稿中重复插入 team-config 的 HTML 团队页。先核实内容和团队选择，再渲染；排版器不负责补全事实、法条或报价。运行方式、JSON 内容契约、模板 token 快速通道及跨引擎验收见 Word 管线说明。
生成设计版 Word 的依赖：Node.js ≥ 22、docx 包。首次使用执行 npm install -g docx；在本 Skill 根目录运行：
用户要包含承办团队、相关裁判文书、律所简介和荣誉的完整版时，增加 --full --lawyers 姓名1,姓名2；渲染器默认从本地 config/team-config.md 读取，经 --team-config 可覆盖。未选主办律师时先根据已提供材料确定，不能随意把配置中所有人列为承办团队。交付前检查所有引用图片已脱敏；逐页检查 DOCX 及导出的 PDF，并在实际 WPS、Microsoft Word 中核对封面和分页。页数随内容变化，不把既有案例的 6/10 页当作固定规范。
Word 的正文页码从 1 起算，后部附页用页名作页脚；HTML/PDF 的“当前页 / 正文总页数”在 Word 中只保留可更新的当前页。具体版式对应关系和限制见 Word 管线说明。
少量变量填充的 word/fill.py 需 python-docx，首次使用执行 python3 -m pip install python-docx；它只用于固定模板，不代替逐案正文生成。