@smartdoc/cli 0.11.0 → 0.13.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 +131 -46
- 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, but before starting a review or changing anything, unless the user has asked for that draft, tell them and ask which they want; switch_draft moves to another.\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. 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
|
|
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, but before starting a review or changing anything, unless the user has asked for that draft, tell them and ask which they want; switch_draft moves to another.\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. 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. 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.\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",
|
|
@@ -83,6 +83,128 @@
|
|
|
83
83
|
"taskSupport": "forbidden"
|
|
84
84
|
}
|
|
85
85
|
},
|
|
86
|
+
{
|
|
87
|
+
"name": "rename",
|
|
88
|
+
"description": "Renames a document, a folder or a variation, straight away. Only the name changes: files, drafts and contents stay as they are. Original, a document's own variation, keeps its name.",
|
|
89
|
+
"inputSchema": {
|
|
90
|
+
"type": "object",
|
|
91
|
+
"properties": {
|
|
92
|
+
"kind": {
|
|
93
|
+
"type": "string",
|
|
94
|
+
"enum": [
|
|
95
|
+
"document",
|
|
96
|
+
"folder",
|
|
97
|
+
"variation"
|
|
98
|
+
]
|
|
99
|
+
},
|
|
100
|
+
"id": {
|
|
101
|
+
"type": "string",
|
|
102
|
+
"description": "The document (from list_documents), the folder (from list_folders), or a variation of the open document (from list_variations)"
|
|
103
|
+
},
|
|
104
|
+
"name": {
|
|
105
|
+
"type": "string",
|
|
106
|
+
"minLength": 1,
|
|
107
|
+
"maxLength": 200,
|
|
108
|
+
"description": "The new name, as the user will see it"
|
|
109
|
+
}
|
|
110
|
+
},
|
|
111
|
+
"required": [
|
|
112
|
+
"kind",
|
|
113
|
+
"id",
|
|
114
|
+
"name"
|
|
115
|
+
],
|
|
116
|
+
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
117
|
+
},
|
|
118
|
+
"annotations": {
|
|
119
|
+
"readOnlyHint": false,
|
|
120
|
+
"destructiveHint": false,
|
|
121
|
+
"openWorldHint": false
|
|
122
|
+
},
|
|
123
|
+
"execution": {
|
|
124
|
+
"taskSupport": "forbidden"
|
|
125
|
+
}
|
|
126
|
+
},
|
|
127
|
+
{
|
|
128
|
+
"name": "list_folders",
|
|
129
|
+
"description": "The folders organising the user's documents in the app: each with its id, name, path and how many documents and folders are directly in it.",
|
|
130
|
+
"inputSchema": {
|
|
131
|
+
"type": "object",
|
|
132
|
+
"properties": {},
|
|
133
|
+
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
134
|
+
},
|
|
135
|
+
"annotations": {
|
|
136
|
+
"readOnlyHint": true,
|
|
137
|
+
"destructiveHint": false,
|
|
138
|
+
"openWorldHint": false
|
|
139
|
+
},
|
|
140
|
+
"execution": {
|
|
141
|
+
"taskSupport": "forbidden"
|
|
142
|
+
}
|
|
143
|
+
},
|
|
144
|
+
{
|
|
145
|
+
"name": "create_folder",
|
|
146
|
+
"description": "Makes a folder in the app, at the top level or inside another. Only use it when the user asks.",
|
|
147
|
+
"inputSchema": {
|
|
148
|
+
"type": "object",
|
|
149
|
+
"properties": {
|
|
150
|
+
"name": {
|
|
151
|
+
"type": "string",
|
|
152
|
+
"minLength": 1,
|
|
153
|
+
"maxLength": 200,
|
|
154
|
+
"description": "Its name"
|
|
155
|
+
},
|
|
156
|
+
"parent_folder_id": {
|
|
157
|
+
"description": "The folder to put it in, from list_folders (default: the top level)",
|
|
158
|
+
"type": "string"
|
|
159
|
+
}
|
|
160
|
+
},
|
|
161
|
+
"required": [
|
|
162
|
+
"name"
|
|
163
|
+
],
|
|
164
|
+
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
165
|
+
},
|
|
166
|
+
"annotations": {
|
|
167
|
+
"readOnlyHint": false,
|
|
168
|
+
"destructiveHint": false,
|
|
169
|
+
"openWorldHint": false
|
|
170
|
+
},
|
|
171
|
+
"execution": {
|
|
172
|
+
"taskSupport": "forbidden"
|
|
173
|
+
}
|
|
174
|
+
},
|
|
175
|
+
{
|
|
176
|
+
"name": "move_document",
|
|
177
|
+
"description": "Moves a document into a folder, or back to the top level. Only its place on the list changes: its files and drafts stay as they are. Only use it when the user asks.",
|
|
178
|
+
"inputSchema": {
|
|
179
|
+
"type": "object",
|
|
180
|
+
"properties": {
|
|
181
|
+
"document_id": {
|
|
182
|
+
"type": "string",
|
|
183
|
+
"description": "From list_documents"
|
|
184
|
+
},
|
|
185
|
+
"folder_id": {
|
|
186
|
+
"description": "The folder, from list_folders, or null for the top level",
|
|
187
|
+
"type": [
|
|
188
|
+
"string",
|
|
189
|
+
"null"
|
|
190
|
+
]
|
|
191
|
+
}
|
|
192
|
+
},
|
|
193
|
+
"required": [
|
|
194
|
+
"document_id",
|
|
195
|
+
"folder_id"
|
|
196
|
+
],
|
|
197
|
+
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
198
|
+
},
|
|
199
|
+
"annotations": {
|
|
200
|
+
"readOnlyHint": false,
|
|
201
|
+
"destructiveHint": false,
|
|
202
|
+
"openWorldHint": false
|
|
203
|
+
},
|
|
204
|
+
"execution": {
|
|
205
|
+
"taskSupport": "forbidden"
|
|
206
|
+
}
|
|
207
|
+
},
|
|
86
208
|
{
|
|
87
209
|
"name": "delete_document",
|
|
88
210
|
"description": "Asks the user to delete a document for good, with all its drafts, variations and reviews: the app shows them your reason and only their approval deletes it, every time. Only use it when the user has asked for a document to be deleted. Returns waiting_for_user: tell them to switch to the SmartDoc app and answer. Calling it again reports their answer, once; after that it asks again.",
|
|
@@ -364,10 +486,14 @@
|
|
|
364
486
|
},
|
|
365
487
|
{
|
|
366
488
|
"name": "get_review",
|
|
367
|
-
"description": "The current draft's review in the active tool: its type (improve or highlights), goal and status (open or committed), then for an improvement review the user's requests, findings with their decisions and annotations, or for a highlights review the highlights. Null if there is none yet.",
|
|
489
|
+
"description": "The current draft's review in the active tool: its type (improve or highlights), goal and status (open or committed), then for an improvement review the user's requests, findings with their decisions and annotations, or for a highlights review the highlights. Null if there is none yet. With decisions_only, an improvement review's decisions and no more, which is shorter: 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.",
|
|
368
490
|
"inputSchema": {
|
|
369
491
|
"type": "object",
|
|
370
|
-
"properties": {
|
|
492
|
+
"properties": {
|
|
493
|
+
"decisions_only": {
|
|
494
|
+
"type": "boolean"
|
|
495
|
+
}
|
|
496
|
+
},
|
|
371
497
|
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
372
498
|
},
|
|
373
499
|
"annotations": {
|
|
@@ -617,30 +743,6 @@
|
|
|
617
743
|
"taskSupport": "forbidden"
|
|
618
744
|
}
|
|
619
745
|
},
|
|
620
|
-
{
|
|
621
|
-
"name": "remove_finding",
|
|
622
|
-
"description": "Removes a finding from the open review.",
|
|
623
|
-
"inputSchema": {
|
|
624
|
-
"type": "object",
|
|
625
|
-
"properties": {
|
|
626
|
-
"id": {
|
|
627
|
-
"type": "string"
|
|
628
|
-
}
|
|
629
|
-
},
|
|
630
|
-
"required": [
|
|
631
|
-
"id"
|
|
632
|
-
],
|
|
633
|
-
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
634
|
-
},
|
|
635
|
-
"annotations": {
|
|
636
|
-
"readOnlyHint": false,
|
|
637
|
-
"destructiveHint": true,
|
|
638
|
-
"openWorldHint": false
|
|
639
|
-
},
|
|
640
|
-
"execution": {
|
|
641
|
-
"taskSupport": "forbidden"
|
|
642
|
-
}
|
|
643
|
-
},
|
|
644
746
|
{
|
|
645
747
|
"name": "add_highlight",
|
|
646
748
|
"description": "Adds a piece of key information to the open highlights review. Quote the text it's in; leave quotes out for something the user would expect that the document doesn't have.",
|
|
@@ -716,8 +818,8 @@
|
|
|
716
818
|
}
|
|
717
819
|
},
|
|
718
820
|
{
|
|
719
|
-
"name": "
|
|
720
|
-
"description": "Removes a highlight from the open
|
|
821
|
+
"name": "remove_item",
|
|
822
|
+
"description": "Removes a finding or a highlight, by its id, from the open review.",
|
|
721
823
|
"inputSchema": {
|
|
722
824
|
"type": "object",
|
|
723
825
|
"properties": {
|
|
@@ -761,23 +863,6 @@
|
|
|
761
863
|
"taskSupport": "forbidden"
|
|
762
864
|
}
|
|
763
865
|
},
|
|
764
|
-
{
|
|
765
|
-
"name": "get_decisions",
|
|
766
|
-
"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.",
|
|
767
|
-
"inputSchema": {
|
|
768
|
-
"type": "object",
|
|
769
|
-
"properties": {},
|
|
770
|
-
"$schema": "http://json-schema.org/draft-07/schema#"
|
|
771
|
-
},
|
|
772
|
-
"annotations": {
|
|
773
|
-
"readOnlyHint": true,
|
|
774
|
-
"destructiveHint": false,
|
|
775
|
-
"openWorldHint": false
|
|
776
|
-
},
|
|
777
|
-
"execution": {
|
|
778
|
-
"taskSupport": "forbidden"
|
|
779
|
-
}
|
|
780
|
-
},
|
|
781
866
|
{
|
|
782
867
|
"name": "get_draft_preview",
|
|
783
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.",
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@smartdoc/cli",
|
|
3
|
-
"version": "0.
|
|
3
|
+
"version": "0.13.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",
|