Preface¶

When developing with Agents, a task worth doing separately often pops up during discussion: a bug to verify, a regression to fix, a small task to offload. It wasn’t appropriate to interrupt the main thread at the time, but if not recorded, it’s gone when the window is closed. Delegating it to the model to record consumes a turn, and switching away to write it elsewhere easily breaks context.

Glean downgrades this to a pure local write: seeing a candidate in the assistant’s reply, clicking or typing a command, and it enters the candidate pool file; the marking process doesn’t wake the model, doesn’t consume tokens, and doesn’t interrupt the current topic. Once enough candidates are gathered, open the task board to decide which ones to actually dispatch.

Glean is maintained by Morange1, a client-side plugin. The author is Morange1 and can be found on the directory page at skillhub.cn. The meaning of the plugin name is “gleaning the lost ears of grain in the field after harvest.”

What is this?¶

One-sentence definition: Glean is a workspace-level candidate task board that captures candidate items from conversations, saves them to tasks/candidates.json, and provides a panel grouped by sessions to view, enter, complete, and delete candidates, as well as view dispatched tasks.

It doesn’t solve the task scheduling problem, but rather the problem of “how to temporarily store secondary items that appear in conversations.” Candidates and dispatched tasks are two separate sets of data: candidates are in tasks/candidates.json, and dispatched tasks are in tasks/agents.json, with no cross-referencing.

Core Features¶

Mark candidates without waking the model. The marking action is performed by the host, leaving only command/run / command/done in the session log, without dispatching, interrupting, or spending tokens.

Two operation entry points. Every assistant reply has a bookmark button in the action row; clicking writes immediately. You can also type /candidate in the input box. The button actually executes /candidate --id=<message ID>, so the one marked is definitely the one you clicked, not the latest one. The command can include a note: /candidate this is worth doing separately.

Candidate list is read-only. /candidates prints the current candidate pool, up to 20 items; exceeding this prompts the remaining count; the first 80 characters of each summary are shown, without reading the original text.

Write receipts come in three types:

Marked as candidate #3 · Round 12 · Written to tasks/candidates.json
Candidate #3 (Round 12) already exists.
No assistant messages available to mark.

Task Board Panel. A new Task Board entry has been added to the sidebar, displaying two columns per workspace: the candidate area is grouped by main sessions, collapsible, and each item can be “Enter / Complete / Delete”; the dispatched area reads from tasks/agents.json, is collapsible, star-able, and deletable, with starred items pinned to the top.

Interaction Semantics. “Enter” changes the candidate to entered, and the host uses agent.followup() to wake the main agent to write the task plan and dispatch; “Complete” changes it to done; “Delete” changes it to dropped; deleting a task changes it to archived, with the ledger retained. Group titles are written to tasks/sessions.json.

Data comes from the plugin’s own routes, none of which are cached or throw errors:

GET  /candidate-pool/data?root=…
POST /candidate-pool/enter
POST /candidate-pool/update
POST /candidate-pool/agent
POST /candidate-pool/session

Reason for not using the workspaceFiles Remote: The task board is a root-level panel with no session binding, whereas that Remote requires a parsable session.

Installation and Enablement¶

The plugin is delivered as a workspace directory, installed via the plugin manager’s install_bundle; do not manually write dsh plugin add:

target: <absolute path>/plugins/candidate-pool

After installation, it can be used in the current session. Changes on the host side require a restart to load the new generation modules, while a page refresh on the client side suffices.

Dependencies are divided into two layers. Host services: commands, sessions, workingDirectory, webServer. Client services: slots, remote, remote.commands, locale; client slots conversation.chat.assistant-actions, sidebar.panellist, main, provided respectively by @deepseek-ai/dsh-client-ui-chat, dsh-client-ui-sidebar, dsh-client-ui-layout. The plugin only depends on public Cordis services and slots, and does not read or write the DOM, styles, or components of other plugins.

Typical Usage¶

1. While chatting, you discover a task worth doing separately; without interrupting the current topic, click the bookmark icon in the assistant’s reply action row, and the candidate is written to tasks/candidates.json.

2. When you need to add a note, use the command form:

/candidate this is worth doing separately

3. View the current candidate pool:

/candidates

Output looks like:

1 candidate
#1 · Round 17 · 11-03 22:07 · Note: can have them all
   Plugin finished, installed into current profile…
File: tasks/candidates.json

4. When you decide to actually do it, open the sidebar Task Board, and click “Enter” in the candidate area. The candidate changes to entered, and the host wakes the main agent to write the task plan and dispatch it. Afterward, track status in the dispatched area: Delivered uses brand color, Adopted uses green, In Progress uses yellow, Archived uses gray.

Applicable Scenarios and Notes¶

Suitable for these use cases: accumulating to-dos in long conversations, registering secondary items appearing in discussions before dispatching, and wanting to see the candidate list before deciding on forwarding. It is also suitable for those who don’t want to interrupt the model just to record a to-do.

There are several limitations you need to know before using.

• The session needs write permissions to the workspace; under a read-only sandbox, the command will return a write failure.
• This version only has marking and read-only board; dispatch, delivery, and archiving are still manually completed by the main task and written to the ledger.
• The task board does not display subtask conversations and does not auto-refresh; you need to click “Refresh” or switch panels.
• Summaries are truncated at 200 characters; if you need the original text, read the session log by sessionId + seq, though it may be unreadable if that message has been compressed.
• Search grouping currently only shows short IDs; session titles are projections and reading access is not yet open.

Also note that the plugin runs with the permissions of the current DSH process and can read and write workspace files. Before installation, you should check the source code and license; this plugin’s license is MIT. Current version 0.6.0, directory page shows 0 stars, a small-scale project maintained by a person.

Conclusion¶

The value of Glean lies not in making a task manager, but in making the “mark candidate” step light enough: without waking the model, without consuming tokens, without interrupting discussion, candidates are saved to disk first, and whether to dispatch is decided by you later. Before using it, you just need to confirm the workspace has write permissions and accept the boundary of “dispatch still requires manual ledger writing by the main task.”

Directory Page: https://www.skillhub.cn/plugins/Morange1/Glean-

Source Code: https://github.com/Morange1/Glean-