@smartdoc/cli 0.6.0 → 0.7.1

package/lib/server.json

@@ -14,7 +14,7 @@
       "listChanged": true
     }
   },
-  "instructions": "This server is SmartDoc: a desktop app showing the user's document (a PDF). You review it with the user, in one of two kinds of review, and the app shows the current review beside the document. The app has a tool for each kind: \"Review and draft\" (improve) and \"Review and highlight\" (highlights). Only the active tool's review shows, and get_review returns it; start_review switches to its kind's tool, and switch_tool switches without starting one (for example to show the user an earlier review of the other kind). A draft can have several highlights reviews, one per goal, called focuses (e.g. \"Recruiter skim\", \"The career gap\"): list_focuses shows them, with earlier drafts' goals not yet run on this draft, and switch_focus shows one. A new draft starts with none. An improvement review can have a focus too: a goal, and a short name for it (title); the user may send one from the app (\"…suggest improvements, focusing on: …\"). Without one it's a general review. A document can have variations, one per purpose (such as a CV tailored to a job): \"Original\" is its own line of drafts, and each variation has its own drafts from the draft it started at. Reviews and drafts belong to the variation showing (get_document_info names it, with its purpose, which every review in it should serve); list_variations, switch_variation and create_variation manage them.\nOpen: get_document_info and get_document read the document open in the app. If none is open, or the user means a different one (the user may name it with its document id), open it with open_document: by document_id from list_documents (documents the user has opened before), by path (a PDF on the user's computer, which the user confirms in the app), or with neither so the user picks the file in the app. When open_document reports waiting_for_user, tell the user straight away to switch to the SmartDoc app and answer there, then call get_document_info, which waits for them.\nRead: start with get_document_info to see the document's size and outline. A small document can be read whole with get_document. A large one is read a range of pages at a time (get_document with pages), using the outline, each page's first line and find_text to go to what matters; for a highlights review, read what the goal needs rather than everything.\nSettle the goal first: read the document, get_review and get_history, then decide with the user what the review is for before calling start_review. Either they want the document improved (type \"improve\"), or they want to understand it: the key information in it for their purpose (type \"highlights\"). If it isn't clear which, or what they're after, ask. Pass the agreed goal to start_review in their terms.\nAn improvement review, in rounds:\n1. Review: the current review may already hold the user's requests: text they marked to rewrite, comment on, keep, remove, add to, or ask about. The history shows what earlier reviews raised and what the user decided. Don't raise again anything the user rejected or chose to keep, unless that text has changed since or you have a new reason (say so in the finding), and don't ask questions they've already answered: use their answers. Changes they accepted that are still not in the document can be raised again. If the user asks for a fresh review, ignore the history. Decorate text with add_annotation and add findings with add_finding. Every finding offers the user a decision: a proposed change, a choice of options, a question, a structural move, a design change, or a flag to acknowledge. Respond to each user request with a finding that has in_response_to set. Finish with commit_review; the user then decides in the app.\n2. Decide: the user works through the findings, and may write changes of their own. Read their choices with get_decisions.\n3. Apply: carry out what was accepted and the user's own changes (and use the user's answers and comments) by writing the complete updated document as HTML and calling apply_review. Wait for the user's decisions first: call it only when they ask you to, or when get_decisions shows nothing pending. The app draws it to PDF as a draft preview of the next draft, which the user accepts or discards in the app: only they can make it a draft, so tell them to look at it there. If they want it changed, call apply_review again and the new draft preview replaces it. Never apply anything the user rejected, and leave text marked \"keep\" unchanged.\nA highlights review: you decide what's key, for the user's goal. Before starting, having read the document, ask the user what they're looking for and anything about the document that changes what matters (for example which party they are in a contract, or what decision they're making); keep it to the few questions that count. Check list_focuses first: if a focus already has this goal, carry it on or switch to it rather than starting a near-duplicate; if the user wants an earlier draft's focus run again, reuse its goal and name. Start the review with the goal, a short name for it as a focus (title, a few words in the user's terms), and what you learned (context). Then add_highlight for each piece of key information: quote its text, put it in a category you choose for this document (a handful, named in the user's terms, such as \"Payment\", \"Deadlines\", \"Your obligations\", \"Risks\"), say in the note why it matters for their goal, and rate its importance. Also add what the user would expect but the document doesn't say, as a highlight without quotes. Be selective: what matters for the goal, not a summary of everything. Finish with commit_review, with a summary that answers their goal in a few sentences. get_history shows earlier focuses, so a later review can build on them. Nothing is decided or applied, and the document doesn't change.\nText is referenced by quoting it exactly from get_document or find_text (whitespace-insensitive), with the page number.",
+  "instructions": "This server is SmartDoc: a desktop app showing the user's document (a PDF). You review it with the user, in one of two kinds of review, and the app shows the current review beside the document. The app has a tool for each kind: \"Review and draft\" (improve) and \"Review and highlight\" (highlights). Only the active tool's review shows, and get_review returns it; start_review switches to its kind's tool, and switch_tool switches without starting one (for example to show the user an earlier review of the other kind). A draft can have several highlights reviews, one per goal, called focuses (e.g. \"Recruiter skim\", \"The career gap\"): list_focuses shows them, with earlier drafts' goals not yet run on this draft, and switch_focus shows one. A new draft starts with none. An improvement review can have a focus too: a goal, and a short name for it (title); the user may send one from the app (\"…suggest improvements, focusing on: …\"). Without one it's a general review. A document can have variations, one per purpose (such as a CV tailored to a job): \"Original\" is its own line of drafts, and each variation has its own drafts from the draft it started at. Reviews and drafts belong to the variation showing (get_document_info names it, with its purpose, which every review in it should serve); list_variations, switch_variation and create_variation manage them.\nOpen: get_document_info and get_document read the document open in the app. If none is open, or the user means a different one (the user may name it with its document id), open it with open_document: by document_id from list_documents (documents the user has opened before), by path (a PDF on the user's computer, which the user confirms in the app), or with neither so the user picks the file in the app. When open_document reports waiting_for_user, tell the user straight away to switch to the SmartDoc app and answer there, then call get_document_info, which waits for them.\nRead: start with get_document_info to see the document's size and outline. A small document can be read whole with get_document. A large one is read a range of pages at a time (get_document with pages), using the outline, each page's first line and find_text to go to what matters; for a highlights review, read what the goal needs rather than everything.\nSettle the goal first: read the document, get_review and get_history, then decide with the user what the review is for before calling start_review. Either they want the document improved (type \"improve\"), or they want to understand it: the key information in it for their purpose (type \"highlights\"). If it isn't clear which, or what they're after, ask. Pass the agreed goal to start_review in their terms.\nAn improvement review, in rounds:\n1. Review: the current review may already hold the user's requests: text they marked to rewrite, comment on, keep, remove, add to, or ask about. The history shows what earlier reviews raised and what the user decided. Don't raise again anything the user rejected or chose to keep, unless that text has changed since or you have a new reason (say so in the finding), and don't ask questions they've already answered: use their answers. Changes they accepted that are still not in the document can be raised again. If the user asks for a fresh review, ignore the history. Decorate text with add_annotation and add findings with add_finding. Every finding offers the user a decision: a proposed change, a choice of options, a question, a structural move, a design change, or a flag to acknowledge. A comment is the user's own note on the text they selected; if the review already holds their comments and no goal, responding to them is the goal, so don't ask for one. Respond to each user request with a finding that has in_response_to set. They can add comments while you work, so read get_review again before committing: commit_review refuses while one has no response. Finish with commit_review; the user then decides in the app.\n2. Decide: the user works through the findings, and may write changes of their own or add comments on the text (requests with afterCommit set). Read their choices with get_decisions.\n3. Apply: carry out what was accepted, the user's own changes and their afterCommit comments (and use the user's answers and comments) by writing the complete updated document as HTML and calling apply_review. Wait for the user's decisions first: call it only when they ask you to, or when get_decisions shows nothing pending. The app draws it to PDF as a draft preview of the next draft, which the user accepts or discards in the app: only they can make it a draft, so tell them to look at it there. If they want it changed, call apply_review again and the new draft preview replaces it. They can comment on the draft preview itself (requests with onPreview set, quoting its text, not the draft's): call get_draft_preview, make what they asked in its HTML, leave the rest as it is, and call apply_review. Requests with resolved set are done: ignore them. Never apply anything the user rejected, and leave text marked \"keep\" unchanged.\nA highlights review: you decide what's key, for the user's goal. Before starting, having read the document, ask the user what they're looking for and anything about the document that changes what matters (for example which party they are in a contract, or what decision they're making); keep it to the few questions that count. Check list_focuses first: if a focus already has this goal, carry it on or switch to it rather than starting a near-duplicate; if the user wants an earlier draft's focus run again, reuse its goal and name. Start the review with the goal, a short name for it as a focus (title, a few words in the user's terms), and what you learned (context). Then add_highlight for each piece of key information: quote its text, put it in a category you choose for this document (a handful, named in the user's terms, such as \"Payment\", \"Deadlines\", \"Your obligations\", \"Risks\"), say in the note why it matters for their goal, and rate its importance. Also add what the user would expect but the document doesn't say, as a highlight without quotes. Be selective: what matters for the goal, not a summary of everything. Finish with commit_review, with a summary that answers their goal in a few sentences. get_history shows earlier focuses, so a later review can build on them. Nothing is decided or applied, and the document doesn't change.\nText is referenced by quoting it exactly from get_document or find_text (whitespace-insensitive), with the page number.",
   "tools": [
     {
       "name": "list_documents",
@@ -679,7 +679,24 @@
     },
     {
       "name": "get_decisions",
-      "description": "The user's decisions on the current review: each finding's status (pending, accepted, rejected, answered, acknowledged), chosen option, answers, edited wording and comments, plus their requests and the changes they wrote themselves (changes: carry these out too). preview is the draft preview waiting for the user, if any; outdated means they changed their decisions since it was written.",
+      "description": "The user's decisions on the current review: each finding's status (pending, accepted, rejected, answered, acknowledged), chosen option, answers, edited wording and comments, plus their requests and the changes they wrote themselves (changes, and requests with afterCommit set: carry these out too). preview is the draft preview waiting for the user, if any; outdated means they changed their decisions since it was written.",
+      "inputSchema": {
+        "type": "object",
+        "properties": {},
+        "$schema": "http://json-schema.org/draft-07/schema#"
+      },
+      "annotations": {
+        "readOnlyHint": true,
+        "destructiveHint": false,
+        "openWorldHint": false
+      },
+      "execution": {
+        "taskSupport": "forbidden"
+      }
+    },
+    {
+      "name": "get_draft_preview",
+      "description": "The draft preview waiting for the user: its complete HTML, its summary, and the user's comments on it (quoting its text, which get_document doesn't show). Change that HTML and call apply_review to do what they asked.",
       "inputSchema": {
         "type": "object",
         "properties": {},

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@smartdoc/cli",
-  "version": "0.6.0",
+  "version": "0.7.1",
   "description": "The smartdoc command: sets up Claude Desktop and Claude Code to use the SmartDoc app, checks the connection, and runs SmartDoc's MCP connection for agents set up with npx.",
   "license": "MIT",
   "type": "module",