SuperAPI AI Directory
Partner with us中文AI newsFavorites
Skillslegal-proposal-generator

legal-proposal-generator

Office & productivity

View repository

Updated 10-15 20:10

About this skill

Legal Service Document Generation Skill

Overview

Generate professional legal service documents from case materials or communication records. Supports multiple document types and uses a modular architecture to automatically match scenarios.

The primary delivery form for external service proposals iscase-by-case Markdown source draft + editable designed Word. When an HTML/PDF that requires no further modification and can be sent directly is needed, use legal-proposal-designer to render the same content; the other design capabilities of this Skill continue to evolve independently.

Core Principles：

  • Only perform information extraction, summarization, structuring, and transformation into professional expressions
  • Do not add new facts, and do not fabricate legal provisions or judicial opinions
  • Analyze and advise only based on the provided materials

Document Types

Litigation Service Proposal

Applicable Scenarios: The client has explicitly engaged for litigation and needs to present a complete service approach and work plan

Core Features：

  • Highlight legal analysis and strategy
  • Clarify service stages and content
  • Complete narrative in paragraph form
  • Includes an introduction to the service team, citing config/team-config.md

Template File：templates/litigation-proposal.md

Consultation Report

Applicable Scenarios: After an initial legal consultation, the client needs issue clarification and action guidance

Core Features：

  • Includes an evidence collection checklist (table + checkbox)
  • Practical tool-oriented
  • Highly actionable

Template File：templates/consultation-report.md

Non-Litigation Service Proposal

Applicable Scenarios: Non-litigation projects (such as compliance, transactions, due diligence, etc.) that require phased, modular services

