name: legal-proposal-generator homepage: https://github.com/cat-xierluo/legal-skills author: 楊衛薪律師（微信ywxlaw） version: "0.3.1" license: CC-BY-NC description: 根據案件材料或溝通記錄生成各類法律服務文件（訴訟方案、諮詢報告、非訴方案、建議書、溝通報告、結案彙報、案件分析摘要等）。本技能應在使用者需要將案件材料、諮詢記錄或溝通內容整理為專業法律文件時使用。 slug: legal-proposal-generator displayName: "法律服務文件生成"

法律服務文件生成技能

概述

從案件材料或溝通記錄生成專業法律服務文件。支援多種文件型別，採用模組化架構自動匹配場景。

核心原則：

• 只做資訊提取、歸納、結構化與專業表述轉化
• 不新增事實，不虛構法條或裁判觀點
• 僅基於提供的材料進行分析和建議

文件型別

訴訟服務方案

適用場景：客戶已明確委託訴訟，需要展示完整的服務思路和工作計劃

核心特點：

• 突出法律分析和策略
• 明確服務階段和內容
• 段落式完整敘述
• 包含服務團隊介紹，引用 config/team-config.md

模板檔案：templates/litigation-proposal.md

諮詢報告

適用場景：初次法律諮詢後，客戶需要問題梳理和行動指引

核心特點：

• 包含證據收集清單（表格+checkbox）
• 實用工具導向
• 可操作性強

模板檔案：templates/consultation-report.md

非訴服務方案

適用場景：非訴專案（如合規、交易、盡職調查等），需要分階段、模組化服務

核心特點：

• 強調專案背景和需求分析
• 分階段服務規劃
• 團隊配置展示（引用 config/team-config.md）

模板檔案：templates/non-litigation-proposal.md

法律服務建議書

適用場景：與客戶線下溝通後，需要正式提交方案建議

核心特點：

• 說服性較強
• 展示專業能力和方案價值
• 分階段展示服務內容
• 包含服務團隊與保障章節，引用 config/team-config.md

模板檔案：templates/service-proposal.md

客戶溝通報告

適用場景：複雜案件的全面記錄，需要完整的分析框架

核心特點：

• 12部分完整結構
• 包含成本效益分析
• 詳細的行動計劃

模板檔案：templates/communication-report.md

結案彙報

適用場景：案件以判決、調解、和解、撤訴等方式收口後，需要向客戶系統彙報結案結果、實際履行情況、客戶授權條件與最終結果差異

核心特點：

• 聚焦結案後的結果彙總與客戶溝通
• 強調“客戶授權條件 vs 歷史方案 vs 最終實際”對比
• 明確結案方式、執行情況、客戶實際支出和後續提醒

模板檔案：templates/case-closing-report.md

內部溝通報告

適用場景：需要團隊其他律師協助核實問題、討論策略或跨部門協作

核心特點：

• 保密等級固定為"內部機密"
• 包含"團隊內部討論事項"專節
• 明確列出需要同事協助核實的事項和負責人

模板檔案：templates/internal-communication-report.md

案件分析摘要

適用場景：收到案件原始材料（聊天記錄、錄音轉寫、證據材料等），需要快速提取關鍵資訊、梳理案情

核心特點：

• 6 層分析框架（案件資訊 → 事實脈絡 → 法律關係 → 爭議焦點 → 證據材料 → 法律問題）
• 時間線 Mermaid 視覺化
• 證據證明力評估表格
• 內部工作文件，用於團隊快速瞭解案情

模板檔案：templates/case-analysis-summary.md

本技能來自小蔥技能站7w4.net。

工作流程

步驟 1: 分析輸入並確定文件型別

文件型別的選擇應綜合考慮案件性質（訴訟 vs 非訴）、客戶階段和文件目的。

優先順序規則（必須嚴格遵守）：

1. 使用者明確指定文件型別時，按使用者指定的型別生成
2. 使用者未明確指定時，按以下邏輯判斷：
3. 涉及訴訟/爭議解決案件 + 使用者要求生成"方案"或"服務方案" → 訴訟服務方案
4. 涉及非訴專案（合規、交易、盡調等）+ 使用者要求生成"方案"或"服務方案" → 非訴服務方案
5. 只有當用戶明確說"建議書"時，才生成 法律服務建議書
6. 禁止在使用者說"方案"時自動降級為"建議書"——"方案"和"建議書"是不同的文件型別

