Preface¶

When doing longer development with DeepSeek Harness (dsh), three types of content quickly accumulate in the chat session: offhand follow-up ideas, mid-stream finalized technology selections, and a list of todos written during agent planning. By default, these only exist within the current conversation. If you switch to a new session and ask “Why did we choose Option A last time” or “Did that note I jotted down ever get implemented”, you usually have to dig through history or just ask again from scratch.

The design of dsh is “everything is a plugin”: models, tools, sessions, storage, and UI can all be mounted or replaced. There is a category of workflow plugins in the community repository that specifically fill the task and collaboration layer. dsh-track targets a more internal layer: instead of syncing tasks to external Linear/Jira, it structures ideas, decisions, and tasks into structured data within the harness itself, and adds a panel to the web UI that can jump back to the source conversation.

This article is collated after cross-checking with the community repository detail page, GitHub repository README, original protocol skill, npm package information, and the official DeepSeek Harness repository: what it is, what installation commands to use, and how to use it daily. This plugin is maintained by fakechris, and is hosted on the independent community site DeepSeek Harness Plugin Library. It has no official affiliation with DeepSeek / HyperMind and should not be treated as an official app store.

What is it¶

dsh-track is also called Track Bridge in the repository, and it is an embedded task management engine for DeepSeek Harness. It is categorized under “Workflow and Automation”, primarily written in TypeScript, with the BSD-3-Clause license (consistent across the repository page, GitHub license field, repository LICENSE file, and skill metadata). As of 2026-08-18, the GitHub repository fakechris/dsh-track has 6 stars; the npm package name is @fakechris/dsh-track, and the current version is 0.5.0.

It solves the problem of: how to turn the ideas, irreversible decisions, and task progress generated during agent execution into queryable, collapsible data that can trace back to the original prompt, without connecting to external project management services. The README clearly states that all data stays within the harness: decision points / todos use session events (which can be replayed), while Capture / Issue / Decision / Usage use ctx.storage KV (independent across sessions). The data shape is modeled to be compatible with Linear for easy future migration, but it has zero external dependencies at runtime.

The architecture is a fat skill + thin harness: the logic to decide “whether to report a decision point or upgrade an idea into a task” is written in skills/dsh-track/SKILL.md; the plugin side only registers tools, subscribes to events, connects storage and HTTP APIs, and does not make such judgments on its own. In package.json, the client injection declaration sets platform to web, and the panel is attached to the right sidebar of the web session UI.

Core Features¶

Capture Wall¶

The entry tool is capture_thought(content, tags?). When the user mentions off-topic thoughts, future plans, or half-formed ideas related to the current work, the agent will save them to the capture wall according to the protocol skill without interrupting the ongoing work. The todo_write from the planning phase will also be automatically captured, with each entry carrying the user’s request at that time as motivational context, avoiding ending up with a list of items whose original purpose is no longer clear afterwards.

You can manually input captures on the panel, paginate, delete with two-step confirmation, and one-click convert a capture into a task. Starting from v0.3.0, createCapture has a unified gate (using session persistence markers + content hash as fallback), so the same entry will not be captured again after a restart.

Decision Ledger¶

When encountering irreversible, risky, value-based, scope, or acceptance-related decisions, the agent should first call report_decision_point, providing options, its own preference, and reasoning, to let the user make a light-weight decision. After the user responds, you must call track_respond_decision(decision_id, choice, rationale?) to save the decision; the original skill text is strict: not saving the decision means the question was never asked. When the user says “hold off / skip”, pass dismissed as the choice. You can query history with track_list_decisions filtered by pending / answered / dismissed.

The protocol skill also defines boundaries: do not repeatedly report variable naming, function splitting, when the user has already said “you decide”, or when a similar decision has already been accepted. Long tasks default to a maximum of 5 decision points.

Evidence-Driven Task Lifecycle¶

Tasks are stored in a Linear-compatible shape. The typical workflow is:

track_create_issue → track_attach_issue → Execution evidence in the session is automatically logged to the task → track_update_issue_state / track_issue_evidence

track_attach_issue(issue_id) declares that the current session is working on a specific task. Afterwards, todo completions, round results, and tool errors will be logged to the evidence ledger, and the state machine infers progress based on this. The key constraint: done and canceled will not be automatically achieved; you must confirm with the user and change the state with confirmed_by_user=true. Starting from v0.5.0, the panel adds “Complete / Cancel” (two-step confirmation) and bulk mode to task cards.

v0.4.0 also added lifecycle sweep: tasks with no progress for a long time will float to the “pending confirmation” section; near-duplicate captures can be merged based on configurable token similarity; canceled proposals can be automatically confirmed after the grace period expires. These are behaviors recorded in the repository changelog, and the configuration entry is in the ⚙ menu of the Track panel or at /api/track/config.

History Sync & Usage Ledger¶

track_sync_history folds past workspace sessions into epic / issue candidates. By default dry_run=true, only viewing the list, and writing back only after confirmation. The skill recommends engine: 'v2' (segment + intent + synthesize), with since defaulting to 7 days.

LLM calls initiated by the track engine itself are billed separately. Use track_usage to check request counts, various token types, time spent, and estimated costs, to avoid mixing them with the usage of business conversations.

Web Panel¶