Core Features：

  • Emphasizes project background and needs analysis
  • Phased service planning
  • Team configuration presentation (citing config/team-config.md）

Template File：templates/non-litigation-proposal.md

Legal Service Proposal

Applicable Scenarios: After offline communication with the client, a formal proposal needs to be submitted

Core Features：

  • Highly persuasive
  • Demonstrates professional capability and proposal value
  • Presents service content in stages
  • Includes service team and assurance sections, citing config/team-config.md

Template File：templates/service-proposal.md

Client Communication Report

Applicable Scenarios: Comprehensive records of complex cases that require a complete analytical framework

Core Features：

  • Complete 12-part structure
  • Includes cost-benefit analysis
  • Detailed action plan

Template File：templates/communication-report.md

Closing Report

Applicable Scenarios: After a case is concluded by judgment, mediation, settlement, withdrawal, or other means, a systematic report to the client is needed on the closing results, actual performance, and the differences between the client's authorization conditions and the final outcome

Core Features：

  • Focuses on post-closing results summary and client communication
  • Emphasizes the comparison of "client authorization conditions vs historical plans vs final actual outcome"
  • Clarify the case closure method, enforcement status, actual client expenditures, and follow-up reminders

Template file：templates/case-closing-report.md

Internal communication report

Applicable scenarios: Need other lawyers on the team to assist in verifying issues, discussing strategy, or cross-department collaboration

Core features：

  • Confidentiality level is fixed as "Internal Confidential"
  • Includes a dedicated section for "Team Internal Discussion Matters"
  • Clearly lists the matters that colleagues need to assist in verifying and the persons responsible

Template file：templates/internal-communication-report.md

Case analysis summary

Applicable scenarios: Upon receiving the original case materials (chat records, audio transcriptions, evidence materials, etc.), need to quickly extract key information and sort out the case facts

Core features：

  • 6-layer analysis framework (case information → factual context → legal relationships → points of dispute → evidence materials → legal issues)
  • Timeline Mermaid visualization
  • Evidence probative value assessment table
  • Internal working document, used for the team to quickly understand the case facts

Template file：templates/case-analysis-summary.md

Workflow

Step 1: Analyze the input and determine the document type

The selection of document type should comprehensively considerthe nature of the case(litigation vs non-litigation),the client stage, andthe document purpose。

Priority rules (must be strictly followed)：

  1. When the user explicitly specifies the document type, generate according to the type specified by the user
  2. When the user does not explicitly specify, determine according to the following logic:
    • Involving litigation/dispute resolution cases + the user requests generation of a "plan" or "service plan" → Litigation service plan
    • Involving non-litigation projects (compliance, transactions, due diligence, etc.) + the user requests generation of a "plan" or "service plan" → Non-litigation service plan
    • Only when the user **explicitly says "proposal"** should Legal service proposal
  3. ProhibitedWhen the user says "plan", automatically downgrading it to "proposal"—"plan" and "proposal" are different document types

Common scenarios：

Input content Client stage Document purpose Recommended type
Litigation/dispute case materials Any stage Demonstrate service approach and work plan Litigation service plan
Non-litigation project background materials Any stage Phased service planning, team configuration Non-litigation service plan
The user explicitly requests a "proposal" After communication, strive to secure engagement Persuade the client, demonstrate professional capabilities Legal service proposal
Initial consultation communication record Initial consultation Issue sorting, evidence collection guidance Consultation report
Multiple communication records Complex cases, comprehensive analysis Complete analysis framework, cost-benefit assessment Client communication report
Closed case materials Case closure wrap-up Report case closure results to the client Case Closure Report
Requires team collaboration/assistance with verification Team Collaboration Internal analysis, requesting assistance, discussing strategy Internal Communication Report
Original case materials (chat records, audio transcriptions, etc.) Early stage of the case Quickly extract key information and organize the case facts Case Analysis Summary

Key Determining Factors：

  • Nature of the case (primary): Litigation/dispute → litigation plan; non-litigation project → non-litigation plan
  • User's wording: "plan" ≠ "proposal", unless the user explicitly says "proposal"
  • Client stage: Initial consultation vs. multiple communications vs. already engaged
  • Presentation purpose: Internal work plan vs. external persuasive material

Step 2: Select the corresponding template

Select the corresponding template from templates/ according to the document type.

Step 2.5: Read the team configuration

Forlitigation service plan, non-litigation service plan, legal service proposalthese three types of external plan documents, read config/team-config.md to obtain the lead lawyer introduction, law firm profile, and partner information, and fill them into the team-related sections of the template.

  • The user will specify the lead lawyers (e.g., "the lead lawyers are Lawyer A and Lawyer B"). When the Markdown plan needs to display the team section, extract the corresponding lawyer content from the HTML table in team-config;when using the designed Word full version, do not insert the HTML table into the source draft, and the Word renderer will directly read the team configuration according to the selected names and generate editable cards.
  • Image paths must be converted to absolute paths: image references in team-config.md (e.g., images/avatar-xxx.png) are relative paths relative to the skill config directory and cannot be resolved in the output document. When generating the document, all image src values starting with images/ must be replaced with the absolute path prefix of this skill, namely SKILL_DIR/config/images/(where SKILL_DIR is the absolute path of the directory where this skill is located). For example, images/avatar-example.png should be replaced with /path/to/your/skills/legal-proposal-generator/config/images/avatar-example.png
  • The law firm profile can be quoted directly, or appropriately trimmed according to the project characteristics
  • Other document types (consultation report, communication report, case closure report, internal communication report, case analysis summary) do not require a team section

Step 3: Generate the document

Generate the content according to the template structure, following the writing requirements below:

General Writing Requirements：

  • Paragraph-style writing: Use paragraph descriptions and avoid excessive use of bullet points and dashes
  • Objective statement: State facts objectively and avoid subjective evaluations
  • Mark missing information: Use "[To be confirmed]" to mark missing or uncertain information
  • Professional expression: Use accurate legal terminology and maintain clear logic
  • Avoid pre-committing to quantifiable deliverables (self-binding protection): In the plan,do not write subsequent work that is "possible but not mandatory" as a specific list of deliverables that the client can quantitatively track(such as various assessment reports, response plans, reply opinion frameworks, and other named documents). Once such a list is written in, it is easy for the client to treat it as the lawyer's commitments and delivery milestones to track, tying the lawyer's hands and adding unnecessary workload; moreover, whether this work actually occurs depends on the other party's actions or procedural developments, and is inherently uncertain.
    • Correct approach: only flag the risk ("the other party may use filing XX as a countermeasure") + the lawyer provides a preliminary assessment; and make clear that "if it actually occurs, it will be accepted as an independent project under a separate engagement, handled on a dedicated basis, and the related fees will be negotiated at that time."
    • Applicable scenarios: all follow-up work that "depends on the other party's actions or procedural developments," such as responding to patent invalidation declarations, counterclaims, second instance/retrial, enforcement objections, and adding parties—all handled as "flag the risk + preliminary assessment + separate negotiation," without pre-listing specific deliverable documents in this plan.

Visualization extensions (optional)：

Mermaid diagrams may be used as needed to assist explanations; see Visualization Guide。

External visualization skill illustrations (recommended)：

For paragraphs requiring formal charts, such as case timelines, party relationships, procedural flows, evidence chains, service stages, and risk matrices, first scan the currently available visualization-type skills (such as legal-visualization、canvas-design , etc.), and according to the rules in Visualization Guide · External Visualization Skill Routing , select the most suitable one to produce high-fidelity graphics such as PNG/SVG/PDF, then insert them into the main text in the form of ![图示](绝对路径) .Do not hard-codeto a specific skill; if there is no suitable visualization skill in the current environment, fall back to the Mermaid inline approach.

Supplementary requirements for case closing reports：

  • The manner of case closure must be accurately distinguished; judgments, mediation, settlement, and withdrawal of claims must not be confused
  • If there is a discrepancy between the client's authorization conditions and the actual outcome, the reasons should be truthfully explained and must not be downplayed
  • Outcome-related information such as amounts, quantities, and performance status should preferably be verified against the case closing documents or communication records

Step 4: Save and generate deliverable files

First save the Markdown source draft, with the file name in the format of document type + case/project name. If litigation service plans, non-litigation service plans, and legal service proposals need to be delivered to the client, by default also generate a designed Word version; if the user only wants Markdown, deliver only the source draft. Other document types are handled in the format specified by the user.

The Word source draft must provide at the top law_firm、client、lawyer、date, and the first # is the cover title; these fields may also be supplemented on the command line. The main text may use chapter/section headings, paragraphs, simple lists, tables, quotations, and bold text.Do not repeatedly insert team-config's HTML team page into the Word source draft. First verify the content and team selection, then render; the formatter is not responsible for completing facts, legal provisions, or quotations. For the running method, JSON content contract, template token quick path, and cross-engine acceptance, see Word Pipeline Instructions。

Dependencies for generating the designed Word version：Node.js ≥ 22、docx package. On first use, run npm install -g docx; in the root directory of this Skill, run:

NODE_PATH=$(npm root -g) node word/render.js \
  --input /绝对路径/方案.md --output /绝对路径/方案.docx --cover C

When the user wants the complete version including the handling team, relevant judicial documents, law firm introduction, and honors, add --full --lawyers 姓名1,姓名2; the renderer by default reads from the local config/team-config.md , via --team-config Can be overridden. When no lead lawyer is selected, first determine based on the materials provided; do not arbitrarily list everyone in the configuration as the handling team. Before delivery, check that all referenced images have been redacted; check the DOCX and exported PDF page by page, and verify the cover page and pagination in actual WPS and Microsoft Word. The page count varies with the content; do not treat the 6/10 pages of existing cases as a fixed specification.

In Word, body page numbers start from 1, and the back appendix pages use the page name as the footer; for HTML/PDF, the "current page / total body pages" in Word retains only the updatable current page. For the specific layout correspondence and limitations, see Word pipeline documentation。

For a small number of variable-filled word/fill.py requires python-docx, execute on first use python3 -m pip install python-docx; it is only used for fixed templates and does not replace case-by-case body text generation.