使用方法
- 复制安装命令，在自己的智能体环境安装前先检查源码包。
- 从原始文档核对所需工具、凭据和支持的宿主。
- 说明输入材料与期望交付物，并对照来源检查输出。
npx skills add https://github.com/sociuu/sociuu-skills --skill sociuu-release-notes开始前需了解
- 安装不包含模型订阅、API 额度或访问文件的权限。
- 仓库星数和安装量反映活跃情况，不等于独立质量或安全测试。
按源仓库内容呈现，保留标题、案例、代码、表格、链接以及原文引用的演示图片。
Sociuu Release Notes
Turns shipped work into two outputs: one release-note comment per ClickUp task, and, when asked for, one #dev_updates note for the non-dev team. The note is sent only when the requester's own instructions allow it; otherwise it stays a draft for a human to send.
Steps
- Scope. Get the release table: from
sociuu-releasewhen it calls
this skill, otherwise build it for the given tag range or release with release contents (range and release table only), or start from the given task list. Done when every item has its ClickUp task, MRs, tags and Production deploy time, or is marked as having no Production deploy yet.
- Understand each task. Read the task's existing release-note comment
when there is one; it is the primary source. Otherwise read the task description, its Ledger, the MR descriptions and, if still unclear, the diff. Note the reporter: the person the task names as reporting it, else its creator when that is not a developer.
- Sort by audience. Apply the audience rules in the
#dev_updates template. Every item ends up in the note or on an exclusion list with a one-line reason; show that list to the human with the draft.
- Comment on each task. Write the comment below. Update the task's
existing release-note comment instead of adding a second one. Post only for work verified in Production; otherwise present the comments as drafts.
- Write the Slack note when asked, with the
#dev_updates template, and save it as a Markdown file in the release or task record. Send it to #devupdates only when the requester's instructions allow sending and the release is verified in Production. Otherwise save it as an unsent draft in #devupdates through the Slack draft tool (if Slack already holds a draft for that channel, leave it alone and point to the file) and hand it to the human to review and send.
Release-note comment
Plain text, factual, for the team that will support the change:
Release note: <repo> <tag> (<short sha>)[, <repo> <tag> …], Production <YYYY-MM-DD HH:MM> UTC
User impact
- <what changed for users or data, before → now, with aggregate numbers>
MRs: <repo>!<iid> (merged <short sha>), … Also in this release: <other tasks, if relevant>
Evidence
- Staging / Demo / Production: <deploy time, migrations, checks and results>
- Monitoring: <new errors since the baseline, or none>
Open: <follow-ups with links, or none>Keep customer rows and personal data out; client names may appear when the task already names them.
