@smartdoc/cli 0.14.2 → 0.16.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/lib/server.json +142 -3
- package/package.json +1 -1
package/lib/server.json
CHANGED
|
@@ -14,7 +14,7 @@
|
|
|
14
14
|
"listChanged": true
|
|
15
15
|
}
|
|
16
16
|
},
|
|
17
|
-
"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. The document opens on the draft last worked on, which may not be the newest: get_document_info then says notNewest. Reading it is fine,
|
|
17
|
+
"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. The document opens on the draft last worked on, which may not be the newest: get_document_info then says notNewest. Reading it is fine, and so is a highlights review, but an older draft can't be improved (no improvement review, findings or apply_review): the drafts after it follow on from it. Tell the user, and ask whether they want the newest draft (switch_draft) or to fork this one, into a new variation (create_variation) or a new document (create_document_from_draft); fork it only once they agree.\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.\nWindows: each AI session has a SmartDoc window of its own, opened by its first tool call, and every call goes to it; opening another document reuses it. If the user's prompt names a window, call use_window with it first, so that window becomes yours instead. Another AI may be working on the same document in its own window: reading is always fine, but a change it has claimed (the same variation in an improvement review, the same goal in a highlights review) is refused, so tell the user. If the user moves your window to another document, your next change is refused: open_document brings it back.\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, or, for a comment that needs no decision from them, with reply_to_comment. 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_review and decisions_only.\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 your wait command reports decisions-sent. Nothing pending in their decisions doesn't mean they've finished: they may still be changing decisions or adding comments. 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. Then answer each comment you dealt with using reply_to_comment: an outcome in your own words (\"Actioned\", \"Noted\", \"Not changed\"…) and no_further_action when nothing more is needed. Writing a new preview doesn't answer them by itself, and a comment belongs to the preview it was written on: once you write another, the earlier one's comments no longer count, so answer them first. Comments marked no further action are left out of get_review unless you ask for all_comments: they're done. 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.\nRenaming and folders: rename, create_folder and move_document take effect straight away, so only use them when the user asks. Keep a .pdf ending if the name had one.\nDeleting: delete_document asks the user to delete a document for good, and they approve or decline in the app. Only ask when they've said they want it gone, never to tidy up on your own initiative, and give the real reason.\nWaiting for the user: commit_review, apply_review, and the waiting_for_user replies of open_document and delete_document give you a wait command, a shell command that ends when the user has acted. If you can run commands in the background, as Claude Code can, run it that way, so you can go on talking to the user, and tell them what you're waiting for. While it runs, the app offers them a button to confirm their decisions, or their comments on a draft preview, for you; nothing reaches you until they press it. When it ends it prints JSON saying what happened (event: decisions-sent, preview-accepted, preview-discarded, preview-comments, open-opened, open-cancelled, open-failed, delete-deleted, delete-declined or delete-failed); act on that as if they'd asked you, reading the details with get_review, get_draft_preview or get_document_info. If you can't run commands in the background, don't run it: ask the user to tell you when they're done. If they tell you first, carry on and stop the command.\nText is referenced by quoting it exactly from get_document or find_text (whitespace-insensitive), with the page number.",
|
|
18
18
|
"tools": [
|
|
19
19
|
{
|
|
20
20
|
"name": "use_window",
|
|
@@ -345,6 +345,34 @@
|
|
|
345
345
|
"taskSupport": "forbidden"
|
|
346
346
|
}
|
|
347
347
|
},
|
|
348
|
+
{
|
|
349
|
+
"name": "create_document_from_draft",
|
|
350
|
+
"description": "Forks the open document: makes a new document from one of its drafts (by default the one showing), with a line of drafts of its own starting there, and opens it in this window. The document it came from is left as it is. Only use it when the user agrees, such as to work on an older draft, which can't be improved where it is.",
|
|
351
|
+
"inputSchema": {
|
|
352
|
+
"type": "object",
|
|
353
|
+
"properties": {
|
|
354
|
+
"variation": {
|
|
355
|
+
"description": "The variation the draft is in, by id (default: the one showing)",
|
|
356
|
+
"type": "string"
|
|
357
|
+
},
|
|
358
|
+
"draft": {
|
|
359
|
+
"description": "The draft to start from: its number, 0 for the original (default: the draft showing)",
|
|
360
|
+
"type": "integer",
|
|
361
|
+
"minimum": 0,
|
|
362
|
+
"maximum": 9007199254740991
|
|
363
|
+
}
|
|
364
|
+
},
|
|
365
|
+
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
366
|
+
},
|
|
367
|
+
"annotations": {
|
|
368
|
+
"readOnlyHint": false,
|
|
369
|
+
"destructiveHint": false,
|
|
370
|
+
"openWorldHint": false
|
|
371
|
+
},
|
|
372
|
+
"execution": {
|
|
373
|
+
"taskSupport": "forbidden"
|
|
374
|
+
}
|
|
375
|
+
},
|
|
348
376
|
{
|
|
349
377
|
"name": "get_document_info",
|
|
350
378
|
"description": "The open document's size and shape, to plan how to read it: page count; word, character, line and (estimated) paragraph counts; estimated tokens and whether it can be read whole; the PDF's own details (title, author, dates); its outline (bookmarks) with page numbers; and the same counts for each page, with its first line. If the user is still answering an open_document request, this waits for them first.",
|
|
@@ -492,6 +520,10 @@
|
|
|
492
520
|
"properties": {
|
|
493
521
|
"decisions_only": {
|
|
494
522
|
"type": "boolean"
|
|
523
|
+
},
|
|
524
|
+
"all_comments": {
|
|
525
|
+
"description": "Include the user's comments marked \"No further action required\" and those on earlier draft previews, left out by default",
|
|
526
|
+
"type": "boolean"
|
|
495
527
|
}
|
|
496
528
|
},
|
|
497
529
|
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
@@ -505,6 +537,45 @@
|
|
|
505
537
|
"taskSupport": "forbidden"
|
|
506
538
|
}
|
|
507
539
|
},
|
|
540
|
+
{
|
|
541
|
+
"name": "reply_to_comment",
|
|
542
|
+
"description": "Answers one of the user's comments (a request in get_review, or a comment on the draft preview), shown under it in the app. Say how you dealt with it in outcome, a word or two of your own such as \"Actioned\", \"Noted\", \"Answered\" or \"Not changed\", and set no_further_action when nothing more is needed: a comment that only needed reading is done once noted. A comment you have answered no longer needs a finding in response. The user can open it again.",
|
|
543
|
+
"inputSchema": {
|
|
544
|
+
"type": "object",
|
|
545
|
+
"properties": {
|
|
546
|
+
"comment_id": {
|
|
547
|
+
"type": "string",
|
|
548
|
+
"description": "The comment's id, from get_review or get_draft_preview"
|
|
549
|
+
},
|
|
550
|
+
"text": {
|
|
551
|
+
"description": "Your reply, in a sentence or two: what you changed, or why you didn't. Optional with an outcome",
|
|
552
|
+
"type": "string"
|
|
553
|
+
},
|
|
554
|
+
"outcome": {
|
|
555
|
+
"description": "How you dealt with it, in your own words, a word or two",
|
|
556
|
+
"type": "string",
|
|
557
|
+
"minLength": 1,
|
|
558
|
+
"maxLength": 40
|
|
559
|
+
},
|
|
560
|
+
"no_further_action": {
|
|
561
|
+
"description": "True when nothing more is needed on it; false to leave it open",
|
|
562
|
+
"type": "boolean"
|
|
563
|
+
}
|
|
564
|
+
},
|
|
565
|
+
"required": [
|
|
566
|
+
"comment_id"
|
|
567
|
+
],
|
|
568
|
+
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
569
|
+
},
|
|
570
|
+
"annotations": {
|
|
571
|
+
"readOnlyHint": false,
|
|
572
|
+
"destructiveHint": false,
|
|
573
|
+
"openWorldHint": false
|
|
574
|
+
},
|
|
575
|
+
"execution": {
|
|
576
|
+
"taskSupport": "forbidden"
|
|
577
|
+
}
|
|
578
|
+
},
|
|
508
579
|
{
|
|
509
580
|
"name": "get_history",
|
|
510
581
|
"description": "Earlier reviews of this document, across all its drafts, oldest first, of both types: for highlights reviews, the goal and each highlight; for improvement reviews, each finding with what the user decided (status, chosen option, answer, edit, comment), their requests and their own changes, and what became of each review (applied as which draft, decided but not applied, or never committed). Leaves out the current review.",
|
|
@@ -817,6 +888,74 @@
|
|
|
817
888
|
"taskSupport": "forbidden"
|
|
818
889
|
}
|
|
819
890
|
},
|
|
891
|
+
{
|
|
892
|
+
"name": "revise_finding",
|
|
893
|
+
"description": "Improves one finding of the current review, when the user has talked it over with you: its title, why it matters (body), its suggestion (proposal), its options or its question. Only what you pass changes. A finding the user had decided goes back to undecided for them to decide again, so only revise when it helps them.",
|
|
894
|
+
"inputSchema": {
|
|
895
|
+
"type": "object",
|
|
896
|
+
"properties": {
|
|
897
|
+
"id": {
|
|
898
|
+
"type": "string",
|
|
899
|
+
"description": "The finding's id"
|
|
900
|
+
},
|
|
901
|
+
"title": {
|
|
902
|
+
"type": "string",
|
|
903
|
+
"minLength": 1
|
|
904
|
+
},
|
|
905
|
+
"body": {
|
|
906
|
+
"type": "string"
|
|
907
|
+
},
|
|
908
|
+
"proposal": {
|
|
909
|
+
"type": "object",
|
|
910
|
+
"properties": {
|
|
911
|
+
"before": {
|
|
912
|
+
"type": "string"
|
|
913
|
+
},
|
|
914
|
+
"after": {
|
|
915
|
+
"type": "string"
|
|
916
|
+
},
|
|
917
|
+
"description": {
|
|
918
|
+
"type": "string"
|
|
919
|
+
}
|
|
920
|
+
}
|
|
921
|
+
},
|
|
922
|
+
"options": {
|
|
923
|
+
"minItems": 2,
|
|
924
|
+
"type": "array",
|
|
925
|
+
"items": {
|
|
926
|
+
"type": "object",
|
|
927
|
+
"properties": {
|
|
928
|
+
"label": {
|
|
929
|
+
"type": "string"
|
|
930
|
+
},
|
|
931
|
+
"text": {
|
|
932
|
+
"type": "string"
|
|
933
|
+
}
|
|
934
|
+
},
|
|
935
|
+
"required": [
|
|
936
|
+
"label",
|
|
937
|
+
"text"
|
|
938
|
+
]
|
|
939
|
+
}
|
|
940
|
+
},
|
|
941
|
+
"question": {
|
|
942
|
+
"type": "string"
|
|
943
|
+
}
|
|
944
|
+
},
|
|
945
|
+
"required": [
|
|
946
|
+
"id"
|
|
947
|
+
],
|
|
948
|
+
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
949
|
+
},
|
|
950
|
+
"annotations": {
|
|
951
|
+
"readOnlyHint": false,
|
|
952
|
+
"destructiveHint": false,
|
|
953
|
+
"openWorldHint": false
|
|
954
|
+
},
|
|
955
|
+
"execution": {
|
|
956
|
+
"taskSupport": "forbidden"
|
|
957
|
+
}
|
|
958
|
+
},
|
|
820
959
|
{
|
|
821
960
|
"name": "remove_item",
|
|
822
961
|
"description": "Removes a finding or a highlight, by its id, from the open review.",
|
|
@@ -865,7 +1004,7 @@
|
|
|
865
1004
|
},
|
|
866
1005
|
{
|
|
867
1006
|
"name": "get_draft_preview",
|
|
868
|
-
"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.",
|
|
1007
|
+
"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). Comments belong to the preview they were written on: those on an earlier one aren't included. Change that HTML and call apply_review to do what they asked.",
|
|
869
1008
|
"inputSchema": {
|
|
870
1009
|
"type": "object",
|
|
871
1010
|
"properties": {},
|
|
@@ -882,7 +1021,7 @@
|
|
|
882
1021
|
},
|
|
883
1022
|
{
|
|
884
1023
|
"name": "apply_review",
|
|
885
|
-
"description": "Applies the committed review: supply the complete updated document as self-contained HTML (inline CSS, no scripts or external resources). Keep the current draft's look, and lay the content out in reading order without absolute positioning, so the PDF's text reads in the right order. It becomes a draft preview of the next draft, replacing any earlier draft preview: not a draft until the user accepts it in the app, so tell them to look at it there.
|
|
1024
|
+
"description": "Applies the committed review: supply the complete updated document as self-contained HTML (inline CSS, no scripts or external resources). Keep the current draft's look, and lay the content out in reading order without absolute positioning, so the PDF's text reads in the right order. It becomes a draft preview of the next draft, replacing any earlier draft preview: not a draft until the user accepts it in the app, so tell them to look at it there.",
|
|
886
1025
|
"inputSchema": {
|
|
887
1026
|
"type": "object",
|
|
888
1027
|
"properties": {
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@smartdoc/cli",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.16.0",
|
|
4
4
|
"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.",
|
|
5
5
|
"license": "MIT",
|
|
6
6
|
"type": "module",
|