Update to Werify

{
  "description": "Search, read, and summarize WhatsApp conversations in the user's connected Werify archive, including available voice-note transcripts and attachments. Use for questions about archived messages, decisions, dates, or shared files.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 320
    }
  ],
  "name": "read-whatsapp-archive",
  "skill_md_contents": "---\nname: read-whatsapp-archive\ndescription: Search, read, and summarize WhatsApp conversations in the user's connected Werify archive, including available voice-note transcripts and attachments. Use for questions about archived messages, decisions, dates, or shared files.\n---\n\n# Read a WhatsApp archive\n\nUse the connected Werify MCP tools within the user's requested scope. Explicit user instructions\ntake precedence over this workflow guidance. Reading an archive does not authorize connecting a\nnumber, starting capture, obtaining earlier history, or sending a message.\n\n## Find and read\n\n1. Resolve the conversation with `search_conversations`. Its query matches conversation names,\n   not message content. Use returned identifiers; disambiguate duplicate names with the user.\n   To find a person, their number or every conversation they appear in, use `list_contacts` if\n   it is in your tool list: it matches a name or a number and returns each conversation's id.\n2. For a period summary or all decisions, use `get_conversation` with the requested local\n   calendar dates. Follow `next_cursor` until null within that window. Pages arrive newest-first;\n   messages inside each page are chronological. Reconcile later decisions with earlier ones.\n3. For a specific phrase or fact, use `search_messages`. When the user does not say which\n   conversation it is in and the schema makes `conversation_id` optional, leave it out: the search\n   spans every conversation, and each match names its conversation. Otherwise search within the\n   resolved conversation. It matches literal substrings, including available audio transcripts,\n   not semantic similarity, so keep the query to the few words that must appear. On every page\n   send the same `query`, and the same `conversation_id` when you passed one, plus the cursor.\n   A keyword search alone cannot establish every decision in a period.\n\nPrefer the callable tool's current schema over remembered arguments. Tools can be reviewed\nindependently, so only call names actually present in your tool list.\n\n## Voice notes and files\n\nRead voice-note content from available inline transcripts in `get_conversation`. A missing\ntranscript is a coverage gap; do not infer what the speaker said.\n\nFor requested files, use `list_attachments`, filter by the requested type and dates, and page\nuntil `next_cursor` is null, sending the same `conversation_id` with each cursor when you passed\none. If its schema has them, pass the words the user gives for the file as\n`query`, which matches the file name and the caption, and leave out `conversation_id` when the\nuser does not say which conversation the file is in: the list then spans every conversation.\nWhen the user has more than one connected number and says which one, pass it as `phone` to\n`search_messages`, `list_attachments` and `list_contacts` if their schemas have it. For PDFs, use\n`type: \"document\"` and identify PDFs from returned file metadata; `pdf` is not a supported type.\nIt lists attachments whose bytes Werify holds: absence does not prove a file was never sent.\nListing files does not require downloading them.\n\nWhen the user asks to inspect or download selected files, or explicitly requests temporary\nlinks, use `get_attachment_file` only for their returned `media_id` values. If its current schema\naccepts lists, group requested IDs into batches of at most 100, removing duplicates while\npreserving order. A list, even with one ID, returns `results`; inspect every entry and report\nper-file errors without discarding successful entries or claiming all files succeeded. A string\nreturns one download. If the available schema accepts only a string, use individual calls.\n\nListing alone must not issue temporary download links. Fetch bytes only when inspection or\ndownload was requested and the host supports it; asking for links alone does not request a fetch.\nThese URLs are bearer links valid until `expires_at`, not host file identifiers. Do not publish\nthem in shared artifacts or ask the user for OAuth tokens. Without the tool or required download\ncapability, offer the authenticated Werify media link and state that you have not inspected\nthe bytes. Request a fresh temporary link when an authorized download needs one after expiry.\n\n## Answer with coverage and evidence\n\nGive the requested findings, dates and supporting excerpts or links returned by Werify. Do not\ninvent a message permalink. Distinguish explicit decisions from inference, and unresolved\ndiscussion from agreement. Do not infer an owner or deadline that the messages do not establish.\n\nState the period actually read and material gaps: unfinished pagination, missing audio,\nunavailable media or interrupted capture. Relay `next_step` from tool responses. An empty\narchive or paused capture does not establish that no conversation or activity occurred.\nIf a tool is unavailable, explain the limit and use a returned web link or\nhttps://werify.app/conversations for the corresponding archive task.\n\nFor example, “all September decisions, including audio” calls for reading the entire September\nwindow, incorporating available audio transcripts, and reporting any uncovered audio. Searching\nonly for the word “decision” would miss agreements expressed differently.\n"
}