Introduction

The plugin ecosystem of DeepSeek Harness (DSH) is developing rapidly. In agent development, a common pain point is fragmented information in chat history and the lack of structured task state management. Instead of tracking requirements one by one in chat, it is better to turn them into a structured pipeline. This is where the “Boss Task Board” comes in.

Plugin Positioning

This is a task board plugin running in DSH, maintained by user lihang-lh. It aims to upgrade “chat bubbles” into a “task pipeline,” allowing you to focus only on publishing and acceptance in the AI era, while planning, clarification, development, and review are all completed by subagents dynamically scheduled by the plugin.

Core Features

The plugin provides end-to-end management capabilities from requirement publishing to final acceptance:

Task Pipeline (Seven States)

The task state machine contains seven nodes, each corresponding to different agents and operations:
1. Pending Claim (todo): The task has been registered and is waiting for the plugin to claim it or queue it for execution.
2. Pending Clarification (clarify): The planning agent found that the requirement is unclear, produced a list of questions, and is waiting for human answers.
3. Pending Confirmation (confirm): The planning agent has produced a plan and is waiting for human confirmation (only appears when “Auto Confirm” is disabled).
4. In Development (develop): The development agent is executing the task.
5. Paused (paused): Entered after manual pause; can be resumed or re-edited.
6. Under Review (review): Entered after automatic review passes (zero outstanding issues); waiting for human acceptance.
7. Completed (done): Human acceptance passed.

Automatic Historical Session Distillation

When publishing a task, the plugin uses sessionQuery.searchSessions to perform full-text search across all historical sessions. Old sessions with high relevance are automatically attached to the task, and the panel provides checkboxes. Before execution, development/planning agents read this context to enable “continuing from the previous session.”

Phased Subagent Scheduling

The plugin internally schedules subagents in four phases:
* Planning agent: Reads historical sessions and produces an implementation plan (plan, steps, risks, questions).
* Clarification agent: Produces a list of questions when the requirement is unclear.
* Development agent: Implements according to the plan, requires verifiable evidence (such as checking items in tasks.md), and handles screenshots.
* Review agent: Self-checks against acceptance criteria and the task list; any outstanding issue means the review fails.

Auto Readers

Each phase has a corresponding “auto reader” to drive transitions:
* Claim reader: Starts planning when the task is in pending claim and there is an available slot.
* Development reader: Starts development after the plan is confirmed.
* Review reader: Starts after development is completed; if there are zero issues, it moves to review; if there are issues, it sends the task back to development (up to 3 rounds).
* Recovery reader: Inspects every 20 seconds and marks the task as “re-executable” when a sub-session is offline.

Native App Screenshot Support

Supports physical device or emulator screenshots for iOS and Android. Development/review agents automatically invoke the corresponding tools based on the repository type:
* Android: adb exec-out screencap
* iOS Simulator: xcrun simctl io
* iOS Physical Device: idb screenshot / idevicescreenshot
If a device is not connected or a tool is missing, the agent reports it accurately and marks the task as “Device Connection Required.”

OpenSpec Artifact Generation

When the plan is finalized, the plugin generates standardized OpenSpec artifacts in the <repoPath>/specs/proposals/<task id>/ directory of the target repository:
* proposal.md: Background, solution, risks, and acceptance method.
* tasks.md: Numbered task list; the development agent checks items one by one.

Panel UI

  • Entry point: A new button at the bottom of the DSH sidebar (above Settings).
  • Interaction: A right-side floating panel, with draggable width (400-1100px).
  • Information display: Each tab shows counts; cards display status dots, conclusion badges, progress bars, review reports, and screenshot thumbnails.
  • Session management: Clicking a card can navigate to the publishing session, planning session, development session, or related historical session.

Typical Usage

  1. Publish a task: Click “Publish New Task” in the panel, and fill in the title, description, and acceptance criteria. The plugin automatically scans related historical sessions; select the relevant ones and publish.
  2. Handle clarification questions: When the task enters the “Pending Clarification” state, expand the card to view the questions raised by the planning agent and answer them one by one. After the answers are complete, the planning agent re-finalizes the plan based on the answers.
  3. Accept results: When the task enters the “Under Review” state, the panel displays a “Ready for Acceptance” or “Has Issues” badge. Expand the card to view the review report, list of outstanding issues, and acceptance screenshots.
  4. Manage task: In any stage other than “Completed,” you can click “Pause” to move it to the “Paused” tab; you can also click “Re-edit” to modify the requirement, which clears the previous plan.

Limitations and Notes

  1. Execution mode: The current development stage runs in serial mode; by default, only one development task runs at a time, while others queue in “Pending Claim.”
  2. Publishing method: The task_publish model tool has not been integrated yet; currently, tasks can only be published through the panel.
  3. Notification method: Currently only panel badges and counts are used; Feishu or email push is not yet supported.
  4. Historical session retrieval: Current distillation supports only keyword/full-text search; introducing LLM semantic summarization is planned later.
  5. Native dependencies: Native app screenshot support depends on tools such as adb, xcrun, and idb, as well as device connections.

The plugin runs with the permissions of the current DSH process. It is recommended to check the source code and license before installation.