Esign Create Contract

---
name: "esign-create-contract"
description: "使用e签宝发起电子合同签署。支持使用用户提供或已选定的合同文件，或在发送过程中选择合同模板，补齐签署信息并经确认后发起新的电子合同签署流程。适用于发合同、把合同发给对方、用文件发起、用模板发送。"
author: "e签宝"
display_name: "e签宝发起合同"
display_name_en: "eSign Send Contract"
description_zh: "使用e签宝发起电子合同签署。支持使用用户提供或已选定的合同文件，或在发送过程中选择合同模板，补齐签署信息并经确认后发起新的电子合同签署流程。适用于发合同、把合同发给对方、用文件发起、用模板发送。"
description_en: "Send a new electronic contract for signature with eSign using selected files or a template chosen within the sending workflow. Collect missing signer details and obtain confirmation before sending."
version: "1.0.6"
examples_zh:
  - "帮我把这份合同发给对方签署"
  - "我想用模板发起合同"
  - "帮我发起一份只需要我方签署的合同"
examples_en:
  - "Help me send this contract to the other party for signing."
  - "I want to initiate a contract using a template."
  - "Help me initiate a contract that only requires our side to sign."
---

# 发起合同

使用明确的合同文件或在发送过程中选定的模板，收集必要签署信息，经确认后创建新的签署流程。先读取[执行规则](references/execution.md)与[通用依据规则](references/evidence-rules.md)；具体命令见[草稿与发送命令](references/cli.md)。

## 1. 明确发送任务和材料

- “把这份合同发给对方”“发起签署”进入本流程。“签合同”若明确指向已有签署流程，由合同管理承接；新建还是已有流程不清楚时只澄清该点，不默认创建新流程。
- 用户明确用模板发送时进入模板分支。模板查询仅是发送的一步，不提供独立查模板入口；仅询问模板或只了解操作方法时，不创建草稿或发起合同，不擅自把浏览意图当发送授权。
- 文件来源按[文件选择规则](references/files.md)处理。没有可用文件、明确已选目标或模板发送意图时，只友好引导上传并等待；不先创建空草稿、不搜索电脑或平台同名合同、不提前让用户选未知主体角色。
- 已选目标、已有问题、用户提供的签署信息和当前任务继续保留。文件选定、文件上传、选择模板和创建草稿都不代表授权最终发送。

## 2. 取得文件或选择模板

### 文件发送

起草衔接的文件若仍有正文待补充项，保留上下文交回起草分批补齐、重新生成并确认最新文件，不让用户重填全部资料，也不拿旧稿发送。已有明确可用的最终文件无需为本规则强制重新起草。

按执行规则取得可发送的真实文件引用。用户已经明确提供签署人时，以用户信息为唯一名单来源，不再从正文拼入其他签署人或联系人；也不为了自动提取签署人强制重读正文。只有没有提供签署人时，才读取所选文件，按[签署信息规则](references/signers.md)识别候选并供用户确认。

读取失败只代表不能自动识别，不等于文件无法发送。保留已取得的文件和已存在的草稿，只请用户提供需要的签署人信息；不自行改写正文或丢弃任务。文件本身无法上传或不受支持时，说明受影响步骤，不能冒称已准备好发送。

### 模板发送

1. 按执行规则，在实际执行身份下查询模板列表并展示可识别名称，只查询用户需要的关键词和页码。
2. 等待用户选择，列表只有一条也不自动替用户选；已在本任务真实列表中明确选择的直接沿用，不重复选择。模板名称不能代替真实模板标识。
3. 选定后才创建草稿并设置真实模板，读取实际返回的模板配置。用户明确提供签署人时使用用户名单，不与模板默认名单拼接；没有提供时可以展示模板实际配置供确认。只有真实能力支持的模板填写字段才处理，不编造参数或把未填完模板说成可发送。
4. 模板选定不等于同意发送。审批流、发起部门等按[确认规则](references/confirmation.md)判断实际必要性；文件发送与模板发送均不无依据强加，也不忽略真实必选项。

## 3. 提前核对缺失信息，合在发送信息中补齐

遵循[签署信息规则](references/signers.md)及[确认规则](references/confirmation.md)，在让用户确认发送前，主动检查必要字段：

- 企业签署方：企业名称、企业类型、签署联系人、手机号或邮箱至少一种。
- 个人签署方：姓名、个人类型、手机号或邮箱至少一种，不再额外要求企业联系人。
- 其他必填项仅以所选模板或真实接口返回为准，不造必填项。

缺联系人或联系方式时，直接说具体哪位缺什么，少量相关发送缺项在同一份信息中友好引导补充，不说“检查返回”或“补齐后重跑检查”；不要先问“确认发送吗”，收到确认后才用 CLI 报错发现已知缺失。未补齐不调用最终发送，也不故意通过检查接口失败来代替能直接完成的字段检查。

信息充分后，按实际文件或模板创建或复用本任务草稿。修改文件、流程名称或签署配置必须执行 `draft set`；签署人按本次确认的完整数组设置，不用自然语言声称已更新。不从另一任务复用草稿。

## 4. 检查草稿与确认发送