常見場景：

關鍵判斷因素：

• 案件性質（首要）：訴訟/爭議 → 訴訟方案；非訴專案 → 非訴方案
• 使用者措辭："方案" ≠ "建議書"，除非使用者明確說"建議書"
• 客戶階段：初次諮詢 vs. 多次溝通 vs. 已委託
• 呈現目的：內部工作計劃 vs. 對外說服材料

步驟 2: 選擇對應模板

根據文件型別選擇 templates/ 中的對應模板。

步驟 2.5: 讀取團隊配置

對於訴訟服務方案、非訴服務方案、法律服務建議書三類對外方案文件，讀取 config/team-config.md 獲取主辦律師介紹、律所簡介和合作夥伴資訊，填入模板的團隊相關章節。

• 使用者會指定主辦律師（如"主辦律師是律師 A 和律師 B"），從 team-config 的 HTML 表格中提取對應律師的 <tr> 塊（含頭像 rowspan），直接插入方案的服務團隊章節
• 圖片路徑必須轉為絕對路徑：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
• 律所簡介可直接引用，也可根據專案特點做適當裁剪
• 其他文件型別（諮詢報告、溝通報告、結案彙報、內部溝通報告、案件分析摘要）無需團隊章節

步驟 3: 生成文件

按模板結構生成內容，遵循以下寫作要求：

通用寫作要求：

• 段落式寫作：使用段落描述，避免過多使用小點和橫槓
• 客觀陳述：事實部分客觀陳述，避免主觀評價
• 缺失資訊標註：用「[待確認]」標註缺失或不確定的資訊
• 專業表述：使用準確的法律術語，邏輯清晰
• 避免預承諾可量化交付物（自縛手腳防護）：方案中不要把後續"可能但非必經"的工作寫成具體的、可被客戶量化追蹤的交付物清單（如各類評估報告、應對預案、答覆意見框架等具名檔案）。這類清單一旦寫入，易被客戶當作律師承諾與交付節點追蹤，律師自縛手腳、徒增不必要工作量；且這些工作是否實際發生取決於對方行為或程式進展，本身具有不確定性。
• 正確寫法：只提示風險（"對方可能以提起 XX 作為反制手段"）+ 律師作初步評估；並明確"如實際發生，作為獨立專案另行接受委託、專項應對，相關費用屆時協商"。
• 適用場景：專利無效宣告應對、反訴、二審/再審、執行異議、追加當事人等一切"取決於對方行為或程式進展"的後續工作——均按"提示風險 + 初步評估 + 另行協商"處理，不在本方案裡預列具體交付檔案。

視覺化擴充套件（可選）：

可根據需要使用 Mermaid 圖表輔助說明，詳見 視覺化指南。

外部視覺化 skill 配圖（推薦）：

對於案件時間軸、主體關係、程式流程、證據鏈、服務階段、風險矩陣等需要正式圖表的段落，優先掃描當前可用的視覺化類 skill（如 legal-visualization、canvas-design 等），按 視覺化指南 · 外部視覺化 skill 路由 的規則選用最合適的一個產出 PNG/SVG/PDF 等高保真圖件，再以 ![圖示](絕對路徑) 形式插入正文。不要硬編碼到某個具體 skill；如果當前環境沒有合適的視覺化 skill，退回 Mermaid 內聯方案。

結案彙報補充要求：

• 必須準確區分結案方式，不得混淆判決、調解、和解、撤訴
• 如存在客戶授權條件與實際結果差異，應如實說明原因，不得淡化
• 金額、數量、履行狀態等結果性資訊應優先回到結案文書或溝通記錄核對

步驟 4: 儲存輸出

自動儲存為 Markdown 檔案，檔名格式為文件型別+案件/專案名稱。

這是一款專業的法律文件生成工具，能根據案件材料自動生成訴訟方案、諮詢報告等8種不同型別的法律文件，模組化設計讓各文件結構清晰、邏輯一致，還支援時間線視覺化等實用功能。整體質量較高，文件型別選擇邏輯合理，寫作規範考慮到了律師實際工作中的風險防護。不足之處是缺少基礎使用說明文件，首次使用可能需要花時間理解各文件型別的區別；對新手使用者而言，團隊介紹等個性化配置的設定流程稍顯複雜。