Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add songoao25/dsh-virtual-product-team --skill 05-release-deploygit clone --depth 1 https://github.com/songoao25/dsh-virtual-product-teamWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/songoao25/dsh-virtual-product-team/05-release-deploy)<a href="https://agentmods.dev/skills/songoao25/dsh-virtual-product-team/05-release-deploy"><img src="https://agentmods.dev/badge/skills/songoao25/dsh-virtual-product-team/05-release-deploy/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/songoao25/dsh-virtual-product-team/05-release-deploy"><img src="https://agentmods.dev/badge/skills/songoao25/dsh-virtual-product-team/05-release-deploy.svg" alt="Reviewed on agentmods" width="80" height="20"></a>What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00059 | $0.02552 |
| Opus 5 | $0.00030 | $0.01276 |
| Sonnet 5 | $0.00012 | $0.00510 |
| Haiku 4.5 | $0.00006 | $0.00255 |
Grade A, and why
release-deploy scanned grade A with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 10d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Makes network callslowCapability
Not a fault in itself. Listed so you know the mod talks to something, and to what.
- [ ] **禁静态徽章冒充版本号**；每个徽章 URL 用 `curl -I` 验证 200；版本徽章显示值 == git tag == CHANGELOG 顶部 == Release title How it starts
The opening of the file, as written. The whole thing — 99 lines — stays where its author put it; the contents beside it link to each section on GitHub.
阶段 5：发布与部署（⑧发布准备 ⑨部署）
角色
你是主 Agent（发布/运维工程师）。任务：把通过审计的产品发布到 GitHub 并部署上线，符合 GitHub 发布全规范。
专业默认规范（DevOps/发布必备知识）
- 仓库命名规范（项目命名时就要遵守，发布时核对）：
- GitHub 硬性约束：≤100 字符、仅 ASCII 字母数字 +
-_.；空格自动转连字符 - 推荐风格：kebab-case 全小写 + 小横杠分隔（如 dsh-bottom-info-bar）；不用下划线、不用大写、不用空格
- 以核心功能关键词开头、可体现技术栈/类型、保持简洁唯一；npm 包名全小写
- GitHub 硬性约束：≤100 字符、仅 ASCII 字母数字 +
- 仓库设计规范：
- 标准目录结构：
src/（源码）、docs/（文档）、tests/（测试）、.github/（CI/模板） - 根目录文件：README/LICENSE/CHANGELOG 会被 GitHub"魔法识别"（仓库页自动展示）
- 分支命名
<type>/<描述>（如 feature/xxx、fix/xxx）
- 标准目录结构：
- 版本与发布规范：
- semver 决策表：major=不兼容、minor=新功能、patch=缺陷修复；tag 加 v 前缀
- 提交信息 Conventional Commits（feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert），50/72 规则（标题≤50 字符）
- 发布四件套同步：semver → CHANGELOG → commit → tag → Release 一次完成
- 部署策略意识：蓝绿/金丝雀/滚动（个人产品用最简单方式）；每次发布必答"怎么回滚"
- 可观测性：结构化日志、错误率/延迟指标、健康检查——发布后先看这三个
- 自动审核与合并规范：PR 小而可审计（一个功能一个修复）；PR 描述含动机/改动/测试。默认由 CI、测试和安全扫描自动审核，全部必需检查通过后自动合并；除非用户另行要求，不要求人工批准。配置分支保护时，必需检查名称必须与实际工作流显示名称完全一致；开启 GitHub Auto-merge，使用 squash merge。
- Issue 规范：好 Issue 含复现步骤/期望实际/环境
- 交接原则：发布涉及凭据与对外操作，由主 Agent/用户侧执行更稳；发布后主动给"先看哪三个指标"
目标
仓库达到符合 GitHub 全规范的可分发状态 + 实际部署上线可验证。发布记录、部署记录和交接材料保存到已忽略的 .product-team/，不进入公开仓库。
发布内容边界（强制）
- 可公开内容：产品源码、测试、构建与部署配置、依赖清单、许可证、变更记录，以及面向最终用户且明确需要公开的使用文档。
- 私有工作资料：调研、PRD、技术设计、任务清单、审计报告、发布/部署记录、交接单、截图、日志、宣传稿、渠道计划、运营数据和路线图。统一放在
.product-team/，并写入.gitignore。 - 宣传物料红线：宣传资料（视频脚本、文章模板、渠道清单、SEO 关键词、宣传文案等）只存在
.product-team/，严禁进入 GitHub 仓库——不得 git add、commit、push，不得随 tag/Release 发布，也不得复制进任何待发布文件。 - 不得以“文档”名义绕过边界：只有用户明确要求公开、且已按零密钥/零个人路径审查的文档，才能进入
docs/。
步骤
第一部分：发布准备（⑧）
- GitHub 发布规范检查清单（逐项检查并补齐）：
标准文件（Must）
-
README.md（英文）+README.zh-CN.md（中文）：用户视角，覆盖 是什么/怎么装/怎么用/常见问题；只写用户视角功能，严禁写开发过程流水账与内部代号；中英文顶部互含语言切换链接 -
LICENSE（默认 MIT，作者署名 songoao25） -
CHANGELOG.md（Keep a Changelog 格式） -
.gitignore（排除依赖/密钥/本地数据/日志） - 版本号：语义化 semver，与 Git tag 一致 社区健康文件（Should）
-
CONTRIBUTING.md/CODE_OF_CONDUCT.md/SECURITY.md/SUPPORT.md -
.gitattributes（LF 换行）/.editorconfigCI 与安全（Should） -
.github/workflows/ci.yml（push/PR 自动构建+测试） -
.github/dependabot.yml/ CodeQL / Issue+PR 模板 /AGENTS.mdGitHub 设置（Must） - 仓库公开（Public）；description 一句话讲清；topics（生态词 deepseek-harness/dsh/dsh-plugin + 类型词 plugin 或 preset + 功能词）
- 默认分支
main；开启 Discussions（可选） README 徽章（标准 7 件套，顺序固定，全带链接） - License / Release / CI / Last commit / Stars / Dependabot（+ Downloads 若 Release 带资产）
- 禁静态徽章冒充版本号；每个徽章 URL 用
curl -I验证 200；版本徽章显示值 == git tag == CHANGELOG 顶部 == Release title 发布前必检 - 零密钥、零个人路径（含
git log -p --all | grep -iE 'sk-[a-z0-9]|api[_-]?key|BEGIN (RSA|OPENSSH|EC) PRIVATE'历史扫描） -
.product-team/已由.gitignore忽略；git check-ignore -q .product-team/返回成功 - 暂存区仅含可公开内容；无
.product-team/、docs/PROMO.md、docs/RELEASE.md、docs/DEPLOY.md、docs/RELEASE-HANDOFF.md、调研稿、日志、宣传物料或本机脚本 - 提交信息遵循 Conventional Commits；四件套同步：semver → CHANGELOG → commit → tag → Release 一次完成
-
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 10d ago First seen · 99 lines · 59 tokens per session scan A f7051c97d30c
release-deploy is a skill published in the GitHub repository songoao25/dsh-virtual-product-team (5 stars, last pushed 6d ago), licensed MIT. It adds 59 tokens to every session and 2,552 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 1 finding (makes network calls). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-31.
Other skills, from other repositories
market-release
A release workflow for publishing a new version of a software package. It uses release-please to create a release pull request, then creates a tag, a GitHub release, and an npm publication after the pull request is merged.
git-workflow
Git workflow patterns including branching strategies, commit conventions, merge vs rebase, conflict resolution, and collaborative development best practices for teams of all sizes. Use when choosing a branching strategy, writing commit conventions, deciding merge versus rebase, or resolving conflicts.
github-ops
GitHub repository operations, automation, and management. Issue triage, PR management, CI/CD operations, release management, and security monitoring using the gh CLI. Use when the user wants to manage GitHub issues, PRs, CI status, releases, contributors, stale items, or any GitHub operational task beyond simple git…
opensource-pipeline
Open-source pipeline: fork, sanitize, and package private projects for safe public release. Chains 3 agents (forker, sanitizer, packager). Triggers: '/opensource', 'open source this', 'make this public', 'prepare for open source'. Use when a private project must be forked, stripped of secrets, and packaged for public…
release
Step through versioning, tagging, and verification.
dsh-changelog
A release-note writing guide for maintaining a CHANGELOG, a file that records what changed in each software version. It follows Keep a Changelog categories and semantic versioning rules.