contract-copilot

Contract Copilot (Contract Assistant)

I. Positioning

When invoked, first determine the operating process according to this document.

1.1 Mandatory File Delivery Rule

When a user provides or transmits a DOCX contract file through a conversation and makes contract review-type requests such as "review, audit, revise, comment, track changes, issue review opinions, help me look at the contract", the file delivery chain must be followed by default:

First complete the necessary clarification and layered review.
Organize the review conclusions into review-plan.json（runtime artifact, generated by contract-copilot during the review process; it is not a file bundled with the skill package, and is regenerated for each review).
Run scripts/review/apply_review_plan.py or scripts/run_apply_review_plan.ps1, passing in the review-plan.json。
apply_review_plan.py generated in the previous step will be automatically generated within archive/<时间戳_合同名>/ inside review-plan_enriched.json（runtime artifact, including expanded information such as completion of legal bases; it is not a file bundled with the skill package).
Deliver externally the reviewed and revised DOCX and the Word review opinion letter DOCX.

It is not permitted to substitute file delivery with only a text-based risk list, review summary, or chat reply, unless one of the following circumstances occurs:

The user explicitly states "only want text opinions / do not need a Word file / do not need a commented and revised version."
There is currently no accessible DOCX contract file, and the user has not yet supplemented the file.
Required information such as reviewer identity, client name, review stance, review purpose, or review criteria is missing, and cannot be confirmed from local memory or the user's reply.
The current runtime environment cannot write files, cannot run scripts, or cannot return attachments.

When an exception occurs, the blocking reason must be clearly explained, and the user must be told which conditions need to be completed before Word file generation can continue. If the file has been generated but the attachment cannot be returned for the time being, the artifact path or file object should be retained, and it should be clearly stated that "it has been generated but conversation return has not yet been completed."

A professional auxiliary skill for contract drafting and review, focusing on the following scenarios:

Review existing contracts, identify risks, and propose revision suggestions.
Draft new contracts and ensure the clauses are complete, enforceable, and practicable.
Form review opinion letters closer to lawyers' delivery practices, supporting communication, negotiation, and re-review.
Add comments or tracked changes directly in DOCX documents.

II. Core Concepts

Facilitate transactions

The review goal is to help transactions land safely, not to mechanically reject transactions.

Think comprehensively

Consider simultaneously our side, the counterparty, performance personnel, and third-party impacts.
Consider simultaneously legal consequences, commercial consequences, and execution costs.

Make rational decisions

Give suggestions according to risk level and business impact.
Give clear solutions for high risks, and optional solutions for medium and low risks.

III. Layered Four-Step Review Framework

3.1 Three-Layer Analysis

Macro layer (transaction structure)

Whether the contract type matches the substance of the transaction.
Whether the subject is qualified and the authorization is complete.
Whether the subject matter is lawful, disposable, and performable.
Whether the key procedures are complete (approval, registration, filing, internal decision-making).
Whether the transaction structure is executable (payment, security, delivery path, exit path).

Meso level (text and form)

Whether the contract form matches the business stage (formal contract / framework + order / supplementary agreement).
Whether the standard terms are compliant and whether the duty to highlight and explain can be evidenced.
Whether the main contract is consistent with the appendices, orders, and ancillary agreements.

Micro level (clauses and language)

Whether the core clauses are complete (subject matter, price, performance, breach, dispute resolution).
Whether the rights and obligations are clear, reciprocal, and enforceable.
Whether the mechanisms for breach, termination, compensation, evidence, and notice form a closed loop.
Whether the language is accurate, unambiguous, and free of conflicts.

3.2 Four-step process

Preliminary clarification

Clarify the position (which party is represented), review purpose, time limit, and priority.
If the user has not clarified the position and review scope, you must first confirm "Party A / Party B / neutral / other" and "restrained / standard / aggressive".
If the local config/review_memory.json has already matched a contract with the same name, by default use the customer name, position, and review scope recorded last time; change them only when the user points out an inconsistency.

