Step 1: check the tools and model connection

Open a prepared Linux/POSIX shell first (on Windows, use an existing WSL environment). Do not paste these commands into PowerShell. Run the checks before cloning or installing anything; they only print versions.

In your chosen environment, run these checks separately:

node -v pnpm -v git --version python3 --version tmux -V gh --version dsh --version

The setup guide lists Node.js 22.19+ or 24+, Git 2.32+, Python 3.8+, GitHub CLI 2.48+, pnpm, and tmux. DSH must satisfy the checkout's engines.dsh requirement. Use that checkout's package.json as the compatibility reference rather than assuming the newest release is interchangeable.

Each command should print a version. If one reports “command not found,” put that item into the installation plan and resolve it before moving on. Tools already present do not need a second installation.

DSH is the workbench foundation. Superagent is the work package loaded on top of it. DSH also needs a usable model-provider configuration. Open-source code does not make model calls free; cost and available quota depend on the service and account you choose.

Get one ordinary model conversation working in DSH before connecting GitHub. That separates “the model cannot answer” from “the repository request never arrived.”

An assistant fixes a configuration function and says it now handles empty strings. You bring the change back into the project. One caller still uses the old parameter name. The program fails again.

“Finished,” “changed the files,” and “verified the result” are three different things. When you keep asking where the patch is, what ran, and what needs your attention, you become the assistant's delivery service.

DeepSeek's public dsh-superagent-prototype moves that handoff into GitHub. An authorized request becomes a work item. The agent handles it in its own session and directory, then replies in the original discussion with a result, such as a pull request.

The useful question is what kind of job you can hand over and inspect afterward. Let's start with a tiny README correction, then connect the actual tool. A pull request, or PR, is a proposed change you can review before merging it into your project.

First, make a task card with two ordinary chats

You can learn the handoff before installing anything. Open two ordinary AI conversations. In window A, paste this complete brief:

Organize a task; do not make the change. Original material: the README says, “Run npm run demo; it displays hello.” The agreed behavior is that npm run demo displays Hello, world! Write a task card with the goal, allowed changes, and acceptance check. Only README may change. Do not change the program, scripts, or dependencies.

Give the resulting card, along with the original material, to window B:

Deliver the before-and-after README text for this task. Explain whether each constraint is satisfied. Use only the supplied material. If you have no terminal, do not claim to have executed a command.

The desired edit is easy to inspect: replace the README's description of hello with Hello, world! Keep the program and launch command unchanged. Return B's answer to A and ask it to compare the result against the original constraints.

If B “helpfully” changes the launch command, you have a specific reason to send the work back. You do not need another round of guessing whether it understood you.

Your wording may differ from the example. Check the scope and expected result, rather than an exact match to an AI response. This exercise produces text, not evidence that a program ran. A second conversation can also miss an error.

You have just practiced writing a small job with a visible finish line. That is the part worth carrying into a repository agent. The exercise does not install Superagent or imply that it includes a separate reviewer that guarantees correctness.

Picture a staffed workbench beside your repository

The prototype has several responsibilities that are easier to understand as a workbench:

  1. GitHub delivers the message. The agent checks its account's notifications.
  2. Policy checks the visitor list. The request must come through an allowed source and satisfy authorization rules.
  3. A Ticket records the job. There is somewhere to track the work beyond one conversational reply.
  4. A session and directory hold the work. The agent can handle the task separately from another task's conversation.
  5. The original discussion receives the result. A web panel helps surface what needs a person.

This is a research prototype for one GitHub repository, packaged for DeepSeek Harness, or DSH. The repository explicitly distinguishes it from an official DeepSeek product and from the team's internal implementation. Some ideas in the accompanying design article are future directions, rather than implemented features.

That distinction helps set the deployment decision. You are configuring research software with accounts, a runtime, and operating responsibilities. You are not simply enabling a feature inside the consumer DeepSeek chat app.

Which jobs belong on that workbench?

Choose work whose result you can inspect without reconstructing the whole project.

A documentation correction is a useful first job. Identify the incorrect sentence, supply the intended text, and limit the edit to one file. Acceptance is a small diff you can read.

