Preface¶
DSH’s Agent sessions need clear objectives to get work done, but these objectives often already lie in the requirement systems: TAPD requirements, Zentao tasks. The common practice is to open the requirement page, copy the title and description to DSH, and then dictate which branch to open and which workspace to use. Copying and pasting too much makes it easy to miss fields, and branch names are often just made up by the Agent on the fly. Below is an introduction to handsomeboy65/dsh-task-hub, which converges the workflow of “List assigned work → Manually fill in branch name → Dispatch to session” into a panel in the sidebar.
The plugin is maintained by handsomeboy65, categorized as “Workflow”, and can be found in the community plugin directory. It solves the manual handover between the task source and the Agent execution environment.
Positioning¶
In one sentence: Read requirements/tasks assigned to the current account from TAPD or Zentao, select a DSH workspace, manually fill in a branch name, and dispatch the task to an Agent to start working in a new session.
It does not handle task execution. After dispatching, the Agent inside the session handles the planning and implementation itself; the plugin only creates the session and fills in the input box draft, it does not send for you.
Core Features¶
Two task sources to choose from, switched via tabs at the top of the panel: Only data from one source is listed at a time, and only one source is active. Switching does not merge the two for display. Configuration such as address, credentials, and projects for each source is saved separately in settings.json. Switching back and forth won’t lose it.
Since it’s a choice between two, credentials won’t be mixed together: TAPD’s API account and password, and Zentao’s address and account are filled in separately; the key is written to DSH’s credentials, not into the plugin’s data file.
When dispatching, the plugin does four things in order: create a branch using git worktree add -b <branch-name> (or checkout -b in-place); establish (or reuse) a DSH workspace on the worktree or repository and create a session; write the requirement title, source link, parent requirement and associated applications, full body, references, work environment, and “Additional Requirements” into the new session’s input box draft; change the session title to <branch-name> · <title> and navigate to it. It does not send automatically.
Attachments are also attached to the draft. TAPD brings requirement attachments (including parent/root requirements) and description screenshots; Zentao reads the requirement or task details and downloads images and attachments in the body. These are just draft attachments attached to the input box; you paste them, edit them, and send.
When dispatching the same task repeatedly, if the previous session still exists, the plugin returns to that session directly; sent sessions also go to the original session, and unsent drafts can be restored by clicking “Open”.
The dispatch process has clear status feedback: the panel displays the branch, session status (Running / Idle / Pending Send / Session does not exist), and the running status refreshes every 8 seconds; a single project or product query failure only prompts on the panel and won’t crash the whole list.
Installation & Enablement¶
The installation command comes from the README:
dsh plugin --profile web add github:handsomeboy65/dsh-task-hub
After installation, restart dsh web, and the “Task Center” will appear in the sidebar. On the desktop, install it in Settings → Plugins within the app. After the package is published to npm, dsh plugin --profile web add dsh-task-hub is an equivalent syntax.
DSH 0.2.1 or later is required, Node version requires >=20.
First Time Configuration¶
Click “Settings” in the top right corner of the panel, first select the source at the top, then fill in the configuration for that source.
For the TAPD side, you need an authentication method (Token or API account + password), API account and password, assignee filter, project ID (TAPD project’s workspace_id, separated by commas if multiple, or select via “Fetch Projects”), and an optional Nick. Note that the API account comes from the personal settings of the TAPD Open Platform, not the login password.
For the Zentao side, you need the address (e.g., https://zentao.example.com, the plugin automatically appends /api.php/v1), account and password, scope (Product reads product requirements stories, Project reads tasks under each execution in the project), and product/project IDs (multi-select or comma-separated). Zentao does not have an “Assigned to me” interface, so the plugin needs to log in first to get a token, and then filter locally by the current account.
General configuration includes the default workspace (e.g., TMS2.0), baseline branch (leave empty to auto-detect origin/HEAD), isolated worktree (enabled by default, creating a separate worktree at .dsh-worktrees/<repo>-<branch> at the same level as the repo), and whether to hide completed items.
Dispatch Process¶
After configuration, the usage workflow is very direct:
- The panel lists items where “Assignee = Me” in the current source, sorted by recent modification, with filters for Unfinished / Finished / All. TAPD requirement “Application” field occupies a separate column before the ID; if there are multiple applications, they are stacked vertically as tags; if the current source has no Application field, the whole column is hidden.
- Click “Dispatch Agent” on a specific item.
- In the popup, confirm the target workspace (or manually enter repository path), Branch Name, whether to use worktree, baseline branch, and optional “Additional Requirements”.
- After confirmation, the plugin executes the branch creation, session creation, and draft writing process described above, then navigates to the new session. It will not send automatically: the task description and attachments are already in the input box; take a look, edit if needed, and press send yourself.
The branch name is the only thing that must be filled in manually throughout the process. The plugin requires a complete name (e.g., feature/order-export), it will not automatically concatenate issue_<requirement-number>, nor append suffixes; the branch name is validated using git check-ref-format --branch, and illegal names will cause an error.
“Additional Requirements” is not for manually writing out the entire task description. If left empty, the plugin automatically generates a description using the requirement title, description, attachments, images, and working conventions; the content you fill in is appended after ## Additional Requirements, it does not replace the requirement body.
Modification Notice: Settings are in ~/.dsh/task-hub/settings.json, dispatch records are in ~/.dsh/task-hub/state.json; records are distinguished by source:id (e.g., zentao:task-31), items with the same number in different systems will not overwrite each other, and old TAPD records remain compatible with their original IDs. In-place dispatch requires a clean workspace, otherwise it reports “Workspace has uncommitted changes”; if a worktree with the same name already exists but is on a different branch, a conflict is reported and it will not force a change.
Applicable Scenarios & Notes¶
Suitable for students who are already using DSH to write requirement implementations, have TAPD or Zentao as task sources, and want the developer themselves to decide the branch name. It fits the rhythm of “processing one to-do item at a time”: select item, fill branch, send session; it is not suitable for scenarios requiring batch linkage or writing back to the source system.
At the same time, the boundaries should be clear: TAPD only connects to requirements, excluding tasks/bugs; Zentao reads requirements by product or tasks by project execution, excluding bugs. The plugin does not write back to the source system, does not change status, and does not write comments; it also does not replace the Agent in making the execution plan.
Security Tip: The plugin runs with the permissions of the current DSH process, capable of reading and writing its data files, and creating worktrees and sessions. It is recommended to open the GitHub repository to review the source code (MIT license) before installing, confirm that modules like tapd.js, zentao.js, checkout.js, dispatch.js under lib/ are doing what you expect, and then decide whether to hand over TAPD/Zentao credentials to it.
When verifying code changes, you can use the built-in tests of the repository: npm test, covering pure functions, git workflows, dispatch, client rendering, and dual-source adaptation. Note that the installed bundle requires restarting DSH to load new JS versions (the first load during installation can use HMR).
Conclusion¶
What dsh-task-hub does is not complicated: pull requirements and tasks assigned to you from TAPD/Zentao to the sidebar, after filling in the workspace and branch name, pour the task description and attachments into the input box of a DSH session, and let you confirm the send. It removes the repetitive manual handover from “reading requirements, opening branches, starting work”, yet does not snatch the send step for the developer, consistent with the positioning he declared when maintaining it.
Directory page: https://www.skillhub.cn/plugins/handsomeboy65/dsh-task-hub
Repository: https://github.com/handsomeboy65/dsh-task-hub
