Dsh Subagent Admission — Development skill for Claude Code

dsh-subagent-admission

[简体中文](README.zh-CN.md)

[](https://github.com/yha9806/dsh-subagent-admission/actions/workflows/ci.yml)

An experimental shared lifecycle admission protocol and reference policy kernel for [DeepSeek Harness](https://github.com/deepseek-ai/deepseek-harness) subagents.

This project addresses the failure shape reported in [Discussion #131](https://github.com/deepseek-ai/deepseek-harness/discussions/131): nested subagents can expand until one Web host becomes unresponsive. It does not add another orchestrator. It makes the decision to create or reactivate a subagent explicit, atomic, and lifecycle-owned across every caller that uses the official runtime.

The long-term product direction is an **Agent Runtime Resource Control Plane**: every materialising agent workload should first acquire an explicit, observable, lifecycle-owned resource permit. v0.1 deliberately tests only the DSH subagent boundary.

**Release-candidate status:** GitHub prerelease [`v0.1.0-rc.1`](https://github.com/yha9806/dsh-subagent-admission/releases/tag/v0.1.0-rc.1) is public, while the package is not published to npm. The focused upstream extension-point question is now public in [Discussion #131](https://github.com/deepseek-ai/deepseek-harness/discussions/131#discussioncomment-18020293). This remains an independent community project, not an official DeepSeek component. No DeepSeek endorsement or adoption, external-user evidence, production deployment, or maintainer response has been observed.

Maintainer review path

The upstream decision is deliberately one question:

Would an optional lifecycle-owned subagent admission capability belong as a documented extension point?

A bounded review can follow four artifacts:

• Agent Note: the protocol-v1 Service Definition, Provider, Consumer, failure, and ownership contract;
• [slim