A missing boundary test is a sensible next job when the repository already has a test framework. Name the function and cases, preserve its current behavior, and specify the test command. The reviewer checks both the assertions and the execution evidence.

A narrow bug fix needs a reproducer: input, actual output, and expected output. Ask for the smallest relevant patch and evidence that the reproducer and related tests now behave as intended.

A Feishu request can provide another entrance once configured. The task still needs a clear scope and an inspectable result. Moving the request into chat does not remove the repository, runtime, or model setup.

These are candidate uses, not guaranteed outcomes. A request can end in a clarification rather than a PR. The first useful milestone is a small change that arrives where you can review it.

Choose the machine before choosing the first task

There is an important difference between a separate work directory and a security boundary.

The deployment guide says the managed worker and router presets run with danger-full-access, as the operating-system user running the service. They can execute programs by path and read that user's home directory. Account wrappers select credentials; they do not isolate a process.

Think of a labeled key box on the desk. It helps the worker pick the robot's GitHub key. It does not stop the worker opening other drawers that the same system user can access.

For an initial deployment, use a dedicated OS account or an isolated practice environment containing only the agent's credentials and practice repository. A separate DSH profile and one-repository scope organize the work, but do not make private files inaccessible.

The commands below use a POSIX shell. On Windows, use an already prepared WSL Linux environment for this route; do not paste them directly into PowerShell. The tooling uses components such as tmux, shell scripts, and Python's fcntl. Preparing WSL itself is a separate system setup task.

Keep two locations distinct: the checkout containing the Superagent tool, and the practice repository you want it to maintain. Installing the tool into one directory does not tell it where to prepare a copy of the other project.

Step 2: use the repository's guided setup

Clone the tool repository, then open that directory in your existing coding assistant:

git clone https://github.com/deepseek-ai/dsh-superagent-prototype.git cd dsh-superagent-prototype

Ask the assistant to follow SETUP.md with you. Add your own constraints: GitHub only, a practice repository, only your account may assign work, and no automatic merging. Request the full installation plan before execution, and complete credential entry locally.

The official setup process gathers answers one question at a time and presents a combined plan for confirmation. Have these details ready:

  • The practice repository's owner/name.
  • The agent's GitHub username.
  • Your username for the allowlist.
  • The absolute path to the practice checkout.
  • The commit author identity.
  • Your choice to leave auto-merge disabled.

The agent needs a dedicated GitHub user account, invited to the practice repository with write access. The current deployment route relies on account notifications, so a GitHub App is not a drop-in replacement here. The documented target is github.com, rather than GitHub Enterprise Server.

This is also where a chat-only alternative remains reasonable. If you only need help rewriting a paragraph once, the two-window exercise may be enough. A resident worker becomes more useful when recurring repository jobs justify maintaining the environment and accounts.

Step 3: keep the robot's GitHub login separate

The deployment guide uses an independent GitHub CLI entry point. It selects a separate configuration directory for the agent's login.

In the dedicated environment, create the wrapper below. If a file with that name already exists, inspect it before replacing anything.

mkdir -p ~/.local/bin cat > ~/.local/bin/gh-agent <<'EOF' #!/bin/sh GH_CONFIG_DIR="$HOME/.config/gh-agent" exec gh "$@" EOF chmod +x ~/.local/bin/gh-agent ~/.local/bin/gh-agent auth login ~/.local/bin/gh-agent api user --jq .login

Choose the robot's account during login. The last command should return its username. If it returns your personal username, resolve the mismatch before configuring the source.

Keep tokens out of the assistant conversation. The wrapper is the labeled key box: it chooses the right credentials, while the dedicated OS account supplies the stronger separation from your everyday environment.

Step 4: distinguish installation, configuration, and startup

Your setup assistant should plan these steps against the official deployment guide. For a new environment without an existing superagent profile, the installation sequence is:

npm install -g @deepseek-ai/dsh@0.2.1-rc.3 pnpm install pnpm build dsh superagent --from-default-profile web --dump-config > /dev/null dsh plugin --profile superagent add "link:$PWD"

Run these in the tool repository's root. The first line is the DSH version pinned in the deployment instructions; check compatibility if DSH is already installed.

