contract-review-pro

name	contract-review-pro
description	Professional-grade contract review skill that adds comment-based issue annotations without changing original text. Enforces a four-layer review (entity verification, basic, business, legal), writes structured comments (issue type, risk reason, revision suggestion) with risk level encoded via reviewer name, and generates a contract summary, consolidated opinion, and Mermaid business flowchart (with rendered image). Output language must follow the contract’s language.
metadata	{"version":"0.2.0"}

Contract Review Skill

Overview

This skill performs contract reviews by adding comments only (no edits to the original text). It follows a four-layer review (entity verification, basic, business, legal) and generates:

• Annotated contract (.docx)
• Contract summary (.docx)
• Consolidated review opinion (.docx)
• Business flowchart (Mermaid + rendered image)

Language rule: detect the contract’s dominant language and output all generated content (comments, summary, opinion, flowchart text) in that language. Use the guidance in references/language.md.

Workflow

1. Unpack the contract (.docx) for XML operations
2. Read contract text (pandoc or XML)
3. Extract and verify contracting parties (Layer 0)
4. Execute three-layer clause review (Layer 1–3)
5. Add comments to the document
6. Generate contract summary
7. Generate consolidated opinion
8. Generate business flowchart and render image
9. Repack to .docx

Output Naming

• Output directory: 审核结果：{ContractName} for Chinese or Review_Result_{ContractName} for English
• Reviewed contract: {ContractName}_审核版.docx for Chinese or {ContractName}_Reviewed.docx for English
• Review report: 审核报告.txt for Chinese or Review_Report.txt for English

Comment Principles

• Comments only: do not modify the original text or formatting
• Precise anchoring: comment should target specific clauses/paragraphs
• Structured content: each comment includes issue type, risk reason, and revision suggestion
• Risk level: carried by reviewer name; do not include a “risk level” line in comment body
• Output language: use labels in the contract’s language (see references/language.md)

Comment example (English):

[Issue Type] Payment Terms
[Risk Reason] The total amount is stated as USD 100,000 in Section 3.2, but the payment clause lists USD 1,000,000 in Section 5.1. This inconsistency may cause disputes.
[Revision Suggestion] Align the total amount across clauses and clarify whether tax is included.

Review Standards

Use the four-layer review model and the detailed checklist in references/checklist.md.

Layer 0: Entity verification (subject authenticity)

• Extract all contracting parties (full legal names, credit codes, legal representatives)
• Verify each entity's registered name accuracy and business registration status
• Verification tool priority:
  1. If an MCP tool for business registration lookup is available in the current environment (e.g., enterprise info query, company lookup, 企业查询, 工商查询), use it to query each party's name or Unified Social Credit Code.
  2. If no such MCP tool is available, use Web Search to look up "[entity name] 工商登记信息" or "[entity name] business registration".
  3. Record the verification source (MCP tool name / Web Search) in the comment.

Layer 1: Basic (text quality)

• Accuracy of numbers, dates, terms
• Consistent numbering and references
• Clarity and lack of ambiguity
• Formatting and punctuation quality

Layer 2: Business terms

• Scope, deliverables, quantity/specs
• Pricing and payment schedule
• Delivery/acceptance procedures
• Rights/obligations and performance guarantees

Layer 3: Legal terms

• Effectiveness and term/termination
• Liability/penalties and remedies
• Dispute resolution and governing law
• Confidentiality, force majeure, IP, notice, authorization

Risk levels (encoded in reviewer name):

• 🔴 High: core business ambiguity (price, scope, rights/obligations)
• 🟡 Medium: material but non-core ambiguity
• 🔵 Low: minimal practical impact

Contract Summary

Generate a structured, objective summary in the contract’s language.

• See references/summary.md (English template)
• Use references/language.md for language selection and Chinese labels

Output file: 合同概要.docx for Chinese or Contract_Summary.docx for English (default font: 仿宋; adjust if language requires)

Consolidated Opinion

Generate a concise, two-paragraph response for the business team in the contract’s language.

• See references/opinion.md

Output file: 综合审核意见.docx for Chinese or Consolidated_Opinion.docx for English (default font: 仿宋; adjust if language requires)

Business Flowchart (Mermaid)

Generate Mermaid flowchart per requirements and render to image.

• See references/flowchart.md

Outputs:

• business_flowchart.mmd
• business_flowchart.png

li## Technical Notes

Core workflow:

1. Unpack → 2. Entity verification → 3. Add comments → 4. Summary → 5. Opinion → 6. Flowchart → 7. Repack

API & implementation details:

• references/technical.md

Dependencies

• Python 3.9+ (3.10+ recommended)
• pandoc (system install)
• defusedxml
• Mermaid CLI (mmdc) for rendering
• python-docx for rich text output

Troubleshooting (Short)

• Comments missing in Word: run doc.verify_comments() and re-save
• find_paragraph fails: shorten search text; confirm actual paragraph text
• Mermaid render fails: ensure mmdc installed; use Chrome path or Puppeteer config

Examples

See references/examples.md for a full workflow example.

Important Rules

1. Never alter original contract text
2. Entity verification (Layer 0) must complete before clause review (Layers 1–3)
3. Review all four layers, do not skip items
4. Ensure risk level is accurate and consistent
5. Keep comments precise, professional, and actionable
6. Flowchart must come strictly from the contract text
7. Summary is objective only; no risk analysis
8. Opinion only reflects findings already identified

License

SPDX-License-Identifier: Apache-2.0

Copyright (c) 2026 JiCheng

Licensed under the Apache License, Version 2.0. See repository root LICENSE.

通用反馈闭环

用户在 Skill 驱动任务中提出修改意见时，继续当前产物前必须执行：

1. 先判断意见是 task-specific（仅本次）还是 reusable（可跨任务复用）。
2. task-specific 只修改当前任务，不改 Skill。
3. reusable 先确定作用域：领域规则先更新对应 canonical Skill；适用于所有 Skill 的规则先更新共享规范。
4. 完成规则更新、版本、lint 与分发核验后，再把修改应用到当前任务。
5. reusable 修改会使此前的“确认”“继续”“发吧”失效；完成当前产物修改和回读后必须停下，等待用户下一步指示，不自动进入发布、提交或其他外部写入。