Requests with an accountable source
GitHub and optional Feishu events enter a policy-controlled routing process. Allowed senders, receiving scope, and team rules determine whether a request can become work.
DSH Superagent Prototype
Explore DeepSeek’s research prototype for turning authorized GitHub and Feishu requests into coding tasks. Study task routing, scoped execution, and reviewable delivery for your own agent workflows.
Map an issue request to an authorized coding task
Start with a permitted repository request and where its result should return. The task can examine DSH's request-to-ticket-to-draft-PR pattern while preserving requester authorization and original scope, with connections and execution permissions checked as separate prerequisites.
Specify the repository, allowed requesters, labels, review policy, and expected PR output.
Copy the request into a new Floatboat conversation and provide the required material.
Download FloatboatYour request for Floatboat
Preview and copy the request. It is not sent automatically from this page.
Reference: DSH Superagent Prototype https://github.com/deepseek-ai/dsh-superagent-prototype Read the original documentation and check the current environment and dependencies. Propose any new installation or tool connection before proceeding. My task: Read the DSH Superagent prototype setup and authorization documents. Design a GitHub-issue-to-draft-PR flow for my repository, listing requester permissions, duplicate-event handling, and required approval. Show the plan before any account, webhook, or service configuration. Expected deliverable: A request-to-ticket flow with authorization checks, duplicate handling, and a reviewable handoff.
About DSH Superagent Prototype
DSH Superagent Prototype is a proactive coding agent published in DeepSeek’s official GitHub organization. It runs as a DeepSeek Harness bundle for one GitHub repository, with optional Feishu input. Authorized requests become tasks that execute in their own sessions and working directories, then return results to the original conversation.
Its useful workflow patterns include evaluating incoming requests, keeping each task within an assigned scope, and following discussion without treating every message as new authority. The web panel prioritizes work needing a person and also exposes history and operational health.
The MIT-licensed repository is research code, explicitly described as not an official DeepSeek product or production-ready software. Its published implementation differs from the internal version and the accompanying design article; some ideas discussed there remain unimplemented.
How Requests Become Agent Work
DSH connects an accountable request source with a bounded task and a result returned to the work's starting point. Compare those mechanisms when designing repository collaboration, keeping authorization and traceable delivery separate from simply receiving a message.
A scope for each task
Accepted work becomes a Ticket with a Mandate defining its authority. Its executor uses a dedicated session and directory while subscribed conversations provide continuing context.
Results where the work started
The agent can reply in the original conversation and open pull requests. A panel brings review, blocked work, and other items needing human attention into view.
Use Cases for DSH Superagent Prototype
Maintenance requests, review follow-ups, and message-triggered work depend on a traceable task identity. Explore DSH's request-to-draft-PR handoff while keeping requester permissions, original scope, and result-return destinations explicit in your own workflow design.
Repository maintenance requests
Repository maintenance can follow a traceable request-to-ticket-to-draft-PR flow. Bound the coding request, permitted files, and acceptance conditions before work begins, and attach verification evidence to the proposed change. This makes the result inspectable without treating a draft pull request as an approved modification.
Follow-up after a review
Review feedback should stay attached to the task and authorization it concerns. Preserve the original scope when planning a continuation, and route unrelated requests into separate work instead of silently enlarging the assignment. The handoff should show which comments are being addressed and which require a new decision.
Team messages with a clear outcome
A message-triggered workflow needs approved channels, permitted requesters, and a clear destination for results. Define the trigger, authorization, assignment, and return path before borrowing that handoff pattern for work organized in Floatboat. Check connection requirements separately rather than assuming the channel is already integrated.
Review execution boundaries before enabling work
The router and worker environment should be assessed alongside requester rules and inferred-task handling. Read the current runtime prerequisites and identify which account, repository, and operating-system permissions the prototype would use. Keep observation settings, execution authorization, and machine isolation distinct, then decide which bounded experiment is acceptable before allowing the system to act on real repository requests.
Prepare the DSH Superagent runtime
Running the prototype requires a compatible Harness environment, configured model access, and a dedicated repository identity. Review those conditions alongside operating-system permissions: separate sessions and credential wrappers do not themselves provide a sandbox for router or worker activity.
Prepare the runtime and agent identity
Use a supported Harness version, a configured model provider, and the documented command-line dependencies. One deployment serves one github.com repository through a dedicated GitHub user account.
Separate machine permissions
The documented router and worker presets run with full access as the operating-system user. Separate sessions and credential wrappers are not a sandbox; use a dedicated OS account for isolation.
Inspect DSH Superagent’s task decisions
Observation helps assess inferred tasks before automatic acceptance is enabled, but explicit requests can still execute in observe mode. Review the steps with that distinction intact, checking permissions and task records rather than treating the mode as a universal execution block.
Inspect inferred work first
The default observe mode records inferred tasks it would accept without starting them; explicit requests still execute. Review decisions before enabling automatic acceptance under written rules.
From GitHub Requests to Agent Workflows
Trace a request through authorization, task execution, and delivery, then decide which mechanisms fit your own workflow.
Related Software Projects
Compare the workflows, operating requirements, and source licenses of these projects.
DSH Superagent Prototype FAQ
Is DSH Superagent a DeepSeek model?
It is agent application code running on DeepSeek Harness. A separately configured model provider supplies inference; the project itself is not model weights or a model API subscription.
How does it differ from DeepSeek Harness?
Harness provides the surrounding agent runtime and extension system. Superagent is a bundle built on that runtime to coordinate requests, tasks, sessions, and delivery for a repository.
Does it need Feishu or support every GitHub deployment?
Feishu is optional. The documented scope is one github.com repository per deployment; GitHub Enterprise Server is unsupported. The agent needs a dedicated GitHub user with write access, rather than a GitHub App.
Does observe mode stop every task from running?
No. It evaluates inferred candidates and records positive assessments without accepting them. Explicit requests work in every mode; automatic acceptance of inferred work requires auto mode and matching rules.
Are workers isolated from the rest of my computer?
No security sandbox is provided by the separate task directories or account wrappers. The documented presets run with full OS-user access, so the deployment guide recommends a dedicated OS account containing only the agent credentials.
Does MIT make it production-ready or include free inference?
MIT covers the source code. Model services and machine operation have separate costs and terms. The README identifies the software as a research prototype, with differences from its internal implementation and some unimplemented design ideas.