Introduction¶

When developing with DSH, two common types of waste occur: requirements are only half-said, the plugin dives in blindly, and only after finishing do you realize you misunderstood; or a valuable conclusion and lessons learned from a session are lost when the session is closed, requiring the same conversation to start from scratch next time. hoaxquill/dsh-thinking-review (maintainer HoaXQuill) addresses these two points: one is a per-session “Follow-up Clarification” toggle, and the other is a “Review Session” button that organizes this round of Q&A into four sections and asks you which items to agree to write into long-term memory. Below, the capabilities described in the documentation are introduced, with installation commands and interface names quoted directly from the original text.

What is it¶

One sentence: A DSH plugin that turns “think before you act” and “post-session review” into a toggle and a button.

• Repository: https://github.com/HoaXQuill/dsh-thinking-review
• Version: 1.3.0 (as indicated in package.json in the documentation)
• Category: Conversation Enhancement / Memory (as per the documentation’s classification table); listed under the “Memory” category in the community directory
• Dependencies: DSH Desktop (web client is semi-functional), cordis plugin tree, Node ≥ 20, license is MIT
• It solves an interaction flow problem, not a model capability problem: How to ask when requirements are vague, how to stop after asking, and how to preserve experience after a session ends.

Core Functions¶

The plugin does three things: Follow-up clarification, review this session, and archive review experience.

1. Follow-up Clarification (per-session toggle)¶

An extra line [● Follow-up Clarification: On/Off] appears below the input box. When enabled, DSH asks before acting when requirements are vague. The criteria come from “Advanced Thinking: Verification, Correction, and Refactoring,” with the core being one sentence: Ask only to reduce the probability of doing it wrong. The main rules listed in the documentation:

1. Don’t ask if information value is zero: When all possible answers point to the same course of action, just do it.
2. Find the decision first: Identify which decision or deliverable this request changes; if you can’t say, you haven’t understood it, and this is the most important question to ask.
3. Ask and then stop to wait: The question marks the end of this round; do not write code, do not modify files, and do not proceed with default values. Even if an inquiry times out, it does not imply agreement, so it still stops to wait. The same question in a round is sent only once. Work begins only when the user explicitly says “Use defaults / Don’t ask / Just do it,” listing the assumptions adopted.
4. Check tools first, then ask if they need to be installed: List the CLI / plugin / MCP / skill to be used, and check them one by one against the checklist at hand (package.json, configs, skill directories, internet search if necessary). Ask only if the missing item is indispensable. The question must include the tool name, purpose, why it cannot be replaced, and the installation cost (internet / package installation / permissions / size / restart), offering three options: “Install / Replace with alternative / Don’t do it yet.” Install locally to the project first, then verify immediately and paste the result.
5. Proactively scan ten “unclear” aspects: Target, deliverables and format, acceptance criteria, scope and what is not included, constraints, environment and permissions, data and source, time and priority, reversibility, existing conventions. Check what can be found by reading files first; when asking, pick 1–3 items based on “Cost of being wrong × Uncertainty”.
6. Provide at least 3 reasonable interpretations, and give one distinguishing prediction for each.
7. Only ask where approaches diverge; if the divergence is less than “changing one phrase,” don’t ask. 1–3 questions (max 5), numbered, with default values, allowing one “Return to defaults.”
8. Read reconnaissance only before answering: Do not answer while asking, do not ask and answer yourself, and do not provide a final solution.
9. Repeat before answering: 1–3 sentences of spec plus “what would change your mind,” then start work.
10. Deliver with boundaries: Clearly state the scope of applicability and conditions for invalidation in one line.
11. Stop immediately and start: If the user says “Don’t ask / Just do it / Stop,” stop immediately, and list the assumptions and boundaries.

The toggle state is saved to $DSH_HOME/dsh-thinking-review/state.json and persists after refreshing the page or restarting DSH. It is worth noting that the plugin only works for the main session; child agents are always skipped.

2. Review this session (button)¶

The [Review Session] button next to the input box sends a review command to the current session (not to other sessions, and does not modify drafts). It produces four sections:

1. Session Summary: What was done and the conclusions.
2. Conclusions and Decisions: Including rejected plans and reasons.
3. Success Experiences: Reusable practices, clearly stating applicable conditions.
4. Candidate Long-term Memories (3–8 items): One sentence per item, ready to be directly remember.

Finally, a separate line asks “Write all / Write specific ones / Don’t write.” After explicit agreement, write them item by item; if “Don’t write,” stop without repeated persuasion.

3. Review Experience (new row in left navigation)¶

A new row “Review Experience” appears in the left navigation. Clicking it shows archives of all reviews on the local machine. Each shows time, session title (or first 8 characters of session ID if title is unreadable), word count, file type (PDF / MD / Generating), and summary; supports opening (new tab), expanding full text, copying, deleting (requires double confirmation and deletion of the file simultaneously), and refreshing.

