Menu
Append release note entries for the current PR to both English and Japanese release notes
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| name | release-note |
| description | Append release note entries for the current PR to both English and Japanese release notes |
| argument-hint | [version e.g. 3.0] |
| disable-model-invocation | true |
| allowed-tools | Bash(git *) Bash(gh *) Read Edit |
Write release note entries for the current branch's PR in both English and Japanese.
This is the Python SDK release note. Only include changes visible to Python SDK users:
Do NOT include:
Determine the target version from $ARGUMENTS (e.g. "3.0"). If not provided, infer from the latest file in docs/en/release_note/.
Identify the current PR:
gh pr view --json number,title,body,url
Understand what changed by reviewing the full diff against main:
git diff main...HEAD
Read the existing release note files:
docs/en/release_note/ommx-{version}.mddocs/ja/release_note/ommx-{version}.mdAppend entries to both files following the existing format:
### headings with PR link: ### Feature name ([#NNN](https://github.com/Jij-Inc/ommx/pull/NNN))## section (New Features, Bug Fixes, Breaking Changes, etc.)Show the user the diff of what was added for review.
English:
### Feature name ([#123](https://github.com/Jij-Inc/ommx/pull/123))
Description of the change from the user's perspective. Include code examples for new API.
Japanese:
### 機能名 ([#123](https://github.com/Jij-Inc/ommx/pull/123))
ユーザー視点での変更の説明。新しいAPIにはコード例を含める。
Append release note entries for the current PR to the relevant OMMX Python SDK and/or Rust SDK release notes
Use when deciding, auditing, or applying GitHub Release labels on OMMX pull requests, especially `rust`, `python`, `proto`, `lean`, `documentation`, `bug`, or `breaking change` labels for release-note generation from the actual PR diff.
Use when reviewing, designing, triaging, or managing OMMX benchmarks, CodSpeed runs or flamegraphs, performance PRs or issues, benchmark workload changes, or benchmark CI policy. Classify the measurement purpose, define the benchmark contract and cost model, validate the required scaling or profile evidence, assign a lifecycle and run policy, and keep CI cost proportional to the regression signal.
Use when triaging, labeling, closing, rewriting, or organizing GitHub issues in Jij-Inc/ommx, especially when deciding consistent issue labels, separating issue backlog labels from PR release-note labels, auditing open issues, or applying GitHub issue metadata changes.
Use when reviewing changes to Arbitrary implementations, proptest strategy parameters, or property-test generators in the OMMX Rust SDK, including changes to what a default strategy generates.
Use when reviewing OMMX Python SDK changes, PyO3 bindings under python/ommx/src, public Python API shape, pyo3-stub-gen output, generated stubs, Python-side wrappers, or tests for Python SDK behavior.