メニュー
Use this skill when the user says open a PR, create a pull request, make a PR, or submit this work as a PR.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/webern/mx --skill mx-open-prコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
You must read and use this skill when writing comments in the code and when documenting this library.
Use when adding a MusicXML feature to mx::api, exposing a feature that is currently inaccessible, or explaining whether and how mx::api supports a feature.
Use this skill to explain, in plain language, what is wrong with the `mx::api` round-trip and what it needs next. It drives the failure classifier (dump -> classify) over the corpus, then reads build/api/classified.json and turns it into a prioritized, human-readable worklist grouped by failure shape (crashes, instant wins, small fix-sets, reorder-blocked, high-frequency drops). Invoke for requests like "what's broken about mx::api", "explain the round-trip failures", "what does the api need next", or "triage the api round-trip".
SKILL.md を表示中
| name | mx-open-pr |
| description | Use this skill when the user says open a PR, create a pull request, make a PR, or submit this work as a PR. |
| argument-hint | <prompt> |
| disable-model-invocation | false |
| user-invocable | true |
Use <prompt> and your context to understand what the PR is about. Check to see if there is
documentation on the issue available in docs/ai/api-feature-audit.md (which might be the case if
it was previously documented by an api-feature-audit).
Use gh for GitHub interactions.
Search the open issues for one that this PR would close or that it is related to. Make a list of issues that it closes and issues that is related to. It might also be related to other PRs.
When writing the PR, the title should be lowercase and start with one keyword, e.g.
Look at the labels on GitHub, choose the ones that match the pr best.
Write a PR body. Keep it tight and human-readable, but with enough information to understand what was done and why.
Determine from the original prompt whether the user wanted you to YOLO and open or whether the user wanted to see a draft first.
When ready, create the pr and note the pr number. Make sure the PR body contains references to issues closed and issues/PRs related (if any).
No self-attribution in the PR body; add the ai label instead.
Do not use excessive bold and italics in the PR body. Go easy on the keywords since they will add a lot of backtick formatting as well.
Template/sample:
## Human Summary
TODO: human writes here
## Summary
`accidentalMap` in `Converter.cpp` was missing the entry for `sharpSharp`. Added a single item to the map so that the
double sharps are now fully supported in `mx::api`.
## Testing
- [x] `SharpSharp_PitchData` fails before the fix, passes after
- [x] All PitchData tests pass (`*_PitchData`: 37 assertions in 8 test cases)
- [x] Full test suite passes (3917 assertions in 219 test cases)
## References
- Closes #123
- Progresses #456
- Fixes a bug introduced in #789