Blocking items (if any one is missing, pause):Review position、Review purpose、Review scope. The three constitute the same blocking checklist; if any one is missing, substantive review must be paused and confirmation requested, and it must not proceed merely because the other two are present.

When the position is missing, you must explicitly request that the user confirm "which party is represented", and must not interpret the empty position as "neutral", "other", or any default value before continuing.
When the review purpose is missing, you must explicitly request that the user confirm the objective for this round ("pre-signing gatekeeping / negotiation revision / other"), and must not select a default purpose on your own, select the delivery intensity on your own, or issue formal review conclusions.
During the pause, only the following may be output: the list of identified gaps, the questions to be confirmed, and an explanation that the review can continue once they are supplied; risk grading conclusions or the three-tier signing conclusions must not be output.
Only when the user explicitly replies "you handle it according to the default scope" or gives equivalent authorization may the default values be used to continue, and the source of that authorization must be recorded in the report.

Layered scan

Macro first, then meso, then micro; framework first, then details.

Clause implementation

For each risk point, provide an executable revision plan, recommended wording, and suggested presentation method (direct revision / partial deletion / partial insertion / full clause rewrite / comment only).

Delivery and follow-up

Output the report, communication priorities, negotiation checklist, and review points.
If this round of tasks was initiated from Feishu or another IM session, and the contract file was transmitted through that session, by default deliver the final work product through the original session.
For DOCX contract review tasks, the final work products by default are the reviewed and revised DOCX and the Word review opinion DOCX; text-only output is not considered complete.

4. Standard output specification

4.1 Risk list fields

For each risk point, it is recommended to use the following fields for output:

Risk name
Risk level (P0/P1/P2)
Risk consequence
Judgment criteria
Recommended wording
Risk examples
Legal basis
Rectification suggestions
Relevant clauses

4.2 Risk levels

P0: May affect validity, cause major losses, or major disputes. Handle with priority before signing.
P1: Will significantly increase disputes and performance costs. It is recommended to prioritize negotiation and amendment.
P2: Wording or process optimization items. Can be handled according to the time window.

4.3 How to write the review conclusion

The conclusion should include:

Whether it can be signed: Can sign / Can sign with conditions / Not recommended to sign.
Preconditions: Preliminary actions that must be completed before signing.
Negotiation priority: P0 → P1 → P2.

Prerequisite for issuing a formal three-tier conclusion: This review is based on sufficient grounds, and key clauses can be substantively judged.

If there are gaps in key facts that make it impossible to substantively judge core clauses (typical examples: acceptance standards are decoupled from payment milestones and the acceptance criteria are missing, changes in scope and cost adjustments have no authorization basis, penalty and compensation clauses are stacked and the calculation base is missing, or attachments referenced in the main text are not provided), then:

must notOutput any one of "Can sign / Can sign with conditions / Not recommended to sign", and must not use equivalent expressions such as "recommended to sign / not to sign".
Instead, output "Conclusion pending—no signing judgment will be made until the information is completed", and list: what is missing, why the gap makes judgment impossible, and how to proceed after it is completed.
Identified risk points shall still be output by level as usual, but must be marked "to be confirmed", and no signing conclusion may be derived from them.
Only after the gaps are filled or the user explicitly states "just give a conclusion based on the existing materials" shall it switch to a formal three-tier conclusion, and the source of that standard shall be recorded.

4.4 How to write the drafting output

The drafting result shall include at least:

Drafting routing card (main contract type + supporting agreement type + main document + recommended delivery package type + mandatory attachments)
List of facts to be supplemented (missing parts shall be uniformly marked "not mentioned/to be supplemented")
Clause skeleton
Procedural prerequisites (approval, filing, registration, effectiveness, closing)
Recommended wording and matters to be confirmed

V. Contract type coverage (fixed 12 categories)

Do not expand the number of contract classifications; prioritize completing full extraction and in-depth supplementation within the existing 12 categories.

