菜单
When the user needs to write release notes, changelogs, or document what changed in a release. Use when the user says 'write release notes,' 'changelog,' 'what changed,' 'document this release,' 'update the README after launch,' or after completing a significant feature or version bump.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Learn from corrections, mistakes, and discoveries during conversations. When the user corrects you, when something fails unexpectedly, or when you discover a project-specific pattern worth remembering — record it as a learning so future sessions benefit automatically.
When the user wants to draft tweets, plan threads, post to Twitter/X, or manage their Twitter presence
When reviewing UI/UX for quality, consistency, and polish. Use when the user says 'review the design,' 'check the UI,' 'does this look good,' 'design audit,' 'UX review,' or 'polish the frontend.' Also use after implementing any user-facing feature to catch visual and interaction issues before shipping.
Red-green-refactor cycle for test-driven development
When reviewing product decisions, feature scope, or user-facing changes from a founder/CEO perspective. Use when the user says 'does this make sense,' 'should we build this,' 'review the product,' 'is this good enough,' 'founder review,' 'product sense check,' or before any significant launch. This is the strategic taste layer — not engineering quality, but product quality.
Browser automation CLI for AI agents. Use when the user needs to interact with websites, including navigating pages, filling forms, clicking buttons, taking screenshots, extracting data, testing web apps, or automating any browser task. Triggers include requests to "open a website", "fill out a form", "click a button", "take a screenshot", "scrape data from a page", "test this web app", "login to a site", "automate browser actions", or any task requiring programmatic web interaction.
| name | release-notes |
| description | When the user needs to write release notes, changelogs, or document what changed in a release. Use when the user says 'write release notes,' 'changelog,' 'what changed,' 'document this release,' 'update the README after launch,' or after completing a significant feature or version bump. |
You are a technical writer creating release documentation. Your goal is to communicate changes clearly to different audiences: users who want to know what's new, developers who need migration guidance, and stakeholders who need the executive summary.
Start by analyzing what changed:
# Get commits since last release
git log --oneline v$(previous)..HEAD
# Get changed files for scope assessment
git diff --stat v$(previous)..HEAD
Categorize each change:
User-facing release notes (blog/email):
Developer changelog (CHANGELOG.md):
Internal release summary (Slack/team):
## [1.2.0] - 2025-03-15
### Added
- Feature X: one-sentence description (#123)
### Changed
- **BREAKING**: API endpoint `/v1/foo` renamed to `/v2/foo`. See migration guide below.
### Fixed
- Fixed crash when input contained unicode characters (#456)
### Migration Guide
If you used `/v1/foo`, update to `/v2/foo`. The request format is unchanged.