{"id":52891,"plugin_id":"plugin_asdk_app_6ad2b643da1481919c8e5567690b0ceb","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-10-24T13:51:40.087Z","digest":"bbe4e71fbbecd87c75f12ef9f2f54f7fb210f568e52759995c828b1f4f1d075d","against":null,"payload":{"description":"Summarize visitor engagement and internal activity across DocSend Spaces or shared documents for a requested reporting period. Use when someone asks for a one-time deal activity briefing, Space engagement summary, or summary of document visits and changes.","included_files":[],"name":"docsend-deal-activity-briefing","skill_md_contents":"---\nname: docsend-deal-activity-briefing\ndescription: Summarize visitor engagement and internal activity across DocSend Spaces or shared documents for a requested reporting period. Use when someone asks for a one-time deal activity briefing, Space engagement summary, or summary of document visits and changes.\n---\n\n# DocSend Deal Activity Briefing\n\nProduce a concise briefing for the current request using the DocSend MCP. Cover visitor engagement and internal changes separately, with clear reporting dates and data limits.\n\n## Set scope and reporting period\n\nIdentify requested Spaces or shared documents from the request and conversation. Use the user's timezone and state the exact dates covered.\n\n- “Yesterday” means the previous calendar day.\n- “Last week” means the previous calendar week, Monday through Sunday.\n- If the period is missing or ambiguous, default to the previous calendar week and explicitly state that assumption. Preserve any unambiguous dates supplied by the user.\n- If resource scope is unspecified or ambiguous, use clear context where possible; otherwise default to accessible, enabled Spaces the user owns or collaborates on for that period, stating the assumed scope. Do not silently expand to all company Spaces or all Library documents. If the resource cannot be resolved without a material risk of reporting the wrong deal, ask for clarification while proceeding with unambiguous resources.\n\nCompute calendar boundaries in the user's timezone, accounting for daylight-saving changes, then convert timestamps for tool calls. Filter the interval from the start of its first day up to, but excluding, the next day after its last day. For a period still in progress, disclose the retrieval cutoff.\n\n## Resolve resources\n\nUse `list_spaces` to resolve Space names and `search_documents` / `list_content_library` to find requested Library documents. Use `list_space_content`, starting with a Space's returned `home_folder_id`, for its documents and folders. Follow pagination and inspect relevant folders. The Content Library and Space content are separate surfaces.\n\nExclude Spaces explicitly marked disabled. Zero activity is not evidence that a Space is disabled. State exclusions concisely when relevant. Use `all_company` only when the user asks for all company Spaces and their access supports it.\n\n## Retrieve activity and assess coverage\n\nUse `list_visits` scoped by `space_id` for a room or `document_id` for a shared document. Omit `contact_id` for general engagement summaries; use it only for a specifically requested visitor after resolving them with `search_contacts`.\n\nThe current visits tool has no date-range parameter. Follow pagination and filter visit timestamps locally to the reporting period. Do not assume pagination order or stop at an old record unless documented ordering guarantees full coverage. For Space changes, use `list_space_events` with `from` and `to`, following pagination and applying the same reporting boundaries locally. Its end filter is inclusive, so exclude events at the next-day boundary locally.\n\nFor audit events, use `display_name` in all user-facing communication. Never expose raw event type values; use them only in tool filters. Attribute changes to the returned actor when identifiable, using their name or email. Do not infer the actor from Space ownership or assume every audit event is internal: visitor views, downloads, and signatures belong with visitor engagement. Inspect returned event details before describing what changed. If details identify only an update, do not invent the changed fields or claim a new document version without evidence.\n\nFor standalone documents, retrieve available visits. Space audit events are scoped to a Space: do not treat Library timestamps as a complete change log or claim standalone internal history is available when no supported source exposes it. If a requested document belongs to a known relevant Space, use that Space's accessible events and clearly scope the findings.\n\nTrack coverage separately for visits and internal activity for each resource. Distinguish:\n\n- Successful complete retrieval with no in-period activity.\n- Partial retrieval or incomplete pagination.\n- Data unavailable because of plan or permission limits.\n- Failed retrieval.\n\nWhen the response establishes that the user's plan lacks Space analytics, state that the current plan does not include the Space analytics needed through MCP and that upgrading to an eligible DocSend plan, such as Advanced Data Rooms when identified by the tool, is required. Do not diagnose a generic permission or retrieval error as a plan limit. If entitlement is unverified, state the observed limitation without asserting which plan the user has. On `insufficient_scope`, ask for re-authentication before retrying. Continue with independently accessible data and disclose its limits.\n\n## Compute only supported metrics\n\nReport new or returning viewers, unique counts, downloads, and engagement changes only when available evidence supports them.\n\n- Count identifiable viewers using stable internal identifiers or normalized email evidence where available; a display name alone may not identify a unique person. Keep anonymous visits separate from identified unique viewers. Do not turn visit counts into people counts.\n- Define whether counts are per document, per Space, or across the briefing. Do not add per-resource unique counts and call the sum an overall unique count.\n- Distinguish new-to-this-resource viewers from returning viewers only with sufficient earlier history for that same resource. If only the reporting window was retrieved, say “first observed in this period” rather than claiming a viewer is new. Lifetime contact totals do not establish prior visits to this deal.\n- Visits expose views and viewing measures, not download events. Report downloads only when audit events or another source explicitly records them. Keep bulk downloads distinct from individual-document downloads unless their contents are known.\n- Visit and audit logs can describe the same view. Use visits for view metrics and events for complementary actions; do not sum both into duplicate activity counts.\n- Total visit duration is in milliseconds; per-page duration is in seconds. Convert units correctly. Describe notable changes only with a supported comparison baseline and label its dates and scope; otherwise describe the observed activity without a trend claim.\n\n## Write the briefing\n\nStart with a concise overall summary highlighting the most useful observed findings, the exact reporting dates and timezone, and any limits affecting the overall conclusion. Keep it clear, short, and scannable.\n\nOrganize the rest by Space or shared document, prioritizing notable activity. Link resource names with verified source URLs when available; do not construct URLs from internal identifiers or create sharing links for citations. For each resource, include relevant sections:\n\n- **Visitor engagement:** Supported new/returning viewer information, documents viewed or downloaded, activity dates, and notable supported changes.\n- **Internal activity:** Document additions or versions, file/folder changes, link creation or updates, and permission changes. Name the actor when identified in the activity data.\n- **Recommended follow-ups:** Only concrete, actionable recommendations supported by the observed activity. Label them as recommendations and omit this section when none is meaningful.\n\nGroup resources with no activity in a brief closing line only when both relevant activity sources were successfully covered. For partial coverage, state specifically which source had no records and which was unavailable. Clearly identify resources whose activity could not be retrieved. Do not imply inaccessible data was reviewed.\n\nSeparate observed facts from interpretations and recommendations. Viewing and downloading do not establish purchase or investment intent. Do not overstate attention, concern, or understanding from duration or viewing percentage.\n\n## Scope boundary\n\nThis skill produces a one-time briefing. It does not configure recurring delivery or create scheduled tasks. Handle any scheduling request separately, and only when a supported scheduling capability can run the workflow with DocSend access.\n\nDiscover live tool schemas and obey access checks. Keep result fields named `id` or ending in `_id` internal, referring to human-readable names, emails, dates, and verified URLs. Check text errors as well as structured results. Preparing the briefing does not authorize changes to documents, Spaces, links, groups, or permissions. Do not call live write tools merely to test this skill.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}