--- name: signeasy-signature-request-preparation description: Prepare a new Signeasy signature request safely, choosing the right template or document source, filling roles and fields, generating a preview for the user to review, and only creating and sending after explicit approval. Use when the user asks to send a document for signature, start a signing request, set up a contract to be signed, or prepare a template for signers. --- # Prepare a signature request Starting a request is the one step that emails real people. The job is to get the document, the signers and the fields right **before** anything is sent, and to make the user look at the exact result first. A request sent to the wrong person, with the wrong template or an empty required field, cannot be recalled by a tool call; at best it can be cancelled, and the signer will already have the email. ## 1. Confirm the account and what is being sent Call `signeasy_get_account_info` once to confirm which account is active and that it has the plan and credits to send. If the user has several workspaces, call `signeasy_list_workspaces` and ask which one the request belongs to. Switching the active account or workspace is a change of context: wait for the user's explicit yes before you switch. Establish the three facts you cannot guess: - **What document**: a template the user already maintains, or a file or existing original. - **Who signs**, and in what order: names, email addresses, and which role each person takes. - **What the fields must say**: the values that belong in the document, such as dates, amounts and names. If any of these is missing, ask. Do not invent a signer address or a value for a field that looks required. ## 2. Pick the right source Use the source the user is actually working from, not the nearest match: - **Templates**: call `signeasy_list_templates`, then `signeasy_get_template_details` for the chosen one. This returns the roles and fields, so you know exactly what must be filled. A template with three roles needs three signers mapped; a request missing one role will not be complete. - **Existing documents**: call `signeasy_list_document_sources` if the user is unsure where a file lives, then `signeasy_list_documents` to find it. Check for near-duplicates by name (two versions of the same contract, one marked final). Ask which one is the current version. If two templates have the same name, do not pick one. Show both with their roles and ask which one the user means. ## 3. Map roles and fields, then check them Build a table from the template details before any preview: | Role | Signer name | Email | Signing order | Fields to fill | Check each row: - Every role has a real person behind it, and the email is spelled correctly. Read the addresses back to the user. - The signing order matches what the user said. If they said "countersigned by the CEO after the counterparty", the CEO's role comes after. - Required fields have values. Optional fields left blank are fine, but say so. - A value that looks wrong (a date in the past for a new agreement, an amount that differs from the one the user gave you) gets flagged, not silently corrected. Do not fill a value the user did not give you. If a field has no source, ask. ## 4. Generate a preview and stop for review Call `signeasy_create_signature_request_preview`. It produces a link that lets the user review the request before it is sent. Nobody is emailed by this step. Give the user the preview link and a short summary of signers, order, and field values, then wait. Tell the user plainly that the preview has been generated and nothing has been sent. Ask them to open it and check the signers and values, then reply. ## 5. Create and send only on explicit approval After the user has reviewed the preview and says yes, call `signeasy_create_signature_request`. This sends emails to real signers. Do not call it on a general "sounds good" to an earlier message; wait for an explicit yes given after the preview. If the user changes anything (a signer, a field, the order), regenerate the preview and ask again. Never send from a changed version the user has not seen. After sending, report the request's pending identifier and its status, so the user can follow it up later with the follow-up skill. ## Common patterns and traps - **The wrong signer order.** Templates often default to a sequence the user did not intend. Compare the template's role order against the user's description before the preview, not after. - **A stale template.** A template may still carry an old price, date or clause. Read the fields, and ask if the user has a newer version. - **A typo in an email.** A misspelled address sends the document to a stranger. Read each address back, character by character if needed. - **Sending to a role that is not a signer.** Some roles only approve or observe. Confirm which roles actually need to sign. - **Preview treated as sent.** The preview changes nothing. Do not tell the user the contract is out for signature until the create call has succeeded. - **Duplicate requests.** If a similar request already exists, check the pending list first so the same document does not go out twice. ## Output ``` Account / workspace: , confirmed Source: