Release Notes
Structured guidance for CHANGELOG files and release notes: confirm triggers, propose the stages below, and adapt if the user wants a lighter pass.
When to Offer This Workflow
Trigger conditions:
- - User mentions release notes, CHANGELOG, what shipped, or closely related work
- They want a structured workflow rather than ad-hoc tips
- They are preparing a review, rollout, or stakeholder communication
Initial offer:
Explain the four stages briefly and ask whether to follow this workflow or work freeform. If they decline, continue in their preferred style.
Workflow Stages
Stage 1: Clarify context & goals
Anchor on audience (users vs developers) and cadence (per release vs continuous). Ask what success looks like and what must not break.
Stage 2: Structure & categories
Group changes (features, fixes, breaking, security). Prefer links to issues/PRs and migration notes when breaking.
Stage 3: Draft & refine
Iterate for clarity: imperative mood, scannable bullets, version headers aligned with semver or product versioning.
Stage 4: Verify & ship
Close the loop with tone: concise and verifiable: monitoring, documentation, stakeholder updates, and lessons learned for the next cycle.
Checklist Before Completion
- - Goals and constraints are explicit for release notes work
- Risks and trade-offs are stated, not hand-waved
- Verification steps match the change’s impact (tests, canary, peer review)
- Operational follow-through is covered (monitoring, docs, owners)
Tips for Effective Guidance
- - Be procedural: stage-by-stage, with clear exit criteria
- Ask for missing context (environment, scale, deadlines) before prescribing
- Prefer checklists and concrete examples over generic platitudes
- If the user declines the workflow, switch to freeform help without lecturing
Handling Deviations
- - If the user wants to skip a stage: confirm and continue with what they need.
- If context is missing: ask targeted questions before strong recommendations.
- Prefer concrete examples, trade-offs, and verification steps over generic advice.
Quality Bar
- - Each recommendation should be actionable (what to do next).
- Call out failure modes relevant to release communication (security, scale, UX, or ops).
- Keep tone direct and respectful of the user’s time.
发布说明
针对CHANGELOG文件和发布说明的结构化指导:确认触发条件,提出以下阶段,并在用户希望简化流程时进行调整。
何时提供此工作流程
触发条件:
- - 用户提及发布说明、CHANGELOG、已发布内容或密切相关的工作
- 用户需要结构化工作流程而非临时建议
- 用户正在准备审查、发布或利益相关方沟通
初始提议:
简要说明四个阶段,并询问是遵循此工作流程还是自由发挥。如果用户拒绝,则继续按他们偏好的风格进行。
工作流程阶段
阶段1:明确背景与目标
锚定受众(用户vs开发者)和节奏(每次发布vs持续更新)。询问成功的标准以及哪些内容绝对不能出错。
阶段2:结构与分类
对变更进行分组(功能、修复、破坏性变更、安全)。建议链接到问题/PR,并在涉及破坏性变更时提供迁移说明。
阶段3:起草与优化
迭代优化清晰度:使用祈使语气、可快速浏览的要点、版本标题与语义化版本或产品版本号对齐。
阶段4:验证与发布
以简洁且可验证的语气完成闭环:监控、文档、利益相关方更新以及为下一周期总结的经验教训。
完成前的检查清单
- - 明确发布说明工作的目标与约束条件
- 说明风险与权衡,而非轻描淡写
- 验证步骤与变更影响相匹配(测试、灰度发布、同行评审)
- 涵盖运营跟进事项(监控、文档、负责人)
有效指导技巧
- - 按流程推进:分阶段进行,并明确退出标准
- 在给出建议前,先询问缺失的背景信息(环境、规模、截止日期)
- 优先使用检查清单和具体示例,而非泛泛而谈
- 如果用户拒绝工作流程,则切换为自由帮助模式,避免说教
处理偏差情况
- - 如果用户想跳过某个阶段:确认后继续提供他们所需的内容
- 如果缺少背景信息:在给出强烈建议前,先提出有针对性的问题
- 优先提供具体示例、权衡方案和验证步骤,而非泛泛建议
质量标准
- - 每条建议应可操作(明确下一步该做什么)
- 指出与发布沟通相关的失败模式(安全、规模、用户体验或运维)
- 保持语气直接,尊重用户的时间