一句话：装上它，你的 dsh（DeepSeek Harness）里就住进一支插件锻造专家团队——你出需求，它们从零把一个 dsh 插件做到可发布的 1.0.0。

不是模板，不是脚手架，是一支会分工、会互查、会打回、会发版的 Agent 团队：写手实现 → 测试独立试用 → 复核角色攻击报告 → 发布角色打包双形态验证 → 定版挂 GitHub Release。全程四值判定口径（通过/条件通过/不通过/未验证），不把没跑过的东西说成通过。

# 方式一：直接装 GitHub 仓（推荐）
dsh plugin --profile  add github:MYCF711/dsh-plugin-forge

# 方式二：从 Release 下载 tgz 后本地安装
dsh plugin --profile  add

依赖 @nanmicoder/dsh-agent-teams（多 Agent 团队协作）。若实例里没有，插件会给出安装指引；装完进程级重启一次即可。

安装后，在 dsh 里选 「锻造队长」（forge-captain）agent，直接说需求：

帮我做一个 dsh 插件：把当前仓库生成 token 级代码地图，控制 token 预算。

队长会：复述目标为可验收的交付定义 → 经你确认计划后拉起团队 → 拆任务图分派 → 收证据、组织修复循环 → 汇总交付检阅。你只需要在两个点出现：确认计划、验收成果。

💡 这支团队经受过真实考验：它的第一件作品 dsh-repo-map（仓库代码地图工具）已由团队自己从 0.1.0 锻造到 1.0.0 定版——期间 tester 抓出 2 个缓存正确性缺陷、reviewer 打回 11 条、 releaser 发现 1 个制品级缺陷，全部走修复循环闭环。

预设	显示名	职责	铁律
`forge-captain`	锻造队长	唯一总控：拆任务图、派发、整合、交付	上下文能闭环就不派发；成员自报≠证据；验证按证据版本去重
`forge-writer`	锻造写手	按手册实现插件 + README 能力清单	DoD 逐项自证后才许交付
`forge-tester`	锻造测试	四动作独立试用，只出证据	只判不改；原始命令+输出落盘
`forge-reviewer`	锻造复核	只读证据包，独立攻击报告	不重跑全量、不修复；增量复审
`forge-releaser`	锻造发布	版本判定、打包、双形态复验、发版	无敏感扫描不打包；无授权不触远端
`forge-ui`	锻造界面	在定稿合同内实装 UI slot / client bundle	定稿后不改设计；逐项对照定稿预览

每个 preset 的 persona 都绑定一份角色合同（权责边界、输入输出义务、禁止事项），队长的 persona 内置调度铁律与 UI 四阶段流程（样例先行 → 预览迭代 → 定稿 → 后端连接）。

技能	内容
`forge-writing`	插件写作工艺：seam/bundle/Config/解析链/工具注册/DoD/崩法速查
`forge-testing`	测试方法论：四动作、能力清单、判定口径、归因表、报告模板
`forge-releasing`	定版与发布：版本判定表、打包清单、制品六验、GitHub 发版
`forge-teamwork`	团队协作：任务拆解、交接契约、独立复核、免费档模型风险
`forge-ui`	UI/client 插件：主题 token 三类色、对比度、布局健壮性、预览定稿制
`forge-roles`	六份角色合同 + 调度铁律 + 跨轮任务账本（改编自 odai，MIT）

篇	内容
docs/01 机制篇	dsh 六层机制：seam/bundle/preset/agent/skill/AGENTS.md
docs/02 开发篇	从零写插件的完整工艺
docs/03 测试篇	四动作测试法与独立复核
docs/04 发布篇	定版判定与 GitHub 发布（含网络封锁应对实测）
docs/05 坑表	本机踩坑实录（杀软回滚 hosts、代理拦截、adb 通道…）
docs/06 装配篇	preset/技能/团队模板的组装与验证

GPL-3.0 —— 衍生作品须同样开源。

dsh-plugin-forge

같은 패키지 이름의 다른 저장소