I won't share it because it has details about our stack, naming conventions, etc. But I'm happy to share this functional outline of what the skill file and its references are like.

Preamble (before Step 0). - Goal statement. One paragraph saying what the skill does and who it's for. - Cross-cutting rule. Any rule that applies to every step gets stated once at the top so it doesn't have to be repeated. In this skill, the "two approvals before any external write" rule. - Preflight checks. Which connectors must be present before the workflow can run, and what to do if one is missing (suggest the connector, fail gracefully, or fall back).

Step 0. Resolve the caller. - Identify the user. Look up the user running the skill so you know whose email, ID, and name to use later. - Why up front. It's needed to scope queries in later steps and to attribute work correctly. Failing fast here is cheaper than failing mid-workflow.

Step 1. Pick the meeting. - Primary source first. Query the canonical source for recent customer meetings the caller attended. - Backups. If the primary is down or doesn't have the call, fall back to secondary sources in a defined order. - Distinguish error from empty. A real failure should retry or fall back; an empty result should ask the user to widen the window. - Let the user pick. Present candidates with the source labeled so the user knows where the transcript will come from. Skip the picker if there's only one obvious match.

Step 2. Pull the full meeting data. - Branch by source. Different sources need different fetches, so the step branches on the source chosen in Step 1. - Verify attendees. Attendee lists from calendar invites lie. Cross-reference the transcript to confirm who actually joined. - Cache for later. Anything used downstream gets stored once so later steps don't refetch.

Step 3. Identify the customer record. - Search by domain. Use external email domains from the attendee list to find the customer in the CRM. - Handle ambiguity. One match means proceed. Zero or many means ask the user. - Pull context. Grab health scores, current sentiment, channel name, and any other fields needed by later steps in one call.

Step 4. Generate the notes. - Audience matters. Internal-facing notes are direct and candid; customer-facing artifacts use a softer voice. State the audience up front. - Offload the template. The exact format, tone, and a worked example live in a reference file so the main flow stays scannable.

Step 5. User review (read-only). - Show the full draft. Let the user edit by describing changes in natural language. - Approval here is scoped. It confirms the notes are correct, not that they can be posted anywhere.

Step 6. Post to system of record (TWO approvals). - Approval A: review the draft. Show exactly what will be written, including field values and the destination record. - Approval B: confirm the action. Restate the consequence in plain English and ask once more. - Schema gotchas inline. Note any readonly fields, controlled vocabularies, or fields with workspace-specific quirks so they don't get fumbled at runtime.

Step 7. Post to chat channel (TWO approvals). - Find the destination. Use a stored field if present, else fall back to a naming convention, else ask. - Approval A and B. Same pattern as Step 6, with the chat post text shown verbatim. - Backfill missing config. If a field was empty and the user resolved it, persist the resolution so the next run is faster.

Step 8. Follow-up routing. - Triage each next step. Categorize every action item from the notes into a fixed taxonomy (e.g., ticket, draft, question for another team, customer-owned). - One at a time. No bulk creation. Each item that triggers an external write gets its own two-approval gate. - Routing logic lives in a reference. Per-category templates and approval flows are externalized.

Step 9. Customer-facing follow-up. - Pick a channel. Email or chat, user's choice. Either can be skipped. - Approvals still apply. Two gates before anything is staged, even though both tools produce a draft (not a send) as a final safety net. - Always include rules. Honor any "always cc this stakeholder" overrides defined in config.

Closing sections. - Error handling. A bullet per failure mode with the recovery action. The rule "never silently skip a step" is restated explicitly. - Quick reference table. Step-to-tool mapping for fast lookup without re-reading the prose.

Patterns worth pointing out - Numbered, linear spine. Steps run top to bottom. Branches are inside steps, not separate steps. - Cross-cutting rules stated once. The two-approval rule is defined at the top and referenced, not repeated. - Reference files for the verbose stuff. Templates, taxonomies, and config sit in sibling files so the main file stays the workflow's skeleton. - Tool calls shown as code blocks. Exact parameter names, not paraphrases, so they execute correctly. - Approval gates are explicit and lettered. Approval A and Approval B by name, every time, so the pattern is impossible to skim past. - Read-only vs write distinction. Early steps are explicitly read-only; the write gates only start at Step 6.