メニュー
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.
デフォルトでは、最初にソースを確認する Prompt が選択されています。直接コマンドに切り替えるか、ローカルコピーをダウンロードすることもできます。
インストールを決める前に、SKILL.md と SkillsMP に表示されている付属ファイルをお読みください。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
直接コマンドでは確認用 Prompt が省略されます。実行前にソースを確認してください。
npx skills add https://github.com/webern/mx --skill mx-api-add-featureコマンドは1行のまま表示されます。コピー前に横へスクロールして全体を確認してください。
ローカルで確認しますか？SkillsMP が現在取得できるファイルをダウンロードできます。
You must read and use this skill when writing comments in the code and when documenting this library.
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".
The mx::api design doctrine. You MUST read this before designing or changing anything in the mx::api layer: adding or reshaping public types in src/include/mx/api/, wiring them through mx::impl, writing comments in api headers, or reviewing any of the above.
SKILL.md を表示中
| name | mx-api-add-feature |
| description | 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. |
| argument-hint | <feature or request> |
| disable-model-invocation | false |
| user-invocable | true |
mx::api featureRead the mx-api-doctrine skill before designing, implementing, or reviewing the change.
Establish the requested user-facing behavior before choosing an implementation:
mx::api already represents the feature under a different shape or name.mx::core types, which always implement the requested features.Choose an api shape using the doctrine and precedent rather than mirroring MusicXML's shape. Keep the change focused on the requested behavior, but include whatever representation is needed to make that behavior sound.
Feature work commonly touches:
src/include/mx/api/src/private/mx/impl/*Reader* or *Functions*src/private/mx/impl/*Writer* or *Functions*src/private/mx/impl/Converter.*src/private/mxtest/api/These are landmarks, not a checklist. Follow the closest existing feature through both translation directions and change only the files the design requires. Do not edit generated core files by hand.
make api-roundtrip-discover to see if you have unlocked a
file. If so, add it to the round-trip baseline src/private/mxtest/api/roundtrip-baseline.txt. If
your changes did not unlock a file, still add it and note that it was discovered already passing.If your reader and writer functions seem complex, add testing. Here are some ideas:
ScoreData round trip with mxtest::roundTrip. Probe the ScoreData values in the
unit test.mxtest::toXml and mxtest::fromXmlRun the applicable gates from AGENTS.md; api feature work normally includes make api-test,
make api-roundtrip, and make fmt.
If the user asks to open a pull request, use the mx-open-pr skill.