dsh-plugin-project-management

A DeepSeek Harness plugin that interviews the user about a project, generates a project timeline / Gantt chart, and exports it as Word or Excel.

The agent owns the loop: it runs a structured interview (via the project-interview skill), decomposes features into tasks, and uses five tools to validate, schedule, adjust, persist, and export. The scheduling math is deterministic. The project (definition + timeline) is persisted to a workspace project file (data/project_management/project_data.json) so it survives across sessions, and the plugin reminds the agent about an existing timeline on session resume.

Tools

Skill

• project-interview — the conversational interview protocol: features → priorities → timeline/milestones → agent budget per duration (hours / cost / agents / custom, with a period) → constraints.

Install

Build the plugin (server + browser bundle), then load it with a Cordis overlay patch:

npm install
npm run build       # tsc server → dist/, esbuild client → lib/client.js

From GitHub

The prepare script builds both halves automatically, so GitHub installs work without committing dist//lib/ (they are gitignored). Install the plugin into the web profile directly from GitHub:

dsh plugin --profile web add github:Luke-Yong/dsh-plugin-project-management

This forwards pnpm add github:Luke-Yong/dsh-plugin-project-management inside the profile directory. Equivalent to installing the package into a DeepSeek Harness checkout manually:

npm install github:Luke-Yong/dsh-plugin-project-management

./package.json is exported for tooling that needs the dsh.client manifest.

From a DeepSeek Harness checkout:

pnpm dsh web --patch /absolute/path/to/dsh-plugin-project-management/cordis.yml

The plugin package must be resolvable from the config tree's baseUrl — install or pnpm link it into the harness checkout (it is a dependency of the cordis.yml package, per the client-modules resolution rule).

Open http://127.0.0.1:3080 and ask, for example:

Plan a timeline for my mobile app and export it as both Word and Excel.

Web UI

The plugin ships a browser half with two surfaces:

• A Project tab in the conversation header's view tabs (the conversation.view slot — the same mechanism ui-trajectory uses). Note: the view-tab ring only appears once the session is active (≥ 1 turn).
• A compact project dock inside the composer stack (conversation.input.dock) that renders even for blank sessions and auto-appears when a project exists, so project management is reachable before the tabs show.

Selecting the tab (or reading the dock) shows: project name, description, and last-updated time; timeline span, task count, and feasibility; phases, critical path, milestones, and open conflicts; the agent budget model.

The pane reads the saved project state for the current session from /plugins/project-management/state (server resolves the session cwd — session header → workspace registry → process cwd — and reads data/project_management/project_data.json). No harness patch is required — both surfaces work with the stock web app.

Flow

1. The agent interviews you (features, deadline, milestones, agent budget per duration).
2. It calls pm_project_define to lock in and persist the definition.
3. It decomposes features into tasks and calls pm_timeline_generate.
4. It reviews feasibility with you and adjusts via pm_timeline_update.
5. It exports with pm_timeline_export (format: docx | xlsx).

Persistence & session resume

• The definition and timeline are saved to <workspace>/data/project_management/project_data.json in the project-plan schema used by templates/gantt.html (project, tiers, phases, tasks, milestones, sprints — plus a _dsh block for plugin round-trip state). Layout follows the Project-Journey Planner example: data/project_management/project_data.json consumed by templates/gantt.html.
• On a new session in the same workspace, the plugin injects a reminder into the model context when a timeline exists, telling the agent about the saved plan and its conflicts; the agent then calls pm_project_load to continue.
• Writes are atomic (temp file + rename). A legacy .dsh-pm/project.json is read as a fallback for backward compatibility.

Notes / MVP limitations

• A single project per workspace.

Roadmap

• Custom Web UI Gantt view via presentCall / presentResult.
• Multi-project and live agent-budget tracking.