菜单
Update release notes entries in doc/release/RELEASE-NOTES.md. Use when the user asks to write, draft, add, or update release notes, or when preparing a new release entry.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Create business-oriented Confluence release notes (draft) and a Slack post draft from GitHub doc/release/RELEASE-NOTES.md. Files the Confluence page via Atlassian MCP (createConfluencePage) after user approval; Slack post is chat-only. Page structure: metadata table (Description row), Programs warning panel, issue table with Jira inline previews. GitHub is source of truth for tickets; Jira provides business context.
Draft, review, and file Jira tickets in OS Hub's house style — Stories (sprint-ready work with Requirements + Given/When/Then Acceptance Criteria) and Epics (feature groups with Background, Scope, and Requirements table). Coaches the user through the body and pushes for specificity, then prompts for parent, priority, labels, and other Jira fields so tickets never float. Files to OSDEV via the Atlassian MCP with two user checkpoints. Auto-loads on requests like "write a Jira ticket", "draft a story for X", "scope this as an epic", "write requirements".
Draft, review, improve, and file user stories in OS Hub's house style — 4-line format (As a / I want to / So that / What is hard today). Coaches the user through it: asks questions, proposes drafts to react to, iterates. Adapts to what they bring — a near-final draft, customer ask, persona+situation, or nothing yet. Files to OSDEV as an Initiative when they confirm. Auto-loads on requests like "write a user story", "draft stories for X", "fix this story", "what's the real need here".
Read a Jira ticket and produce a written plan saved as a markdown file. No code, no branches, no commits — just a quality plan. Use when the user asks to plan, scope, or think through an OSDEV ticket before building.
Full ticket pipeline for OS Hub — read a Jira ticket, plan, implement, test, preview, create PR. Use ONLY when the user explicitly invokes the /ship command or asks to "ship a ticket" with an OSDEV key. Do not auto-invoke on general mentions of planning, building, or implementing — /ship is a deliberate multi-step pipeline that requires explicit user trigger.
Make a copy edit anywhere on the OS Hub platform — change visible text on the website, in a form label, button, error message, navbar item, email template, or anywhere user-facing text appears. Use ONLY when the user explicitly invokes /copy-ship. Do not auto-invoke on general edit language. This skill exists so any teammate (engineer or not) can ship a text-only change end-to-end without manual file hunting.
| name | release-notes |
| description | Update release notes entries in doc/release/RELEASE-NOTES.md. Use when the user asks to write, draft, add, or update release notes, or when preparing a new release entry. |
Before writing the note, run these commands in parallel to understand the full scope of changes:
git log --oneline <base-branch>..HEADgit diff <base-branch>..HEAD --statgit diff <base-branch>..HEADgit log <base-branch>..HEAD --format="%B---"doc/release/RELEASE-NOTES.mddoc/release/RELEASE-NOTES-TEMPLATE.mdNew entries go at the top of the file, directly after the header block (lines 1–4).
doc/release/RELEASE-NOTES.md) to find the latest version number and the structure of existing entries before writing anything.2.19.0 → 2.20.0)2.18.0 → 2.18.1)## Release X.Y.Z
## Introduction
- Product name: Open Supply Hub
- Release date: _Provide release date_
### Database changes
#### Migrations
- <filename>.py - <What the migration does>.
#### Schema changes
- [OSDEV-XXXX](https://opensupplyhub.atlassian.net/browse/OSDEV-XXXX) - <Describe model/table changes>.
### Code/API changes
- [OSDEV-XXXX](https://opensupplyhub.atlassian.net/browse/OSDEV-XXXX) - <Describe code or API changes>.
### Architecture/Environment changes
- [OSDEV-XXXX](https://opensupplyhub.atlassian.net/browse/OSDEV-XXXX) - <Describe infra/devops changes>.
### Bugfix
- [OSDEV-XXXX](https://opensupplyhub.atlassian.net/browse/OSDEV-XXXX) - <Describe the fix>.
### What's new
- [OSDEV-XXXX](https://opensupplyhub.atlassian.net/browse/OSDEV-XXXX) - <Describe user-facing feature or change>.
### Release instructions
- Ensure that the following commands are included in the `post_deployment` command:
- `migrate`
- `reindex_database`
---
## Writing Rules
1. **Omit empty sections.** Only include sections that have content. Hotfix releases often only have `Bugfix` and `Release instructions`.
2. **Link Jira tickets** using `[OSDEV-XXXX](https://opensupplyhub.atlassian.net/browse/OSDEV-XXXX)` format.
3. **Prefix tags** when applicable:
- `[Hotfix][OSDEV-XXXX]` — for hotfix-specific items.
- `[Follow-up][OSDEV-XXXX]` — for follow-up work from a previous release.
4. **Migration entries** use the format: `* <filename>.py - <description>.`
5. **Be detailed.** Each bullet should explain _what_ changed and _why_, including endpoint paths, model names, field names, and behavioral effects.
6. **Release instructions** always include at minimum `migrate` and `reindex_database`. Add other commands (e.g. `reindex_locations_with_approved_claim`) only when the release requires them.
7. **Release date** — use the actual date if known, otherwise leave as `*Provide release date*`.
8. **Separate releases** with a `---` divider followed by two blank lines between entries.