The profile-creation command is for a fresh installation. Recreating an existing profile replaces its configuration. Existing operators should follow the documented upgrade route and preserve their configuration.

A successful build does not mean the agent can accept work yet. Machine settings come from examples/profile.cordis.patch.yml, including an absolute stateDir. On a new installation, use the example through the guided procedure. For existing settings, make a targeted edit rather than replacing the file wholesale.

Start the service and inspect its status:

scripts/dsh-superagent start scripts/dsh-superagent status

Open the address in the startup output and select Superagent in the sidebar. The default plan uses 127.0.0.1:3082; your actual configuration determines the address.

Complete four groups in the panel:

  • Sources: supply owner/name for the practice repository and the absolute path to the robot's gh wrapper.
  • Policy: add your GitHub login to the allowed list. An empty list will not produce a ticket.
  • Execution: set the worker-directory root and the prepare command. Have the setup assistant construct the worktree command from your real checkout path.
  • Prompts: configure the commit identity and bot disclosure, while retaining human merging.

These are the cables that connect the workbench. A different model cannot compensate for a missing source login or an unconfigured working directory.

If saving a setting requests a restart, wait for the service to return. After fixing an external login, use Check again where offered to recheck it.

Step 5: send one real job

From your allowlisted account, add a new Issue comment in the practice repository:

@<agent-login> Please correct the README's demo output description. It should say Hello, world! Only change README. Do not change the program, scripts, or dependencies. Please open a PR and explain what changed and how you checked it.

Replace the angle-bracket placeholder with the actual robot username. This is an example request, not a built-in command.

The default route polls GitHub account notifications, with a documented default interval of about a minute. Prefer a new comment over adding a mention to old text. Creating a label alone is not the default task trigger; label-driven work would need additional rules.

Look for a Ticket in Overview, then inspect the task session and the reply in the original discussion. The eventual result might be a PR or a request for missing information.

Treat the checkpoints separately:

  1. A Ticket exists: the intake route worked.
  2. A PR exists: the agent produced a proposed change.
  3. The diff and checking evidence satisfy the task: the delivery is acceptable.

For the README exercise, open the changed-files view. Confirm the output text is corrected, the launch command is untouched, and no program, script, or dependency file changed. A prose claim that everything passed cannot replace those checks.

The status command also helps locate problems. Exit code 0 means healthy operation; 1 indicates a process or runtime problem; 2 indicates a source or other module error; 3 means setup is still required. For 2 or 3, inspect the errors or setup details. Repeated restarts will not supply a missing account or configuration value.

Healthy service status still does not establish that the first task met its acceptance criteria.

Expand responsibilities after the first delivery

Once the README job works, try a small function in a repository that already has tests. Add the test command, prohibited changes, and failure-reporting expectations to the card. That creates a reviewable increment in responsibility.

Proactive work is a separate decision. The setup guide defaults proactive candidate handling to observe: record candidates without executing them. This is distinct from an explicit request by an authorized user. Inspect what the agent proposes before enabling broader proactive action.

Feishu is another optional expansion, with its own bot application, permissions, lark-cli configuration, and allowed list. It changes where requests arrive. It does not eliminate the setup beneath them.

My recommendation is to expand based on the quality of the delivered diff and the attention review requires. More intake channels are useful only when the current handoff is already understandable.

What can wait

You can leave Feishu, proactive scanning, multiple requesters, automatic merging, and production integration for later. The first finish line is one understandable change in a practice repository.

Ordinary chat remains useful for exploring ideas. The resident worker earns its place by keeping requests, task state, and delivery somewhere traceable. When a PR comes back, open it, inspect the evidence, and decide whether it belongs in your project.

Sources and scope

These public project documents were checked on November 7, 2026. Commands and panel names may change with the checkout. The setup examples describe the project's documented route; task outcomes depend on the actual repository and configuration.

  • Project README: prototype scope, the repository workflow, and its distinction from the internal system.
  • SETUP.md: prerequisites, guided planning, initial choices, and the first request.
  • 006 Deployment: account separation, permissions, installation, panel configuration, polling, startup, and status codes.
  • package.json: runtime compatibility and build scripts.