Signature Sleigh (send for signature)

Route a finalized Google Drive PDF out for e-signature through DocuSign, using the browser the way a person would — log in, upload the PDF, add recipients, set the signing order, place each signer's fields so they just click, add any completion-copy recipients specified in the user's companion doc, send. No DocuSign API key, JWT, or admin integration — gog handles the Drive side, browser-harness drives DocuSign's web app, henry-out handles the optional Slack heads-up.

Operate conservatively. This workflow handles real signature envelopes. Don't guess your way through an irreversible send — when a screen doesn't match, look at it, adapt, and ask. Always stop at preview and require explicit approval before sending.

Naming and invocation

Signature Sleigh is the human-facing and searchable workflow name. Keep the skill discoverable under that term in the title, description, and tags. The installed skill ID may remain send-for-signature for compatibility; do not rename the ID/folder unless deliberately migrating references. Treat all of these as valid invocation phrases: “Signature Sleigh,” “send this for signature,” “DocuSign this,” “get this signed,” and “route this PDF for signature.”

When the user asks for the generic/shareable Signature Sleigh link for other users, use references/shareable-signature-sleigh-docs.md: provide the generic End-to-End Workflow doc link, distinguish it from personal companion docs and the pre-rollout test plan, and check Drive permissions before calling the link share-ready or changing access.

When the user asks for a GitHub/repository README or public explanation of the general Signature Sleigh skill, start from templates/github-readme.md. Keep it generic: explain the browser-operated DocuSign workflow, the no-DocuSign-API design, the mandatory preview/explicit-approval checkpoint, and the companion-doc split. Do not include any user's companion doc ID, DocuSign account, 2FA routing, envelope tracker ID, Slack destinations, or real signer data.

How this skill works: generic base + the user's companion doc

Everyone gets this skill — it's the generic how-to for routing a PDF through DocuSign in the browser. Each user's specifics live in their own companion doc — which DocuSign account/login to use, where their 2FA codes go, any field-placement quirks for their templates, default channels or signers. The skill is the mechanics; the companion doc is that user's preferences. Keep them separate.

At the start of a run, get the user's companion doc — find an existing one, or guide the user through creating one.