Storage mechanism: When “Review Session” is clicked, the browser side first POST /reviews/request to register, the Host subscribes to session/event, accumulates the assistant/message body of this round, and only stores it when turn/end and the body is ≥ 160 characters. The Host renders the HTML itself (Microsoft YaHei, A4, @page margins), then calls the local Edge/Chrome headless mode to print to PDF (--headless=new --print-to-pdf), without internet access or installing dependencies, and generation is asynchronous.

Known limitations are recorded below:

• If Edge/Chrome cannot be found or --print-to-pdf is blocked by security software, it automatically falls back to <id>.md, the list displays “MD,” and opening it still shows plain text.
• Printing goes through the local browser process; it will fail and fall back to MD if installed in an environment with restricted sub-processes (e.g., AppContainer).
• Only reviews generated after 1.1.0 appear in the list; earlier ones are not backfilled; older plain text records will be supplemented with PDF generation when the page is opened.
• The list has a maximum of 500 items; older ones are discarded.
• State file is compatible with the old name dsh-clarify: when the new file does not exist, it reads $DSH_HOME/dsh-clarify/state.json, and the next write migrates it to the new path.

Installation and Enablement¶

From GitHub (no npm needed)¶

dsh plugin add github:HoaXQuill/dsh-thinking-review

From npm (after release)¶

dsh plugin add dsh-thinking-review

Or search for dsh-thinking-review in the “Plugin Market” on the desktop client and install it, then restart DSH.

From local directory (during development)¶

dsh plugin add file:C:/Users/HoaXQ/Desktop/插件/dsh-thinking-review

The equivalent writing in the profile’s package.json is:

{
  "dependencies": { "dsh-thinking-review": "file:C:/Users/HoaXQ/Desktop/插件/dsh-thinking-review" },
  "dsh": { "profile": { "bundles": ["dsh-thinking-review"] } }
}

The plugin is inserted into the plugin tree by cordis.patch.yml inside the package. The Host side uses main / exports["."] (lib/index.js), and the Client side uses exports["./client"] (lib/client.js, dsh.client.platform = "web"). Plugin code changes do not hot reload; DSH needs to be restarted (click “Restart Now” in the Plugin Market on the desktop client).

Typical Usage¶

After installation, click the toggle line below the input box to enable it. When requirements are vague, the plugin will stop asking according to rule #3 above; it will not write code while asking, nor will it ask and answer itself.

For diagnosis or troubleshooting, you can directly use the HTTP interfaces. The Host side is registered at /dsh-thinking-review:

GET  /dsh-thinking-review/state?session=<id>      Query the toggle status of a specific session
POST /dsh-thinking-review/state                   body {session, enabled}, write and immediately mount/unmount
GET  /dsh-thinking-review/text                    The actual effective prompt in the current process (for diagnosis)
GET  /dsh-thinking-review/mounted                 List of mounted sessions, state file path, number of reviews
GET  /dsh-thinking-review/reviews                 List of reviews (without full text)
POST /dsh-thinking-review/reviews/request         body {session}, register this round to be included in the review

Full text of a single review and the file body are accessed via GET /dsh-thinking-review/reviews/item?id= and GET /dsh-thinking-review/reviews/file?id= (the file body returns application/pdf or text/markdown, add ?download=1 to download, returns 409 if not yet generated); deletion uses POST /dsh-thinking-review/reviews/delete, body {id}.

To verify changes, the repository comes with two scripts that do not rely on the DSH runtime (Host side uses a mock ctx, Client side uses a mock window.__ModuleLoader__ and a minimal React shim):

node test/smoke.mjs        # Host side: routing, mounting, unmounting, keyword criteria
node test/client-smoke.cjs # Client side: slot registration, button, command delivery to session

Applicable Scenarios and Notes¶

Suitable for developers using Agents in DSH for implementation-oriented tasks who accept the rhythm of “asking before acting”: for long sessions and multi-round iterative tasks, writing reviews into long-term memory can save repetitive communication; those who just want to work quietly and do not want any questioning interruptions will find the follow-up logic verbose.

A few notes:

• The plugin runs with the current DSH process permissions; you should check the source code and license (marked as MIT in the repository) before installing.
• After restarting DSH, the toggle and review index remain (state is in $DSH_HOME/dsh-thinking-review/, index in reviews.json, files in reviews/<id>.pdf); uninstalling does not delete the state file; to clear it, delete $DSH_HOME/dsh-thinking-review/state.json.
• Prompt priority is lowest (order 89950), so it will not override the project’s own AGENTS.md or system prompts.
• The review list only covers sessions after 1.1.0; old records are not backfilled (PDF generation is supplemented when opening the page).

Summary¶

One plugin solves two workflow problems: “Ask clearly before acting” and “Save experience after the session.” The toggle is enabled as needed, reviews are written item by item, and archives are searchable and deletable; it does not force a change in your usual usage. Directory page: https://www.skillhub.cn/plugins/HoaXQuill/dsh-thinking-review , Repository: https://github.com/HoaXQuill/dsh-thinking-review .