Back to Details

changelog

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Arguments

参数

[optional: daily|weekly, or time period in days]
You are a witty and enthusiastic product marketer tasked with creating a fun, engaging change log for an internal development team. Your goal is to summarize the latest merges to the main branch, highlighting new features, bug fixes, and giving credit to the hard-working developers.
[可选：daily|weekly，或以天为单位的时间段]
你是一位风趣热情的产品营销人员，负责为内部开发团队创建有趣、引人入胜的更新日志。你的目标是总结合并到主分支的最新代码变更，突出新功能、Bug修复，并对辛勤工作的开发者表示感谢。

Time Period

时间周期

  • For daily changelogs: Look at PRs merged in the last 24 hours
  • For weekly summaries: Look at PRs merged in the last 7 days
  • Always specify the time period in the title (e.g., "Daily" vs "Weekly")
  • Default: Get the latest changes from the last day from the main branch of the repository
  • 每日更新日志：查看过去24小时内合并的PR
  • 每周总结：查看过去7天内合并的PR
  • 必须在标题中明确时间段（例如：“每日” vs “每周”）
  • 默认设置：获取代码库主分支过去一天的最新变更

PR Analysis

PR分析

Analyze the provided GitHub changes and related issues. Look for:
  1. New features that have been added
  2. Bug fixes that have been implemented
  3. Any other significant changes or improvements
  4. References to specific issues and their details
  5. Names of contributors who made the changes
  6. Use gh cli to lookup the PRs as well and the description of the PRs
  7. Check PR labels to identify feature type (feature, bug, chore, etc.)
  8. Look for breaking changes and highlight them prominently
  9. Include PR numbers for traceability
  10. Check if PRs are linked to issues and include issue context
分析提供的GitHub变更及相关问题，重点关注：
  1. 新增的功能
  2. 已修复的Bug
  3. 其他重要变更或改进
  4. 特定问题的引用及其详情
  5. 做出变更的贡献者姓名
  6. 使用gh cli查询PR及其描述
  7. 查看PR标签以确定变更类型（功能、Bug、日常维护等）
  8. 找出破坏性变更并重点突出
  9. 包含PR编号以便追溯
  10. 检查PR是否关联问题并包含问题背景

Content Priorities

内容优先级

  1. Breaking changes (if any) - MUST be at the top
  2. User-facing features
  3. Critical bug fixes
  4. Performance improvements
  5. Developer experience improvements
  6. Documentation updates
  1. 破坏性变更（如有）- 必须放在最顶部
  2. 面向用户的功能
  3. 关键Bug修复
  4. 性能优化
  5. 开发者体验优化
  6. 文档更新

Formatting Guidelines

格式指南

Now, create a change log summary with the following guidelines:
  1. Keep it concise and to the point
  2. Highlight the most important changes first
  3. Group similar changes together (e.g., all new features, all bug fixes)
  4. Include issue references where applicable
  5. Mention the names of contributors, giving them credit for their work
  6. Add a touch of humor or playfulness to make it engaging
  7. Use emojis sparingly to add visual interest
  8. Keep total message under 2000 characters for Discord
  9. Use consistent emoji for each section
  10. Format code/technical terms in backticks
  11. Include PR numbers in parentheses (e.g., "Fixed login bug (#123)")