Category	Path	Example
Sales contract	`references/contract-types/01-sale/`	Sale of movable property, sale of second-hand housing, sale of commercial housing, distribution sales
Lease contract	`references/contract-types/02-lease/`	Real estate leasing, construction equipment leasing
Service contracts	`references/contract-types/03-service/`	General services, intermediary, warehousing and custody, work-for-hire, property management, transportation, commission agency, advertising
Intellectual property contracts	`references/contract-types/04-ip/`	Software license, technology development, trademark license, trademark assignment, patent, copyright
Security contracts	`references/contract-types/05-guarantee/`	Suretyship, mortgage, pledge
Loan and gift contracts	`references/contract-types/06-lending-gift/`	Private lending, gift
Internet agreements	`references/contract-types/07-internet/`	User license agreement, order agreement, privacy policy
Marriage and family contracts	`references/contract-types/08-marriage-family/`	Marital property agreements, divorce agreements, testamentary support agreements
Employment and labor contracts	`references/contract-types/09-employment/`	Labor contracts, labor dispatch, outsourcing, internships, re-employment, part-time, individual labor services
Real estate contracts	`references/contract-types/10-real-estate/`	Land grant, land transfer, joint construction, entrusted agency construction
Construction engineering contracts	`references/contract-types/11-construction/`	Construction, general contracting, subcontracting, survey and design, supervision
Corporate investment contracts	`references/contract-types/12-corporate-investment/`	Capital contribution, capital increase, investment, shareholder agreement, equity transfer, equity incentive, merger and division, valuation adjustment mechanism

Subdivided contract types not separately listed shall uniformly be classified according to references/contract-routing.md into the existing 12 categories, and shall be used simultaneously for review routing and drafting routing.

VI. Reference Call Order

6.1 Four-Layer Structure

Basic rules layer:references/review-framework.md
Review entry layer:references/priority-clauses.md
Presentation strategy layer:references/revision-strategy.md
Type routing layer:references/contract-routing.md
Contract main file layer:references/contract-types/01-sale/ to references/contract-types/12-corporate-investment/

6.2 Recommended Reading Order

Known contract title, but uncertain classification: First read references/review-framework.md, then read references/contract-routing.md, if necessary use references/priority-clauses.md to focus on high-risk clauses, enter the corresponding contract main file to complete detailed review, then use references/revision-strategy.md to determine the implementation actions.
Known contract directory, but uncertain whether there are cross-cutting issues: First read the current contract main file; if there is a mixed transaction, then return to the mapping list for dual-tag review.
Mixed-type transactions or titles inconsistent with substance: Always classify first according to the substance of the transaction rather than the title, using a dual tag of “main contract type + supporting agreement type”.
Drafting a new contract: First use the mapping list to generate a “drafting routing card” (main contract type, main file, recommended delivery package type, required attachments, issues to be confirmed), then use templates/合同起草信息清单.md to fix the file package, facts to be supplemented, and clause skeleton.

6.3 Maintenance Rules

references/ The root layer retains only high-reuse entry materials, and no longer splits out short navigation or process files.
When adding a new independent contract template, it may only be placed under references/contract-types/ in the existing 12 category directories.
For newly emerging common review issues, prioritize absorbing them into references/review-framework.md or the main file of the corresponding contract directory.

VII. Templates

Contract drafting information checklist:templates/合同起草信息清单.md
Clause library:templates/条款库.md
Review report template:templates/审查报告模板.md

templates/合同起草信息清单.md is positioned as a “drafting workbench”, used to first fix the routing card, file package, procedural prerequisites, and facts to be supplemented produced by the identification and triage documents;templates/条款库.md is positioned as a “drafting support layer” and does not separately constitute another reference. When drafting, first go through references/review-framework.md、references/contract-routing.md、templates/合同起草信息清单.md and the corresponding contract main file, then extract reusable wording from the clause library. The current clause library has added the first batch of high-frequency structural clauses such as document priority, acceptance, cooperation obligations, satisfaction of conditions, notice and service, limitation of liability, background technology, milestones, and closing checklist; subsequently, public clauses should continue to be extracted in reverse from the 12 categories of contract main files.

VIII. Document Operations (Comments/Revisions/Reports)