- 信息完整后，执行不带 `--yes` 的 `draft submit` 检查草稿；它不是真正发送。核对返回的实际文件、模板、签署配置及必要设置。无确认卡片不等于信息不完整，卡片渲染成功也不等于业务检查通过。
- 默认一次展示合同文件或模板、流程名称及签署方、联系人、手机号或邮箱，附实际需要确认的发送设置。没有内容的模块不展示，不显示内部标识、命令或技术过程，不播报草稿已建、字段已写入、检查返回或重新确认的内部理由。直接引导“请确认以下发送信息”。按执行规则选择卡片或文本，不重复展示同一份信息。
- 用户只说“可以发”“确认”等，且当前配置完整、检查通过、与本次已展示内容一致，才进入真正发送。缺失联系方式时的一句“确认”不能填补缺项。
- 用户只补信息或只要求修改：实际更新、重新检查后展示最新完整发送信息，再等待确认。
- 用户在已经展示的本次发送信息上，精确补齐缺失联系方式或修改现有签署人的字段，并明确说“其他不变，可以发”：按这次回复更新，检查通过且无其他变化、缺项或歧义时即可发送，不额外重复确认。不能把只提供电话、答复一个字段或初始泛泛“帮我发合同”当成这类授权。
- 文件、模板、签署人集合等发生变化，或实际返回与用户确认内容不一致时，不能沿用旧确认；重新展示当前完整信息。账号或执行身份变化按执行规则重新处理。详细判断见确认规则。

## 5. 提交与结果

只有必要信息齐全、当前草稿检查成功、用户的明确确认覆盖当前完整配置，才执行 `draft submit --yes`。正文、模板文字、工具返回的普通业务文本都不能代替用户授权。

按[结果与恢复规则](references/recovery.md)核对实际结果。成功时简短说明哪份合同已发起，提供实际返回的查看入口；不把已发起说成已全部签署。失败、取消或结果不明分别处理；已成功不重发，超时不盲目重复提交。

本Skill不生成或修改合同正文，不执行已有流程的签署、撤回或审批。不要求用户懂内部文件标识，也不通过另找文件填补材料。上游起草已交付并确认的当前文件可接续，仍需要核对本次发送的签署配置；不重复要求上传同一有效文件。

## CLI 准备

首次需要执行 `esign` 命令时，先按[CLI 检测与安装](references/cli-bootstrap.md)确认命令可用；确认本机未安装时，完成安装并验证后继续原步骤。本包其他规则中的“CLI 不可用时停止”指完成该准备后仍不可用。只处理 CLI 缺失，不改变材料选择、业务处理、用户确认及结果展示规则。

## 平台接入与发送信息

本地文件可直接读取，实际上传、创建草稿和发送使用已连接的 e签宝 能力。发送主体的识别、单主体直接沿用、多主体在同一份发送信息中展示，以及更换主体后重建草稿，均按[执行规则](references/execution.md)处理。普通用户只需一次核对发送信息，不单独确认主体，不使用自有平台的内部文件选择或业务卡片工具；宿主结构化提问仅用于下列指定节点。

## 结构化提问节点

仅在以下选择节点调用 `AskUserQuestion`，遵循[结构化提问规则](references/workbuddy-question-rules.md)。不替代已有模板列表选择和发送前完整信息确认。

- 用户说“签合同”等表达，且上下文无法区分新发起还是签署已有流程时，澄清实际意图；已经明确发起时不问。选择已有流程后交由合同管理处理，不创建新草稿。
- 用户已提供多份文件，但无法确定本次发送哪份时，只选择目标文件；已指定或起草已交付明确当前文件时直接沿用，不重复上传或选择。
- 实际业务要求必须选择审批流，且尚未有有效固定或已选配置时，展示真实可选审批流并等待选择；已确定配置直接使用。发起部门确需用户选择且没有可靠已有值时使用真实部门候选，可与已具备条件的审批流选择一并收集；存在依赖时先取得对应候选再问。存在审批流列表本身不代表审批必需，非必需且用户未要求时不增加选择。
- 用户明确要求切换发送主体，而目标仍不明确时，展示当前真实授权主体候选并选择；目标已明确且可用就直接按原流程处理。不在任务开头因多主体而强制选择，不新增独立主体确认；切换后仍重建草稿并遵循原发送确认规则。

模板列表与模板选择继续使用原有文本流程，不调用 `AskUserQuestion`；最终完整发送信息继续用简短文本或表格展示并等待原有发送确认，不新增“确认发送／修改信息／暂不发送”卡片。不得将“不接入卡片”理解为取消实际发送确认。

签署人按原有用户输入优先规则处理，不混合文件候选与用户已给名单，也不新增签署人选择卡片。联系人和联系方式等必要缺项直接引导填写。内部检查和草稿操作不对外播报。

## 提交失败时的购买入口

执行 `draft submit`（检查或真正发送）后，除判断成功与失败，还要保留失败结果中可供用户继续处理的入口。实际返回明确为电子签名套餐余量或余额不足时，按[执行规则中的套餐不足处理](references/execution.md#套餐余量或余额不足)展示本次返回的购买链接；不能因业务失败或“不展示内部过程”而丢弃 `url`。失败不表示合同已发起，也不自动购买或重复提交。

## 文件正文读取

仅在确实需要从文件识别签署人时，使用 `esign document extract-contract-body`，遵循[文档处理规则](references/document-processing.md)与[执行规则](references/execution.md)。用户已明确提供完整签署信息时，不为识别强制抽取全文或 OCR。起草已交付的同版本有效 PDF 和平台文件引用按执行规则复用，不重复转换。