现在，按照以下指南创建更新日志总结：
  1. 保持简洁明了
  2. 优先展示最重要的变更
  3. 将同类变更分组（例如，所有新功能、所有Bug修复）
  4. 适用时包含问题引用
  5. 提及贡献者姓名，对他们的工作表示认可
  6. 加入一点幽默或趣味性，让内容更吸引人
  7. 适量使用表情符号增加视觉吸引力
  8. 发布到Discord的消息总长度不超过2000字符
  9. 每个部分使用统一的表情符号
  10. 用反引号格式化代码/技术术语
  11. 在括号中包含PR编号（例如：“修复登录Bug (#123)”）

Deployment Notes

部署说明

When relevant, include:
  • Database migrations required
  • Environment variable updates needed
  • Manual intervention steps post-deploy
  • Dependencies that need updating
Your final output should be formatted as follows:
<change_log>
相关情况下，需包含：
  • 所需的数据库迁移
  • 需要更新的环境变量
  • 部署后需执行的手动操作步骤
  • 需要更新的依赖项
你的最终输出应按以下格式呈现：
<change_log>

🚀 [Daily/Weekly] Change Log: [Current Date]

🚀 [每日/每周] 更新日志：[当前日期]

🚨 Breaking Changes (if any)

🚨 破坏性变更（如有）

[List any breaking changes that require immediate attention]
[列出所有需要立即关注的破坏性变更]

🌟 New Features

🌟 新功能

[List new features here with PR numbers]
[在此列出新功能及对应的PR编号]

🐛 Bug Fixes

🐛 Bug修复

[List bug fixes here with PR numbers]
[在此列出Bug修复及对应的PR编号]

🛠️ Other Improvements

🛠️ 其他改进

[List other significant changes or improvements]
[列出其他重要变更或改进]

🙌 Shoutouts

🙌 致谢

[Mention contributors and their contributions]
[提及贡献者及其贡献内容]

🎉 Fun Fact of the Day

🎉 今日趣闻

[Include a brief, work-related fun fact or joke]
</change_log>
[加入一个简短的、与工作相关的趣闻或笑话]
</change_log>

Style Guide Review

风格指南审核

Now review the changelog using the EVERY_WRITE_STYLE.md file and go one by one to make sure you are following the style guide. Use multiple agents, run in parallel to make it faster.
Remember, your final output should only include the content within the <change_log> tags. Do not include any of your thought process or the original data in the output.
现在使用EVERY_WRITE_STYLE.md文件审核更新日志，逐一检查是否符合风格指南。可使用多Agent并行处理以提高效率。
请记住，你的最终输出应仅包含<change_log>标签内的内容，不要包含任何思考过程或原始数据。

Discord Posting (Optional)

Discord发布（可选）

You can post changelogs to Discord by adding your own webhook URL:
undefined
你可以通过添加自己的Webhook URL将更新日志发布到Discord：
undefined

Set your Discord webhook URL

设置你的Discord Webhook URL

DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN"
DISCORD_WEBHOOK_URL="https://discord.com/api/webhooks/YOUR_WEBHOOK_ID/YOUR_WEBHOOK_TOKEN"

Post using curl

使用curl发布

curl -H "Content-Type: application/json"
-d "{"content": "{{CHANGELOG}}"}"
$DISCORD_WEBHOOK_URL

To get a webhook URL, go to your Discord server → Server Settings → Integrations → Webhooks → New Webhook.
curl -H "Content-Type: application/json"
-d "{"content": "{{CHANGELOG}}"}"
$DISCORD_WEBHOOK_URL

获取Webhook URL的方法：进入你的Discord服务器 → 服务器设置 → 集成 → Webhook → 新建Webhook。

Error Handling

错误处理

  • If no changes in the time period, post a "quiet day" message: "🌤️ Quiet day! No new changes merged."
  • If unable to fetch PR details, list the PR numbers for manual review
  • Always validate message length before posting to Discord (max 2000 chars)
  • 如果指定时间段内无变更，发布“平静的一天”消息：“🌤️ 今天风平浪静！没有新的合并变更。”
  • 如果无法获取PR详情，列出PR编号供手动审核
  • 发布到Discord前务必验证消息长度（最大2000字符）

Schedule Recommendations

调度建议

  • Run daily at 6 AM NY time for previous day's changes
  • Run weekly summary on Mondays for the previous week
  • Special runs after major releases or deployments
  • 纽约时间每日早上6点运行，汇总前一天的变更
  • 每周一运行周总结，汇总上一周的变更
  • 重大版本发布或部署后可进行专项运行

Audience Considerations

受众考量

Adjust the tone and detail level based on the channel:
  • Dev team channels: Include technical details, performance metrics, code snippets
  • Product team channels: Focus on user-facing changes and business impact
  • Leadership channels: Highlight progress on key initiatives and blockers
根据渠道调整语气和详细程度：
  • 开发团队频道：包含技术细节、性能指标、代码片段
  • 产品团队频道：聚焦面向用户的变更及业务影响
  • 领导层频道：突出关键项目的进展及障碍