Workbench development: six-step quickstart

Version: 2026-10-08 · For full rules, see the Workbench Development Standard; for listing, see the Workbench Market Acceptance Standard.

  1. Confirm requirements: From the user's current request and confirmed context, identify the business scenario, target users, and core steps to complete one task. Generic development instructions, a directory name, and existing code do not establish the user's intent. If any item is missing, ask one combined question and wait before designing business features.
  2. Inspect the project: Check pwd, directory contents, git status --short if this is a Git repository, existing scripts, package manager, and Desktop version. Preserve uncommitted changes.
  3. Define the smallest business flow and layout: Identify the entry point, primary action, completion state, and failure recovery. Choose a standard split or customFrame, and define the entry point when there is no session. Compact tools that accompany a conversation suit a split; consider a full-page layout when a report, dashboard, or wide table is the main task.
  4. Implement: Build the plugin package and business panel under Section 3 of the development standard. Follow Sections 4–7 for the session, workspace, and UI capabilities actually used. Make the business area responsive to its own container width, not only the window width.
  5. Verify the package: Run pnpm pack. Confirm the .tgz contains the declared server and client entries and cordis.patch.yml, and excludes credentials and user data.
  6. Install and test locally: Under Section 3.6, check which local installation method the current Desktop supports, install the package, and complete the required restart. Open it from “Installed workbenches” and the sidebar, then record actual results under Section 8. If installation is unavailable, deliver the verified package and list every untested item.

When developing inside the target DSH Desktop: Do not close or restart DSH Desktop or Harness yourself, and do not use process probes such as ps or pgrep to manage the restart. Ask the user to fully quit and reopen DSH Desktop. After the user confirms it has reopened, verify loading and UI; keep these checks pending until then. An agent outside the target app may follow the normal restart process.

UI acceptance: Check first entry without a session, an owned session, expanded and collapsed sidebar, and a narrow window. For a standard split, check the host generic guidance beside the business panel; for customFrame, provide your own first-use action. Use realistic Chinese and English text; prevent single-character vertical wrapping, clipped controls, and page-wide horizontal overflow. Preserve host shared entrances.

Empty-directory example: The user only pasted Desktop's generic development instructions; the directory is empty and there is no business goal. The agent's next step is one combined question: “Who is this workbench for, what business scenario should it address, and what are the core steps from entry to task completion?” While waiting, the agent may run pwd, ls, git status, or check the Desktop version. Until the user answers, do not create package.json, business code, or UI, and do not build, install, or submit anything.