{"id":81033,"plugin_id":"plugin_asdk_app_6a9ae42bf8148191b31cd429bd5937d5","kind":"skill","collection_source":"plugin_package","comparison_source":null,"observed_at":"2026-11-04T18:09:35.617Z","digest":"7a763557ba8d21ecaa3a01ac353b09ad5b1ce9c7fc44994533a37e0d2a29f396","against":null,"payload":{"description":"Answer the same questions across many documents at once — a vLex collection, a matter's files, or several files uploaded together — as a Clio review table with the documents as rows and the questions as columns. Covers asking for the table in the shape that builds one, choosing columns or a review template, getting the cells back over a connection that cannot render the table, waiting out rows that are still being answered, and adding, dropping or rephrasing columns and rows afterwards. Use it whenever the answer would be per-document findings, even when the user never says \"table\". Requires a corpus of more than one document; a single document reviewed, summarised or questioned is not this skill, even when the user just uploaded it.","included_files":[],"name":"tabular-review","skill_md_contents":"---\nname: tabular-review\ndescription: Answer the same questions across many documents at once — a vLex collection, a matter's files, or several files uploaded together — as a Clio review table with the documents as rows and the questions as columns. Covers asking for the table in the shape that builds one, choosing columns or a review template, getting the cells back over a connection that cannot render the table, waiting out rows that are still being answered, and adding, dropping or rephrasing columns and rows afterwards. Use it whenever the answer would be per-document findings, even when the user never says \"table\". Requires a corpus of more than one document; a single document reviewed, summarised or questioned is not this skill, even when the user just uploaded it.\n---\n\n# Tabular review (Clio Tables)\n\nRows are documents, columns are questions, and every cell is answered against its\nown document. It is a questionnaire run over a corpus, not one long answer about it.\n\nThere is no table tool on this server. The nine table tools live inside Clio and\nit calls them itself; what selects them is how the `question` reads. So everything\nbelow is about what you *say*, not what you call — and the mechanics of the turn\nitself belong to **clio**.\n\n## When this is the shape\n\nWhenever the answer would be per-file extraction across several uploaded files or a\nconnected collection's files. The signal is parallel per-document analysis: if you\nwould otherwise read each document and produce a separate result for each, this\nhandles it better. The user need not say \"table\", \"tabular\" or \"Clio Tables\".\n\nNot this when:\n\n- one document reviewed, summarised or questioned, even when the user just uploaded it;\n- a holistic answer that needs no per-document output — \"do any of these have an\n  arbitration clause?\" is one question, not a column;\n- the corpus is small enough that reading the documents inline answers it directly.\n\n## Connect the corpus first\n\nRows come from **the corpus connected to the conversation**, so connect it on the\ncall that starts the work:\n\n- a collection or matter → `collection_id` on `start_research`, discovered with\n  `list_collections`. Never a composed id.\n- uploads → `file_ids`, each confirmed `available` with `get_file_status` first.\n\nWith neither, Clio has no corpus to draw rows from and answers as ordinary\nresearch over whatever is at hand. The table caps at 1000 rows on most accounts.\n\n## Ask for it in the shape it works\n\nPut two things in `question`: the corpus, and the questions to ask of every\ndocument. \"For each contract in the Acme collection, tell me the governing law, the\ntermination notice period, and whether liability is capped\" is the shape. A vague\n\"review these\" produces prose, not a table.\n\n- **Narrowing is a search, not a filter.** Clio adds rows by searching the\n  connected collection, so \"only the 2024 ones\", \"only NDAs\" becomes that query —\n  say it and the corpus narrows. This works on any connected collection.\n- **Column types.** A column can be text, number, boolean, or verbatim — verbatim\n  quotes the document's own words. Say which when it matters; otherwise Clio\n  picks.\n- **Templates.** There are column templates for common review types. When the user\n  names a familiar one (\"an NDA review\", \"a due-diligence pass\"), ask for it by name\n  instead of composing twelve columns. Which templates exist depends on the account,\n  so ask what is available rather than promising a specific one.\n- Infer a small, coherent set of columns when the user is vague. Dozens of columns\n  is a request for exhaustive coverage, not a default.\n\n## The table is invisible here — this is what people get wrong\n\nIn Clio's own UI the table renders live, and Clio is told not to repeat it in\nchat so the user does not see it twice. Over this connection there is no renderer,\nso a build turn's `answer` is a one-line confirmation with the results nowhere in the\n`TurnResult`: the projection keeps prose only, and cells are not documents so they\nare not in `files` either. The build shows up in `activity` (\"Created document review\ntable\", \"Added columns…\").\n\nSo a build is not finished when the turn returns. **Call `read_review_table` right\nafter it, and after every time you add files — without being asked** — and tell the\nuser the row count against what they expected. That a table was built says nothing\nabout which documents became rows: a corpus search that matched two documents of\nnineteen confirms exactly like one that matched all nineteen, and the user finds out\nonly if you looked. That first read is for the rows; the cells arrive later.\n\n## The cells fill after the turn ends\n\nThe review runs on a background queue that is not one of the conversation's tasks,\nso the turn can complete — and `get_conversation_metadata` can read `finished` —\nwhile cells are still empty. Treat an empty cell, or a row tagged with a status other\nthan complete, as **pending** rather than as an answer: wait, then ask again.\n\nTwo settled outcomes are legitimate and worth naming to the user rather than papering\nover: a document the table could not read (scanned, corrupt, unsupported), which\ncomes back as a failed cell, and a question a document simply does not address.\nNeither is a \"no\". Cell wording is localized to the conversation's language, so read\nthe shape of the cell, not an English string.\n\n## Reading it back\n\n`read_review_table(conversation_id)` returns the grid as it stands — the columns, the\nrows keyed by column, `row_count`, and `formatted`, the same grid as a markdown\ntable with its cells excerpted so it stays scannable.\n\n**Do not answer off a table that is still filling.** `empty_cells` counts the cells\nwith no answer yet across every row. While it is falling, the review is still\nrunning: wait and read again. Stop when two reads agree — whatever is blank then is a\nquestion those documents do not answer, which is a finding and not a gap — or when\nthe user asks to see it as it stands. Say which of the two you are showing.\n\n**Paste `formatted` as it comes, and keep its shape.** One row per document, one\ncolumn per question: reading *across* the documents is the whole point, so a table\nper document is the same loss as a paragraph — it answers about each contract and\ncompares none of them. When the user asks about one document or one clause, quote\nthat cell in full from `rows`. It is read-only and costs no turn, so it is\nalso how you check a build before telling the user anything about it. It returns\n`truncated` when there are more rows than it returned; raise `max_rows` and say which\nrange you actually have, because the first rows of a long table are not the review.\n\nAsk Clio in prose instead when the user wants the table *interpreted* — a summary,\na memo, an answer across rows. That is a turn, and it is worth one; reading the cells\nis not.\n\nA cell answers for its own document only. Do not generalize one row to the corpus,\nand never report a count or a conclusion the table did not report.\n\n## Changing it afterwards\n\nEvery change is `continue_conversation` on the **same** `conversation_id` — a fresh\n`start_research` cannot see the table. Say what should change in the user's terms:\nadd columns, rephrase a question, rename a header, change a type, drop columns, drop\nrows, restore rows dropped earlier, add files uploaded since.\n\n- Rephrasing a question and replacing the column set are different requests. For a\n  wholesale replacement say so, or the old columns stay alongside the new ones.\n- A file has to be on the conversation before it can be a row. Once\n  `get_file_status` says it is available, attach it and ask for it in the same call:\n  `continue_conversation(file_ids=[...], message=\"Add this file to the table.\")`. A\n  message is always required.\n- Stay with the table for the rest of the conversation. Reverting to per-document\n  reading mid-thread abandons the rows already answered.\n- Do not invent or repeat internal identifiers — template ids, column keys, row ids —\n  in anything the user reads.\n\n## Tying it to research\n\nThe strong version pairs the two: research the legal standard first, then use what\nit established as the columns each document is tested against. Keep both in one\nconversation so the research and the table share context, and when reporting, keep\nClio's legal conclusions separate from the per-document findings.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}