1. Find an existing companion. Check your memory for a recorded companion doc-id first (fastest — when it's set up, the doc-id is pinned in your memory). Otherwise the user may point you to it, or run a name-scoped Drive search:

gog drive search "name contains 'Send for Signature'" --raw-query

Use the name-scoped query, NOT a plain full-text gog drive search "Send for Signature" — a full-text search drowns in legal/financing docs that all contain the word "signature" and will not surface the companion. Read the companion with gog docs cat <doc-id> and follow it for the user-specific choices (account, 2FA mailbox, signing defaults, template notes). If you find it, record its doc-id to memory (step 4) and skip to the workflow.

2. No companion yet → run a guided setup (don't hand them a blank doc). Ask the setup questions once, in one structured message (same style as Step 2 of the workflow — don't drip questions). Tell them you'll save their answers as a reusable preferences doc so they never repeat this:

Looks like this is your first signature run — let me set up your preferences once so future sends are one step. A few quick things:

• DocuSign account/login to use — the email/account the browser should sign in as (the work account, not a personal login):
• 2FA mailbox I can read — when DocuSign emails a verification code, which of your own inboxes should it go to? It must be a mailbox I can read via gog, not a shared one (DocuSign often defaults to a shared mailbox I can't open):
• Default signing order (default = counter-signers first, internal last) — keep the default, or prefer internal first / simultaneous?
• Usual internal signer(s) — who on the internal-company side normally signs? (name + email):
• Completion-copy recipients — anyone who should receive the completed/executed envelope by default, and whether they should receive only the completed copy (not the initial signing request):
• Slack heads-up channel/person — default person or channel for the optional signing notice (or "none"):
• Signature-block quirks — anything unusual about where each party's Signature / Date / Name sit in your standard documents? ("none" is fine):

3. Create the companion doc PRE-FILLED with their answers (not the blank template). Fill the template (bottom of this skill) with what they told you, write it to a local file, and convert it into a Google Doc:

gog drive upload /opt/data/send-for-signature-companion.md --convert-to doc --name "Send for Signature — <user>'s preferences"

(Or create the doc from the template and gog docs find-replace <doc-id> each ____ blank with their answer.) Then share it to the user as writer so they can tweak it later:

gog drive share <doc-id> --to user --email <their-email> --role writer

Confirm back: "Saved your preferences here: . I'll use these going forward — edit that doc anytime. Now, on to your signature." Leave any answer they skipped as a blank for them to fill in later.

4. Record the doc-id to memory so the next run finds it instantly with no search: save send-for-signature companion doc-id = <doc-id> to your durable memory. Then proceed straight into the actual send — don't make them wait on the setup.

Where to record what you learn — keep this straight:

• A generic DocuSign mechanic (a UI step, a field-placement trick, a screen that changed for everyone) → update this skill.
• A user-specific preference (their account, their 2FA mailbox, their document's signature-block layout, completion-copy/CC recipients such as Records, Slack destinations, default signer lists) → update their companion doc (gog docs find-replace / edit it in place). Never bake one user's specifics into this skill.

The pieces — native tools, no API

When to use

The user shares a Google Drive PDF URL and wants it routed for signature ("send this for signature: url — internal signer Chris, counterparty Jane"; "DocuSign this and have our side sign first"; or just a Drive URL + a counterparty name — collect the rest).

Do not use for

• Contract review / redlines / legal advice — a different job.
• Searching Drive by document name — the user provides a direct URL.
• Non-PDF source files — ask the user to export to PDF first.
• Sending without a preview + explicit approval.

Watched test runs and pre-rollout QA

If the user wants to validate Signature Sleigh before broader rollout, use references/pre-rollout-bug-bash-test-plan.md: run the three-test matrix (internal-only preview+cleanup; counter-signer-first/internal-last with exact title fields; Slack heads-up + tracker logging) and patch any generic issues before sharing widely.

If the user wants to test this skill while watching in the Live Browser, keep the instructions and approvals in chat and use the Live Browser only as the shared visual surface where they watch DocuSign being operated. Do not tell the user to type a prompt into the Live Browser.

Offer this copy-paste prompt for a watched test:

Henry, run a watched test of the send-for-signature skill using my companion doc.

Drive PDF: <paste Google Drive PDF link>
Internal signer: <name>, <email>
Counter-signer: <name>, <email>  [or: internal-only test]
Signing order: use my companion/default unless stated otherwise
Slack heads-up: no for this test  [or specify channel/person]
Test mode: build the DocuSign envelope and stop at preview for my approval. Do not send until I explicitly approve.

Then drive DocuSign through browser-harness so the user can watch. Narrate only useful checkpoints in chat (PDF verified, DocuSign login/auth needed, preview ready, send verified), and still require the normal explicit approval before sending.

If the user says the run was test-only or explicitly says do not proceed after preview, treat that as a final stop: do not send the envelope, do not post any Slack heads-up, and do not log anything to the envelope tracker. Abandon/close the unsent DocuSign builder or navigate away so there is no active send screen left open, then verify the browser is no longer on the envelope send screen before confirming. If they ask to delete/discard the test draft or log out, use references/docusign-test-cleanup-2026-06.md: close Preview, Actions → Discard, confirm Discard Draft, verify the Agreements page, then profile → Log Out and verify the logged-out page before reporting completion.

Logging into DocuSign (browser-harness + autofill)

Open https://account.docusign.com (or https://apps.docusign.com/send/home) with browser-harness. If you're already signed in, go straight to the workflow.

At the login screen, sign in with the browser's saved credentials — never type, invent, or ask for a password:

1. Email input with real typing. Type the account email from the user's companion doc with real browser input (coordinate-click the field, then type).
2. Password autofill & 1Password Unlocking. On the password page, click directly in the password field to reveal the autofill dropdown.
   • If the autofill/saved-password dropdown does NOT appear: It means 1Password is locked. Go to the 1Password browser bookmark (https://my.1password.com/home), log in to 1Password itself using its saved autofill, then return to the DocuSign tab (or open a new tab to https://account.docusign.com) and click the password field again to reveal the autofill options.
   • Choose the row for the DocuSign sender account named in the user's companion doc. Do not stop for user handoff just because a password field appears.
3. Submit, then watch what DocuSign asks next. Verify the DocuSign Home page (apps.docusign.com/send/home) before continuing.
4. Only ask for a user handoff if the autofill dropdown does not appear even after executing the 1Password unlock flow above, or if the saved credential is rejected.

If DocuSign asks for a verification code (2FA)

DocuSign sometimes requires an emailed one-time code. Handle it only when DocuSign actually asks — never pre-empt it, and don't repeatedly prompt the user for codes.

1. Route the code to a mailbox you can read. DocuSign shows where it will send the code as a masked address (d***@…, t***@…, j***@…). You can only read the user's own mailbox (via gog). If the offered destination's first letter does not match the user's own email, click "Select another method" / "Try another way" and choose the email option whose first letter matches the user's own email — e.g. if the user's email is alex.rivera@…, pick the a*** option. (You know the user's email from their gog account.) The companion doc lists which addresses to skip (the ones the agent can't read).
2. Trigger the send, then read the code with gog from the user's mailbox:

   gog gmail search 'from:docusign.net is:unread newer_than:15m' --json
   

   Open the newest match and pull the 6-digit code (DocuSign codes come from @docusign.net).
3. Enter the code in DocuSign.
4. If no code arrives within ~1 minute, or there's no readable email option to route to, ask the user for the code — one ask, then wait; don't loop, and don't force 2FA when DocuSign didn't ask for it.

Once signed in, confirm you're on the correct DocuSign account before touching an envelope (screenshot if unsure).

Workflow

References:

• references/sharing-and-rollout.md captures the generic shareable Signature Sleigh workflow-doc link and how to distinguish it from user-specific companion/preference docs.
• references/docusign-web-ui-2026-06.md captures real June 2026 DocuSign browser runs, including the current Home → Start submenu shape, hidden file-input upload, completion-copy recipient role selection, watched-test login/autofill pitfalls, field-placement coordinates/pitfalls, and final Sent-list verification.
• references/docusign-login-controlled-input-2026-06.md captures a DocuSign login pitfall where JS value injection into the controlled email field was discarded; use real browser-harness typing for the email step.
• references/docusign-login-autofill-2026-06.md captures the current DocuSign password-step playbook: click the visible password field, select the saved-password row matching the companion-doc sender account, verify DocuSign Home, and only hand off if visible autofill is unavailable or rejected.
• references/docusign-prefilled-title-fields-2026-06.md captures the watched-test workaround for exact pre-filled signer titles: replace standard editable Title tabs with read-only Text fields when the UI does not expose a reliable default-value control.
• references/docusign-test-cleanup-2026-06.md captures the post-test cleanup path: close Preview, Actions → Discard, confirm Discard Draft, verify the Agreements page, then profile → Log Out and verify the logged-out page.
• references/pre-rollout-bug-bash-test-plan.md captures the three-test release gate before opening Signature Sleigh to a wider audience: internal-only preview+cleanup, counter-signer-first/internal-last with exact titles, and Slack heads-up + tracker logging.
• references/envelope-tracker-status-refresh.md covers companion-doc-driven Google Sheets envelope trackers: logging each sent envelope idempotently and refreshing pending signature status from DocuSign.

Step 1 — the Drive PDF (gog)

1. Extract the file ID from the URL (/file/d/{ID}/view, open?id={ID}, /d/{ID}/).
2. gog drive get <ID> → read the name, the type field (the MIME type), and the modified date. (gog drive get prints type application/pdf for a PDF.)
3. The type must be application/pdf. If it's a Google Doc / DOCX / anything else, stop and ask for a PDF URL (offer to wait while they export). Backstop: the downloaded file in Step 5 must start with the bytes %PDF.
4. Confirm back: "Found 'Acme MSA - Final.pdf', modified May 24 — use this one?" Stop if no.
5. Download it: gog drive download <ID> --out /opt/data/<safe-name>.pdf — this local file is what you upload into DocuSign.

Step 2 — collect signer + recipient details

Ask once, in one structured message (don't drip questions):

• Internal signer (required): name + email — the signer explicitly labeled as the internal/internal-company-side signer by the user; their fields get pre-placed.
• Counter-signers: name + email (title optional), one or many. Default: they sign first. If none, confirm internal-signer-only is intended.
  • Do not silently relabel signers based on email domain, the user's identity, or what seems more likely. If the user says Internal signer: Chris and Counter-signer: Jane, treat Chris as the internal signer and Jane as the counter-signer for this run, even if Jane is the requester or has a internal company email. If the labels look inconsistent with the document or normal company roles, flag it in the preview/checklist and ask for confirmation before sending; never invert the routing order on your own.
  • If exact titles are needed but the user did not supply them, inspect the PDF signature blocks first. Clearly printed title values (for example Title: CEO or Title: Head of Finance) can be used as proposed defaults and should be verified in the preview; do not ask the user for titles that are already plainly present in the PDF unless there is ambiguity.
  • If a provided signer email looks malformed or inconsistent with earlier known values (for example a last-name-only local part where prior runs used a first-name address), pause and confirm the exact email before building the DocuSign draft.
• Subject: default = document name (no "Please sign:" prefix).
• Message: optional body for the DocuSign email.
• Signing order (only ask if not already stated): default = counter-signers first, internal last. Overrides: internal first, or simultaneous.
• Slack heads-up (optional in the generic skill): want a draft heads-up to the signer? If yes, who. If the user's companion doc specifies a default Slack heads-up workflow, treat that as requested for that user and follow the companion's routing/approval rule. Keep this distinction clear in generic/shareable materials: Slack drafting is optional generally, but may be a user's companion-doc default.
• Completion-copy recipients (optional): use any defaults from the user's companion doc; only ask if no default exists and the user appears to need completion-copy recipients.

Step 3 — pre-send checklist

Surface anything off (don't block — make the user confirm): file is a PDF; internal signer + every counter-signer has a valid-looking email; the name doesn't look like a draft ("DRAFT", "v0.", "WIP", "redline") — if it does, confirm it's final; PDF is under ~25 MB. Cross-check the document's signatories against your signer list — if the PDF text is readable, read the printed signature-block names; if the document names a signatory you have no signer for (or a provided signer has no block), flag it and confirm before sending (e.g. three signature lines but only two signers given — confirm whether to add or exclude the third). If the user explicitly says internal signature only, do not automatically add company/counterparty signature-block names found in the PDF; instead, make the preview say those blocks exist and will be excluded, then require the usual explicit approval before sending.

Step 4 — preview + explicit approval (REQUIRED — never skip)

Show a scannable preview and wait for an unambiguous yes. Never send on silence or a maybe.

Ready to send:
  Document: Acme MSA - Final.pdf (modified May 24)
  Subject:  Acme MSA - Final
  Execution order: Counter-signers first, then internal signer
    1. Jane Smith <jane@acme.com>         (counter-signer)
    2. Alex Internal <alex.internal@example.org>  (internal signer — fields assigned)
  Completion copies: per companion doc
  Slack: group-DM heads-up to Chris  (only if requested)
  Checklist: ✓ all passed

Step 5 — build + send the envelope in DocuSign (browser-harness)

Only after approval. Drive the DocuSign web app step by step:

1. Start: from DocuSign home, click Start → Send an envelope. In the June 2026 UI this was Start → Agreements → Envelopes → Send an Envelope (a nested submenu); see references/docusign-web-ui-2026-06.md before improvising if the simple path is not visible.
2. Add the document: in the upload area, upload the PDF you downloaded in Step 1 (drag it in, or "Upload" → the local file /opt/data/<name>.pdf). With browser-harness, the hidden file input usually works directly: upload_file('input[type=file]', '/opt/data/<name>.pdf'); verify a document card/thumbnail and page count appear. DocuSign may also offer "Get from Google Drive" — either works; the downloaded file is the most reliable.
3. Add recipients in the order matching Step 2:
   • Turn "Set signing order" ON for sequential modes; for simultaneous, leave it off (or give everyone order 1).
   • Add each counter-signer + the internal signer as "Needs to Sign", numbered per the chosen order.
   • If the user's companion doc specifies completion-copy recipients, add each as "Receives a Copy" (CC), ordered last, so they get the executed copy after everyone signs. New recipients may default to "Needs to Sign" — open each recipient's role dropdown and explicitly choose Receives a Copy; verify the visible text changed before proceeding.
4. Subject + message from Step 2. Click Next to open the field-placement view.
5. Place the signing fields so every party can just click to sign. Select each recipient from the recipient dropdown in turn, and drag or click-place their fields onto that person's signature block: Signature, Date Signed, Name (+ Initials / Title where the printed block has them). If the PDF already has the signer name and/or title visibly printed in the signature block, do not overlay duplicate DocuSign Name/Title fields in production; place only the fields the signer must complete, unless the user is running a test that specifically requires Name/Title field placement. If the user supplied exact title values that should already be completed (for example Head of Finance, CEO) and they are not printed in the PDF, use Text fields containing those exact values and mark them Read Only instead of using DocuSign's standard editable Title field. If drag-and-drop is fiddly in browser-harness, the current DocuSign builder supports a reliable click-to-place pattern: click the field type in the left sidebar (for example Signature), then click the target line in the document. Put each field on the correct line for that person — your signer goes on the internal-company block ("Internal Company / By: ___"), each counter-signer on theirs. DocuSign often auto-tags from the document's signature lines — if it placed fields, just verify they're on the right party's block. At high zoom, signature fields can land too low and cover printed Name: text; select the field and nudge it with arrow keys (for example repeated ArrowUp) so it sits on the blank signature line. If the document has a pre-filled Place and date and no separate date-signed line, do not force a Date Signed field just to satisfy a generic checklist.
6. Preview before Send. Use DocuSign's Preview button to simulate what the signer will see; click Start in preview to jump to the required field and verify it is visible, assigned to the intended signer, and not covering printed text. For exact names/titles, preview each signer view and visually confirm the rendered full-name and read-only title values, not just that fields exist in the add-fields canvas. In watched/test runs, this preview screen is the right place to stop and ask the user for explicit approval. Do not click DocuSign's Send button from the field-placement screen until the user has unambiguously approved.
7. Review → Send. Watch for send completion. The app may redirect to Agreements → Sent rather than show a modal.
8. Verify in Sent: the newest row should match the document, show To: with the signer(s) plus any completion-copy recipients from the companion doc, and have status like Waiting for with a Resend button. This is stronger verification than assuming the button click succeeded.
9. If any screen doesn't match these steps, screenshot it, describe it to the user, and ask — DocuSign's UI varies. Record a generic fix in this skill, or a user/template-specific note in their companion doc (per the split above).

Step 6 — Slack heads-up (only if requested) — henry-out

If the user asked for a Slack notice, draft it, show the user, and wait for explicit approval before anything is posted.

Reference: references/slack-heads-up-routing.md captures private-channel posting failures, channel_not_found interpretation, and personal/group-DM fallbacks.

Default Slack handling: when the user requests a signer heads-up, draft the message in the current thread for approval first. After the user's explicit approval, post the approved copy back in Slack to the user/current thread for copy/paste into the appropriate channel or DM. Do not attempt to post directly into the requested Slack channel/DM by default, because private channels and personal Slack spaces often reject bot/API posts even when the user provides an archive URL. Only post directly to a channel/DM if the user explicitly asks for direct posting and accepts the access-risk/fallback behavior. Do not attempt to create an unsent draft inside Slack's channel composer unless the user explicitly asks for a live-browser draft.

A Slack channel URL, DM URL, or email alias does not grant posting permission. If direct posting is explicitly requested and henry-out reply --channel <channel_id> returns channel_not_found, treat it as a Slack app membership/access issue: report that the approved note was not posted and provide the approved text in the current thread for the user to copy/paste, or ask the user to invite Henry/the Slack app to the destination if they still want direct posting.

1. Draft a short note: "Chris — DocuSign envelope {envelope_title} is ready for your signature. Please review and sign the document when you have a chance. Thank you." Adjust the signer name and envelope title.
2. Show the user the draft + intended destination context (person, group DM, or channel). Wait for approval — never auto-send.
3. On approval, post the approved copy back to the user/current Slack thread for copy/paste into the appropriate channel or DM. Make clear that this is the copy/paste version and that Henry is not posting it directly to the destination by default.
4. Only if the user explicitly asks Henry to post directly to a destination, send to that approved destination:
   • If the user requested a channel, post the approved message directly to that channel with henry-out reply --channel <channel_id> (or the platform messaging tool if that is the current routing path). Do not post before approval.
   • If the user requested a group DM, use:

     henry-out group --to <signer's workspace email or Slack handle>
     

     This opens a DM with you, the user, and the signer, posts the note, and routes the signer's replies back to your container so you can follow up.
5. If the requested channel/person cannot be resolved, provide the exact approved text and say why it was not posted.
   • If they ask to draft only / do not send, reply with the exact channel-targeted copy and explicitly say Not sent. Do not post to the channel and do not open a group DM.
   • If they approve sending to the channel, use henry-out reply --channel <channel_id> (and --thread only if they specified a thread). Keep the message short and focused on the envelope title and requested action.
   • If the only address supplied is a Slack channel email alias, prefer the explicit Slack channel ID/mention (for example <#C...>) over emailing the alias.
   • A Slack archive link (https://.../archives/C...) or channel mention confirms the channel ID but does not prove Henry can post there. If Slack returns channel_not_found, do not keep retrying the same ID; tell the user Henry/the Slack app likely is not in that private channel or cannot access it, and offer a reachable fallback (current thread, group DM with the signer, or retry after the user invites Henry/the app to the channel).
   • If the user asks to post the draft “to me personally” after a channel post fails, be explicit: replying --in-reply-to posts into the same originating Slack thread, not a separate new personal DM. Only promise a separate DM if a distinct reachable DM target is available.

Step 7 — tracker logging (if companion doc specifies one)

If the user's companion doc specifies an envelope tracker, log the sent envelope after DocuSign send verification and before final reporting. Use references/envelope-tracker-status-refresh.md.

Minimum pattern:

1. Read the tracker first and search for the DocuSign Envelope ID.
2. If the Envelope ID already exists, update that row; otherwise append one row.
3. Capture sent date, document name, subject/envelope title, sender, signing order, signers, CC recipients, current DocuSign status, signed recipients, pending recipients, completed date if present, and the DocuSign details URL.
4. Read the written row back before telling the user it was logged.

When the user later asks what is outstanding, read pending rows from the tracker, open each DocuSign details URL in the Live Browser, and update the tracker from DocuSign as the source of truth.

Step 8 — confirm + report

Keep it short: envelope sent (with the DocuSign envelope name/ID if shown); who gets the first invitation (routing-order-1 recipient); any completion-copy recipients from the companion doc get the executed copy on completion; whether the envelope was logged to the companion tracker; if any signer's fields couldn't be placed, say so; if a Slack heads-up was sent, that it's a group DM and their replies will come to you.

Defaults (fixed — don't ask)

• Sender = the person running the skill, via their own DocuSign account. Never a signer unless they explicitly add themselves.
• Completion-copy recipients = user-specific defaults from the companion doc. Do not hard-code organization- or user-specific CC recipients into this generalized skill; if a user wants a fixed Records/Legal/Ops recipient, put that rule in their companion doc.
• Signing order = counter-signers first, internal signer last (unless overridden).
• Slack = drafted + approved before posting. For channel requests, post the approved text directly to the requested Slack channel; for group-DM requests, use a group DM so replies route back.

Guardrails

• Preview + explicit approval before every send (Step 4).
• PDF only; direct Drive URL only (no search-by-name).
• Never auto-send the Slack notice — draft, approve, then henry-out group.
• If DocuSign isn't logged in and neither autofill nor SSO works, stop and ask — never guess or request a password. If the user completes login and saves the credential in the shared Live Browser profile, note that future runs should try browser/1Password autofill first before handing off again.
• When the requested Slack heads-up destination is a private channel, channel_not_found after an approved henry-out reply --channel <id> attempt means the Slack app/Henry lacks access; do not keep retrying the same post. Report not-posted status and offer invite, personal-thread, or group-DM fallback.
• If the user asks to log out after a sent or watched run, do it before final confirmation and verify the logged-out page (https://www.docusign.com/logged-out / You’ve been securely logged out) rather than assuming the profile-menu click worked. references/docusign-test-cleanup-2026-06.md has the observed logout path; its discard steps apply only to unsent drafts.
• When the DocuSign UI doesn't match this skill, adapt visually + ask — don't click blindly through an envelope.
• Keep this skill generic. A user's specifics go in their companion doc, not here.

Companion-doc template (create one if the user has none)

Make a Google Doc with this structure, share it with the user (writer), and ask them to fill the blanks. Then read it on each run via gog docs cat <doc-id>.

# Send for Signature — <user name>'s preferences

## DocuSign login
- Account / saved login to use (if the browser offers more than one): ____
- Verification-code (2FA) email I can read — the mailbox codes should go to (usually my own): ____
  (If DocuSign defaults to a shared mailbox I can't read, switch to this one via "Select another method".)

## Signing defaults
- Default signing order (if not "counter-signers first, internal last"): ____
- Usual internal signer(s): ____
- Completion-copy recipients and timing (for example, only on completed/executed envelope): ____
- Slack person/channel for heads-ups: ____

## Template / field-placement notes
- Quirks in our standard documents' signature blocks (where each party's Signature/Date/Name go): ____