Before directly running scripts/*.py or scripts/run_apply_review_plan.ps1 , first confirm that the operating prerequisites in references/setup-dependencies.md have been met. The minimum requirement is: the local Python has installed the fixed version of scripts/requirements.txt according to defusedxml. OOXML packaging, unpacking, and validation functions are already embedded in scripts/docx/ , no additional Office parsing package is required.

8.1 Processing Flow

Integrated execution (recommended):

python scripts/review/apply_review_plan.py \
  --input contract.docx \
  --plan review-plan.json \
  --output contract_reviewed.docx

After execution, the default external deliverables are:

contract_reviewed.docx(integrated revision and comments version)
contract_reviewed_审查报告.docx

At the same time, it will be retained in the archive/<时间戳_合同名>/ internal archive directory:

review-plan.json
contract_reviewed_审查报告.md
contract_reviewed_执行日志.json
Output DOCX, copy report DOCX, and manifest.json

Low-level API (orchestrated as needed):

from scripts import ContractReviewer

reviewer = ContractReviewer("workspace/unpacked")
reviewer.add_comment_by_text("甲方承担全部责任", "P0：责任范围过宽，建议增加责任上限和例外")
reviewer.replace_text("五个工作日内付款", "十个工作日内付款", tag="w:r")
reviewer.save()

For plan format and parameters, see:scripts/README.md
In the generation phase, you can first run plan completion:

python scripts/review/enrich_review_plan.py \
  --input review-plan.json \
  --output review-plan_enriched.json

Used to automatically complete needs_negotiation / deterministic_edit, then execute comments/revisions.

Execution semantics:

If config/reviewer_profile.json does not exist, or the reviewer name / law firm or company name is not filled in, first confirm with the user the reviewer name, law firm/company name, and optional department; then the script will use config/reviewer_profile.example.json as a template to generate a formal configuration and write it back.
Even if config/reviewer_profile.json already contains a name / law firm or company name, as long as the configuration has not been confirmed in the current environment, you must still confirm with the user once before continuing; do not directly use unconfirmed pre-filled values.
If the user has not clearly specified the client name, review stance, or review scope, first read config/review_memory.json; when a historical record for a contract with the same name is found, use it by default; when no match is found, in interactive mode ask for "client name + stance + review scope", and use config/review_memory.example.json as a template to generate a formal memory file.
The review scope is only used to control the strength of risk identification and conclusion expression, and is no longer directly mapped to the body-text marking strategy; the automatic routing of "body revision / inline comments / opinion letter only" should be determined by an independent edit_policy .
If there are review items that were not successfully written into Word, the command will still retain the output DOCX, Word report, and archive records, but will exit with a non-zero exit code.
The external report by default adopts the "Review Opinion Letter" format: first write the opening "To: recipient", contract overview, comprehensive review opinions, and important risk alerts, then expand item by item according to formal opinions, and finally append the statement and issuance information; execution hit rate, failed items, and internal statistics are by default kept only in the JSON execution log in the archive.
The Word review opinion letter by default adopts a formal legal document layout: dark blue headings, FangSong body text, light-background metadata cards, brown label highlighting, and footer page numbers, in a style closer to a lawyer service proposal/opinion letter deliverable.
The Word review opinion letter layout by default uses more compact formal document parameters: margins, line spacing, paragraph spacing, and padding within the detailed opinion table have all been compressed to avoid unnecessary whitespace stretching the total page count.
Unordered lists and numbered lists in the Word review opinion letter use the native OOXML numbering system to avoid drift in level and indentation display.
"Detailed Review Opinions" are by default displayed in the Word report as an item-by-item table, making it easier to compare the risk overview, original clauses, suggested revisions, and legal basis.
The "Detailed Review Opinions" table by default uses a more compact layout: the label column is narrowed, the content column is widened, and the top and bottom cell padding is set to zero, prioritizing reduction of line wraps in long clauses.
In the default delivery mode, only the reviewed and revised DOCX and the Word report are kept in the user directory; the Markdown report, execution log, and review plan copy are by default deposited in archive/. If you need to directly view these process files, you can temporarily use --no-archive for debugging.
The review version DOCX delivered externally uses the "revision-comment integrated version" by default: definitive issues are directly revised, blank items/items pending factual supplementation continue to be commented, and major direct revisions retain necessary explanatory comments; procedural optimization-type, explanatory-type, and low-necessity issues are by default only written into the review opinion letter.
If the current round of tasks comes from Feishu or another IM conversation, and the contract file is directly transmitted from that conversation, the default delivery channel is the same IM session; in the end, the reviewed and revised DOCX and the review report DOCX should be directly sent back to the original conversation, not merely replying "the file has been generated" or only giving a local path.
If the current runtime temporarily does not have IM attachment sending capability, this limitation should be clearly stated, and the sendable artifact path or file object should be retained, waiting for later re-sending through a channel with sending capability; do not incorrectly describe "not sent" as "delivered".
On first execution, it will preferentially read config/reviewer_profile.json; if there is no configuration yet, the name/organization is missing, or the current environment has not yet confirmed that identity configuration, then in interactive mode ask for the reviewer name, law firm/company, and optional department, or when --author and --organization are explicitly passed in for the first time, generate and save according to the current input.
This configuration is only saved in the config/ directory of the current local skill and will not be automatically uploaded; it can be updated at any time later through natural language requests.
initials is optional; if left blank, it will not be automatically generated, nor written into Word comments.
The comment and revision timeline written into Word will first read the current time zone and local time of the machine, then stagger backward in 5 to 10 minute intervals starting from the point when this command is executed;w:date is written using the local time zone format, and the extended UTC field uses the UTC format of the same point in time, avoiding displaying the wrong time zone or writing back a timestamp earlier than runtime.
The timeline uses a "two-layer staggered" approach by default: within the same review opinion, each actual revision/comment batch is by default sequentially delayed by 1-2 minutes; between different review opinions, the larger interval of 5-10 minutes continues to be maintained.
The Word comment author is displayed by default as 姓名｜机构; the reviewer, affiliated institution/company, and affiliated department in the review report are still displayed as separate items.
The reviewer, affiliated institution/company, and affiliated department in the review report remain consistent with the above local configuration.
If the review plan does not explicitly provide comment, by default generate comments in the multi-line structure of "risk level / risk point / clause location / explanation / revision suggestion / optional suggested wording".
The default automatic triage strategy is the more restrained revise-first: only review items with high certainty and strong implementability are preferentially directly revised; procedural optimization-type, explanatory-type, and low-necessity issues may be changed to comments or only written into the opinion letter.
Before determining comment / delete / insert / replace , priority should be given to referring to references/revision-strategy.md: blank items, items pending factual supplementation, and business trade-off items with unclear authorization are by default only commented; accurate legal provision citations are by default not deleted merely because they are long; where local deletion or insertion is possible, do not rewrite the entire paragraph.
The revision execution layer has been upgraded to "multi-paragraph minimal-difference revision + review density convergence": within the same w:r phrase replacement/deletion is preferentially implemented as local w:del / w:ins; the target spans multiple w:r When doing so, prefer falling back to intra-paragraph fragment revisions; for complex long clauses, when multiple stable and unchanging fragments exist, they should also be split into multiple groups of local revision blocks as much as possible, rather than continuing to compress them into one large mid-section replacement; if a single clause would explode into a large number of low-value single-character-level differences, automatically merge them into fewer core revision blocks. For blank/placeholder items, even if the upstream mistakenly marks them as direct revisions, they should fall back to comments.

8.2 Mode Selection

External delivery mode: by default, only the “integrated revision-comment version” is used, and users are no longer required to switch among pure comment / pure revision / mixed modes themselves.
Comment action: used for risk alerts, business negotiation suggestions, facts pending confirmation, scenarios requiring retained flexibility, and adding a layer of explanation to major direct revisions.
Revision action: the default preferred mode, used for obvious errors, terminology unification, deterministic replacements, and risk rectification where it is truly necessary to directly change the text.
Opinion letter only: used for procedural optimization-type, explanatory-type, low-necessity issues, or issues where “a prompt is sufficient and no trace needs to be left on the Word page.”

8.3 Automatic routing (`action=auto`）

By default, the revise-first strategy is used; it can be overridden via --edit-policy revise-first|balanced|comment-first or the planned meta.edit_policy .
edit_policy is independent of the review posture: even if the current posture selects 克制, deterministic issues can still be directly revised; do not mechanically equate a “low posture” with “comments only, no text changes.”
When a review item contains features such as “negotiation/pending confirmation/retained flexibility,” automatically handle it as a comment.
When a review item contains deterministic change features (such as typo correction or terminology unification) and provides a text-change payload, automatically handle it as a revision.
When a review item is a procedural optimization-type, explanatory-type, or low-necessity suggestion, it can automatically go through the “opinion letter only” channel and not be written into the Word body.
Under revise-first , if replacement_textis not explicitly provided, but recommended_textthat can be directly placed into the text has been provided, the system will first determine whether the issue is worth putting directly into the body; only after passing the convergence rules will it execute it as replacement text for a direct revision.
Explicit actions (comment/delete/insert/replace) take precedence over automatic routing.
If needs_negotiation / deterministic_editis not explicitly provided, the script will automatically complete it when loading the plan (this can be disabled via --no-enrich-plan ).

9. Standard Review Process

9.1 Initiation Stage

Required questions: Which side do we represent; whether this round's goal is “pre-signing gatekeeping” or “negotiation revision”; deadline and priority; whether restructuring the transaction structure is allowed, or only text changes.
Blocking validation (aligned with §3.2): If any of the three items—review stance, review purpose, or review posture—is missing, suspend substantive review and request confirmation before continuing; do not proceed by taking default values just because “the item is not on some list.” Missing deadline and priority do not constitute a block; continue after marking them as “not mentioned/to be supplemented.”
First-use validation: If config/reviewer_profile.json lacks the reviewer's name or affiliated institution/company, or the current environment has not yet confirmed this identity configuration, first remind the user to add or confirm the reviewer's name, law firm/company name, and optional department, and explain that this configuration is stored only locally and can be modified at any time later through natural language.
Input materials checklist: Contract body and attachments; background materials; entity materials.
Output conventions: Integrated revision-comment version document / review opinion letter; risk grading is unified as P0/P1/P2.
Channel convention: If the contract file is delivered via Feishu or another IM conversation, by default treat that conversation as the same channel for task assignment and deliverable return; unless the user explicitly switches to email, cloud drive, or another location, the files should ultimately still be sent back in the original conversation.

9.2 Tiered Review Stage

Macro level: contract type, subject qualification, legality of the subject matter, approval/filing/registration/internal resolution, and the closed loop of payment, delivery, guarantee, and exit.
Meso level: whether the contract form matches the stage, whether the main contract conflicts with annexes/orders/rules documents, and whether standard terms and priority are clear.
Micro level: completeness of core clauses, balance of rights and obligations, enforceability of breach and termination, and evidentiary support for dispute resolution and notices/service.

9.3 Risk Handling Stage

Risk ranking: P0 must be handled; P1 priority negotiation; P2 optimization items.
For each risk point, output at least: risk consequences, identification criteria, recommended wording, and remediation suggestions.
Default execution approach: If clear clause text can already be formed, prioritize directly revising the body text; only switch to comment prompts when business negotiation, factual gaps, or the need to preserve flexibility are involved.
Revision granularity approach: Prioritize local deletions, local insertions, and local replacements; rewrite an entire clause only when the overall logic of the original clause has failed and local actions cannot repair it.
Explanation approach for major revisions: For major direct revisions to P0 / P1, in principle retain a brief comment explaining the reason for the modification; for pure formatting, numbering, punctuation, and typo issues, usually only revise the text and do not disturb the reading further.
Priority negotiation order: Effectiveness and procedure -> funding and delivery -> remedies and exit -> text optimization.

9.4 Delivery Stage

Final deliverables: risk summary table, key clause modification suggestions, pre-signing prerequisites checklist, and second review issue list.
File deliverables: review and revision DOCX, review report DOCX.
Completion criteria: When an accessible DOCX contract file exists in the current round, the above two Word files must be generated and delivered; outputting only chat text, a Markdown summary, or a risk list does not constitute completion.
Report completeness review: The report generation script itself "running successfully" does not mean the report is qualified.scripts/report/integrity.py will independently review the number of placeholders, each legal basis in the structured plan, and item-by-item basis coverage after rendering;apply_review_plan.py will execute this gate before writing any formal DOCX. If it does not pass, it exits non-zero and does not leave formal deliverables; if a draft needs to be retained, only the upper-level caller may retain process files itself after authorization.
IM return approach: If the task comes from Feishu or another IM channel, by default return the above two files in the original conversation; if the runtime does not have the ability to send attachments, it must clearly state that "the files have been generated but the conversation return has not yet been completed."
Conclusion template: Can sign / conditionally can sign / not recommended to sign + prerequisites + main reservations. When there are key factual gaps and core clauses cannot be substantively judged, switch according to §4.3 to "conclusion pending - no signing judgment before information is completed" + gap list + completion path, and do not force the three-tier conclusion.

9.5 Review and Common Mistakes

After the counterparty provides feedback, check whether new conflicts have been introduced.
During version iteration, focus on checking the knock-on effects of revised clauses.
Perform one more quick check on the final signing version.
Common mistakes: Only changing the wording without fixing the transaction structure; only looking at the main text without looking at the attachments and orders; only looking at our obligations without looking at the counterparty's remedies; only giving risk warnings without providing executable alternatives.

10. Standard Drafting Process

10.1 Drafting Initiation Stage

Information that must be asked: Which party we represent; the transaction objective; whether this output is a complete contract, framework agreement, supplemental agreement, or term sheet; whether there is a mixed transaction; the deadline.
Do routing first: First read references/contract-routing.md, determine the main contract type, the supporting agreement types, the recommended delivery package type, and the required attachments, and first produce a "drafting routing card."
Build the checklist first: Use templates/合同起草信息清单.md to record the document package, entities, transaction structure, procedural prerequisites, and missing facts.

10.2 Skeleton Building Stage

First check according to references/review-framework.md whether the macro / meso / micro three levels are complete.
First build the document package according to the "priority main document + skeleton order + required attachments" given by the mapping checklist; do not jump directly to the wording of the main text.
Then enter the corresponding contract main document and extract the exclusive clauses, risk points, and recommended wording for that type of contract.
Mixed transactions must always be split into "main contract clauses + supporting agreement clauses" to avoid forcing different legal relationships into one text.

10.3 Clause Filling Stage

Fill in the key commercial facts first, then write the wording; mark missing places uniformly as "not mentioned / to be supplemented."
Procedural matters must clearly state the responsible party, completion time, and consequences of non-completion.
templates/条款库.md It is only used to supplement general candidate wording and does not replace the main document in determining the clause structure.

10.4 Delivery Stage

At minimum output: the drafting routing card, contract draft / clause skeleton, list of issues to be confirmed, and list of procedural prerequisites.
If a complete text cannot be drafted in one go: first output the routing card, clause list, and facts to be supplemented; do not fabricate commercial arrangements to "fill out" the draft.

11. Compliance Requirements

Do not cite the specific sources of external materials in skill documents or reference files.
Do not use proprietary naming from external materials as the main framework name of the skill.
Retain only review concepts, structures, and practical rules that can be publicly expressed.
Information that cannot be confirmed must be clearly marked as "not mentioned / to be supplemented."

12. Permissions and Data Boundaries

The script only reads the contract explicitly provided by the user, the review plan, and this Skill's local configuration; by default, it writes revised documents, reports, and logs to the user-specified output directory and this Skill's archive/ .
On first run, it may write confirmed reviewer information and review memory to config/ ; these local configurations, contract contents, or outputs must not be automatically sent to the network, IM, email, or third-party services.
--no-archive It is only used for local debugging; any external sending, uploading, or returning attachments from the original session must be completed separately by upper-layer tools with the corresponding capabilities and with user authorization.

13. Version

Current version:1.6.3
Update date:2026-08-13