The panel is a pure DOM injection with no front-end framework dependencies. The right sidebar displays both the capture wall and task wall (prioritizing in-progress tasks); each record can be clicked with “↩ Conversation” to switch to the left source session, scroll to the corresponding history, and highlight the original user prompt. When collapsed, there is a ◆ floating button in the bottom right corner, and you can also access the Track tab in the session tab bar. The panel refreshes lightly every ~20 seconds, and its width is draggable.

Installation and Enablement¶

The installation commands given on the community repository page are as follows, run them in the DeepSeek Harness terminal:

dsh plugin add github:fakechris/dsh-track

For reproducible installations, the repository page recommends pinning the commit hash:

dsh plugin add github:fakechris/dsh-track#<commit>

The plugin declares support for web clients. The repository README recommends using the released version of dsh and explicitly specifying the web profile; you can also install it this way once the npm package is published:

npx -p @deepseek-ai/dsh dsh plugin --profile web add @fakechris/dsh-track

The protocol skill will not automatically be added to the default scan directory just by installing the plugin. The README requires copying it to your local machine:

mkdir -p ~/.dsh/skills && cp -r skills/dsh-track ~/.dsh/skills/
dsh web

Verification method: Open the panel in your browser (either the ◆ button in the bottom right corner or the Track tab in the session tab bar). You will see “Capture Thoughts” and “Tasks” columns if the installation is successful.

There is one documentation item that needs cross-checking: the README and cordis.patch.yml comments still mention the alternative git source github:dsh-external/dsh-track. Visiting this address will redirect to the current public repository fakechris/dsh-track (same repository ID). Use the installation command github:fakechris/dsh-track as specified on the repository page, do not construct the URL manually using the old organization name.

The repository page also reminds users: the plugin runs with the permissions of the current dsh process, and may execute code during installation. You should inspect the source code repository and license before installing.

Typical Usage¶

The following workflow comes from the “Core Workflow” section of the repository README and skills/dsh-track/SKILL.md, and is not a fabricated example.

1. Capture ideas. When the user casually says “I’ll add documentation next time” while modifying an interface, the agent calls capture_thought and continues the current task. You can also manually add an entry to the capture wall via the panel. When explicit follow-through is required, use track_create_issue (or “Convert to Task” in the panel) to fill in the title, description, acceptance criteria, and priority; call track_list_issues before creating to avoid duplicates.

2. Report decision points. The positive examples given by the skill include: Framework A or B? Can API keys be stored locally? Does writing documentation count as scope creep? What level of completion counts as done? Do we need to modify the database schema? After reporting, look for the first line of the return text Decision recorded: dec_xxx. After the user makes a selection, call track_respond_decision.

3. Advance tasks. Call track_attach_issue when starting work on an issue (during the planning phase or when writing the first todo). Use track_issue_evidence mid-work to check the inferred status and evidence. When the task appears to be completed, first ask the user “Would you like to mark it as done?”, and after approval, call track_update_issue_state(..., confirmed_by_user=true). When evidence shows “Pending confirmation”, proactively ask the user instead of finalizing the state on your own.

4. Organize history. When the user says “Sync my recent work to Track”, first run track_sync_history (default dry-run) to review the candidates, then run it with dry_run=false to write them back. Any capture or task on the panel can jump back to the original prompt.

Common tool reference:

Applicable Scenarios and Notes¶

It is suitable for users who are already using the dsh web UI, have many sessions, and need to keep track of what was said as searchable records: individuals using the harness for medium-to-long-term transformations, who want a ledger for their decisions, and do not want to set up a separate Linear account. It is not a general-purpose kanban, nor does it replace the assignment / acceptance flow in team collaboration; there are other community plugins in the same category such as kanban and multi-agent orchestration, with different positioning.

Pay attention to these points before using:

1. Client platform is web. package.json sets dsh.client.platform to web, and the verification steps in the README also use the browser panel. Do not assume it provides the same UI in headless sessions.
2. Installing the plugin alone is not enough. The decision discipline is in the skill, you need to copy it to ~/.dsh/skills/ as per the README for the agent to call the tools correctly based on “what should be asked and what should not”.
3. done / canceled must be confirmed by a human. The system can propose a state change, but it will not mark tasks as completed automatically.
4. History sync defaults to dry-run. Candidates will not be written as issues without confirmation.
5. Do not write business data into custom session events. The README clearly states: starting 2026-08-11, the harness will reject reading entire logs for unknown event types; observe sessions only through the official event stream, read-only.
6. Permissions and source. The plugin runs with the permissions of the current dsh process. The repository is hosted on a community site, not an official DeepSeek store; before installing, double-check the GitHub repository, BSD-3-Clause license, and recent commits. For reproducible environments, use the #commit syntax from the repository page to pin the hash.

Summary¶

dsh-track aggregates the scattered ideas, decisions, and todos from DeepSeek Harness sessions into a capture wall, decision ledger, and Linear-shaped tasks within the harness itself, and provides a web right sidebar panel that can jump back to the original prompt. Data does not rely on external project management services; completions and cancellations still require human confirmation.

Repository page: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-track/

GitHub: https://github.com/fakechris/dsh-track

npm: https://www.npmjs.com/package/@fakechris/dsh-track