Install
$ agentstack add skill-thinkinaixyz-deepchat-deepchat-release ✓ scanned · ✓ verified — works with Claude Code, Cursor, and more.
Security review
✓ PassedNo issues found. Passed automated security review. · v0.1.0 How review works →
- ✓ Prompt-injection patterns
- ✓ Secret / credential exfiltration
- ✓ Dangerous shell & filesystem operations
- ✓ Untrusted network calls
- ✓ Known-malicious package signatures
What it can access
- ✓ Network access No
- ✓ Filesystem access No
- ✓ Shell / process execution No
- ✓ Environment & secrets No
- ✓ Dynamic code execution No
From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.
About
DeepChat Release
Overview
Follow the repository-specific DeepChat release process. Prepare release metadata on dev, keep CHANGELOG.md concise, and publish through the documented fast-forward flow instead of merge commits on main.
Start With Repo State
Inspect git state before changing anything:
- Check the current branch and working tree.
- Check whether
release/exists locally or onorigin. - Check whether
vexists locally or onorigin.
If a local or remote tag already exists on the wrong commit, stop and ask before replacing it.
Choose The Release Mode
Pick the mode that matches the user's request and current git state:
prepare metadata
Update package.json, CHANGELOG.md, and the release notes commit on dev.
cut release branch
Create release/ from the release-ready commit on dev and push it.
update existing release branch
Use this when the release branch already exists but metadata changed afterward. Commit on dev, move release/ to the new dev commit, and force-push only the disposable release branch.
publish
Use this only after the release PR is approved. Fast-forward main, create the version tag on the same commit, push the tag, and then delete the temporary release branch.
Use [references/release-checklist.md](references/release-checklist.md) for exact commands.
Update Release Metadata
When preparing a release on dev:
- Update
package.jsonto the target version. - Add a new
CHANGELOG.mdsection at the top. - Summarize only user-visible or release-relevant changes since the previous tag.
- Prefer deriving the notes from recent commits or the diff since the previous release tag.
- Do not create SDD folders for pure release metadata, branch, tag, or release PR work.
For v1.0.1 and later, format changelog entries in this order:
## vX.Y.Z (YYYY-MM-DD)
- English bullet
- English bullet
- 中文条目
- 中文条目
Use the current local date in YYYY-MM-DD form. Preserve older changelog sections unless the user explicitly asks to rewrite them.
Run Release Checks
After editing release metadata, run these repo-required commands:
pnpm run formatpnpm run i18npnpm run lint
Prefer running pnpm run typecheck before cutting the release branch. Run tests when the user asks, when the release touches behavior beyond metadata, or when risk is unclear. Report pre-existing failures separately from the release metadata work.
Follow Release Branch Policy
- Keep
devas the integration branch. - Treat
release/as disposable and identical to a commit already ondev. - Never use the GitHub merge button for releases to
main. - Never click "Update branch" on the release PR.
- Use
pnpm run release:ff -- release/ --tag vto publish after approval.
Read [../../../docs/release-flow.md](../../../docs/release-flow.md) when you need the full repository policy or if the checklist and repo docs ever diverge.
Common Recovery Case
When the user says something like "the release branch already exists but the tag is not created yet" or "I fixed the changelog after cutting the release branch":
- Commit the metadata fix on
dev. - Push
dev. - Move
release/toHEAD. - Force-push
release/with--force-with-lease. - Continue with the existing or updated PR to
main. - After approval, publish and create the tag.
Response Rules
- Act on the repo when the user wants the release advanced; do not stop at generic advice.
- Tell the user exactly which step of the release flow they are currently in.
- Use concrete versions and dates such as
v1.0.1and2026-04-02. - Keep commands copy-pastable and repo-specific.
- If checks fail, separate blocking failures from unrelated existing warnings.
Examples
Activate this skill for requests like:
- "准备发布 1.0.2,更新版本号和 changelog"
- "继续发 1.0.1,release 分支已经有了,还没打 tag"
- "帮我按项目流程把 release/v1.0.3 发出去"
- "检查一下现在离发布 v1.0.4 还差什么"
Source & license
This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.
- Author: ThinkInAIXYZ
- Source: ThinkInAIXYZ/deepchat
- License: Apache-2.0
- Homepage: https://deepchat.thinkinai.xyz/
Install and usage instructions live in the source repository linked above.
Reviews
No reviews yet — be the first.
Write a review
Versions
- v0.1.0 Imported from the upstream source.