What dsh-superagent Is: An AI Teammate for One GitHub Repo
dsh-superagent is a framework for an AI teammate that watches one GitHub repo and does the work while you chat. You write a request in a GitHub conversation, and the agent opens a work item, does the task in its own agent session and directory, and answers back in the original conversation with a pull request. That is the whole idea: you never leave the conversation, and the work arrives as a normal PR you can review. It comes from DeepSeek's own deepseek-ai organization, it has 22,373 stars, it is written in TypeScript and licensed under MIT. But read the name carefully. This is explicitly a research prototype. It is not an official DeepSeek product, it is not production ready, and the README says it may contain bugs. If you try it, try it as a prototype: on a repo you can afford to experiment with, with a human reviewing every pull request it opens.
How It Works: You Chat, It Opens a Pull Request
A dsh-superagent instance is for one GitHub repo, and it listens to GitHub, and optionally to Feishu, for requests. A request only counts when it addresses the agent directly and comes from a person the team allowed, either someone on an allowed list or anyone in a conversation the team opened to requests. When a request arrives, the agent confirms once and names what it will do, then stays quiet while it works. It writes again when the result is ready, when it needs a decision, or when it cannot finish. The result is a pull request in the repo, opened by the agent. A Text Diff is the fastest way to check that pull request, since you can compare the agent's changes against the original code line by line before you merge anything. The agent also has a dashboard panel that shows live progress, and it lists first what waits for a person, so a healthy state takes no space.
The Philosophy: As Little Attention as Possible, As Much Value as Possible
The project is built around one principle: take as little human attention as possible, and give as much value as possible. Every part of it is judged by the attention it costs. A message, a notification, a question, a setting, a panel element and a paragraph of documentation each cost someone's attention, and each one has to give more value than that, or it is removed. That is why the agent speaks only when a person must act or can use a result, why it asks one concrete question at a time instead of burying a question inside a long report, and why it stops by impact rather than by effort. A local change goes as far as a reviewable result. A change that needs a design decision stops with a clear question. A draft is marked unfinished, a failure is reported as a failure, and a limit is never bypassed just to avoid asking. The design follows the same rule: few concepts, few settings, and documents that read in order so a reader never needs a concept that has not been introduced yet.
Proactive Work: Rules, Not Requests, and a Record Only Mode
The agent does more than answer requests. It can also do proactive work, but only under rules the team wrote in advance, and it starts in a mode that only records what it would have done. That record only mode is the safe way to begin: the agent watches, notes what it would change, and does nothing, until you have seen enough of its judgement to trust it. When you widen what it may do, you widen it deliberately, from a short allowed list outward. The README is blunt about the responsibility that comes with this. The agent comments, opens pull requests and messages people under accounts your team sees every day, and every message it sends costs your colleagues' attention. So start narrow, tune for less noise, and never use it to produce volume. Mass pull requests, broadcast messages and busywork cost the team more than they give, and the goal is the right help at the right time, and nothing at any other time.
Setting It Up: Agent Assisted, One Repo at a Time
Setup is agent assisted, which fits the project: you follow SETUP.md and the agent helps you set itself up. You give it a repo, the allowed list, and the rules for proactive work, and you deploy it so it can listen to GitHub. A JSON to YAML converter comes in handy during setup, since the agent's configuration and the repo's workflow files are YAML, and it is easier to check a JSON example by converting it first. The project is a work in progress, so expect rough edges, and the documentation is organized as numbered documents that build on each other, starting with the philosophy, then the overview, then the concepts, the deployment guide and the setup guide. Read them in order and each one only uses ideas the earlier ones already introduced.
Who Should Try It, and Who Should Wait
This is for people who run a GitHub repo and want to see what an AI teammate feels like, and who are comfortable reviewing every pull request it opens. It is a good fit for a side project or a team repo where someone is watching the queue and can correct the agent when it is wrong, because the README says plainly that you own what it says: read what the agent posts in your name, and correct it in the prompts when it is wrong. It is not for a production repo you cannot afford to experiment on, and it is not for anyone who wants a finished product with support. It is a research prototype from DeepSeek's own organization, it may contain bugs, and it is shared so people can learn from the way it works. If that sounds like you, the repo is worth an evening. If you need something that just works, wait for the prototype to grow up.
