[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXK7Y15AS1W95Z177MP84J":3,"skill-same:01M6BXK7Y15AS1W95Z177MP84J":70},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":42,"linkOnly":43,"markdownContent":44,"markdownBody":45,"frontMatter":46,"refName":47,"commitSha":48,"skillDirectory":49,"forksCount":50,"repositoryHtmlUrl":51,"repositoryHomepageUrl":52,"ownerHtmlUrl":53,"ownerBlogUrl":54,"ownerDescription":6,"updatedAt":55,"install":56,"resources":69},"01M6BXK7Y15AS1W95Z177MP84J","rust-module-boundary",null,"Use when writing or reviewing Rust module structure, item visibility, public API exposure, or pub\u002Fpub(crate)\u002Fpub(super) choices in OMMX.","Jij-Inc\u002Fommx","Jij-Inc","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F63967332?v=4","01M6BXJDRXRCD4WS61GY21G2JZ","JIJ","01M6BXJDXNE2TRZBNXPQQE5NDH",55,"Apache-2.0","https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frust-module-boundary\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41],"rust","boundary","rust module boundary","module","writing","api","ommx","public","use","structure","public api","super","when","2026-11-10 10:12:30",false,"---\nname: rust-module-boundary\ndescription: Use when writing or reviewing Rust module structure, item visibility, public API exposure, or pub\u002Fpub(crate)\u002Fpub(super) choices in OMMX.\n---\n\n# Rust Module Boundary\n\nUse this skill whenever Rust code changes introduce, remove, or review module boundaries or item visibility. This applies during implementation and code review.\n\n## Position In The Workflow\n\nUse `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md` first when a change has domain meaning. This skill is the next step: translate that responsibility model into Rust modules, ownership boundaries, and visibility.\n\n## Access Scope Design Principle\n\nWhen designing access scope, do not start from the field, method, or visibility\nkeyword that would make the current call site compile. Start from the\noperation → representation → API derivation defined as the Mandatory Design\nOrder in `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md`. That order is\nowned by the domain skill; do not restate or fork it here. This skill\ntranslates its outcome into Rust module structure and visibility.\n\nFor each operation identified there, state:\n\n- which data the operation must read;\n- which data the operation must change;\n- which smaller storage components are only implementation targets of that\n  root operation;\n- which API preserves the invariants without granting broader mutation\n  authority.\n\nDerive access scope from that analysis. Grant mutation authority only to the\nobject that owns the mathematical\u002Fdomain operation. Lower-level tables or\ncollections may expose storage primitives only for the specific row-level\neffects needed by that owner; they should not expose broad `&mut` access that\nlets sibling modules perform part of the root operation without the owner.\n\n`pub(crate)` is still an API across owner boundaries. Do not use crate-internal\nvisibility as the method for preserving invariants. Use it only when a named\nowner in another top-level module must call a narrow operation whose effect can\nbe described without exposing broader mutation authority. If the justification\nis only \"SDK users cannot call it\", make the item private or reshape the module\nboundary.\n\n## Writing Flow\n\n1. Identify the owner before choosing visibility.\n   - Name the domain abstraction or internal subsystem that owns the operation.\n   - Restate the mathematical or domain operation first, then identify which\n     data it must read or modify.\n   - Identify its callers and whether those callers are inside the same module, sibling modules, the crate, or SDK users.\n   - State the invariant or API commitment that the boundary must protect.\n\n2. Choose the narrowest visibility that matches the owner boundary.\n   - Use plain private items for implementation details inside one module.\n   - Use `pub` inside a private module when sibling code inside that private module boundary needs the item; the module privacy still protects it from the crate API.\n   - Use public crate API only when the item is an intentional SDK commitment.\n   - Use `pub(crate)` only when the item must cross top-level module boundaries in this crate and the allowed effect is narrower than the caller's full semantic operation.\n\n3. Document public owner invariants.\n   - For each public Rust struct, put the invariants it owns in the struct-level Rustdoc when possible.\n   - Name the constructor, parser, builder, or owning host API that preserves those invariants.\n   - If public fields or public mutation methods exist, the docs should make clear which values callers may set directly and which owner-level invariants still must hold.\n\n4. Avoid visibility as a shortcut.\n   - Do not use `pub(super)` or `pub(in ...)` to patch around an awkward module hierarchy.\n   - First reconsider whether the module tree should express the ownership boundary more directly.\n   - Do not expose raw registry, descriptor, config, or persistence plumbing just to make a caller convenient.\n\n5. Document crate-wide visibility.\n   - If `pub(crate)` is necessary, add a short comment or documentation explaining why the item must cross top-level module boundaries.\n   - The reason should name the owner boundary or cross-module contract, not just \"used elsewhere\".\n   - Prefer names that describe concrete storage effects, such as row\n     replacement, lifecycle movement, or table-level conversion. Avoid broad\n     names like `rewrite`, `update`, `with`, or `into_parts` unless the owning\n     abstraction genuinely exposes that whole operation.\n\n## Mechanical First Pass\n\nBefore reading the diff by hand, generate the visibility delta and review that\nlisting. Eye-scanning a large diff misses added `pub` items; a generated\nlisting does not.\n\n- Enumerate every new visible item and every new mutable access path across\n  all changed Rust sources. OMMX Rust code is not confined to `rust\u002F`; the\n  PyO3 binding crate lives under `python\u002Fommx\u002Fsrc`, so match by file type\n  rather than hard-coding a directory:\n  ```\n  git diff main...HEAD -- '*.rs' | rg '^\\+.*\\bpub\\b'\n  git diff main...HEAD -- '*.rs' | rg '^\\+.*(-> *&mut|&mut self)'\n  ```\n- When `cargo-public-api` and a nightly toolchain are available, produce the\n  public API delta of the SDK crate instead of reconstructing it from the\n  diff:\n  ```\n  cargo public-api -p ommx diff main..HEAD\n  ```\n  CI already runs cargo-semver-checks, but that only answers \"is this a semver\n  break\". The API delta answers \"which public items appeared, changed, or\n  disappeared\" — every added line is an SDK commitment that needs an owner\n  justification.\n- The diff grep only sees source text. Items generated by macros — PyO3\n  `#[pymethods]`, derive macros — never appear in it. `cargo public-api`\n  (rustdoc JSON) and rust-analyzer queries see the post-expansion API, so use\n  one of them when the change touches macro-heavy code.\n- Feed each listed item into the Review Flow below: which owner, which\n  callers, which invariant.\n\n## Review Flow\n\n1. Check that visibility follows the domain owner.\n   - For each visible item, ask which domain abstraction owns it and which callers should be allowed to use it.\n   - If the item crosses an owner boundary, verify that the boundary is intentional.\n   - When rust-analyzer is available, answer \"which callers genuinely need\n     access\" with evidence: `findReferences` on the item gives the actual\n     caller set. If every caller lives in one module, the visibility is too\n     broad — make the item private or `pub` inside a private module.\n     Graduation target for over-broad visibility: `#![warn(unreachable_pub)]`\n     and clippy's `redundant_pub_crate`, which flag items whose visibility\n     exceeds their actual reachability.\n\n2. Check for hidden API commitments.\n   - Public Rust items are SDK commitments unless they are protected by a private module boundary.\n   - Raw OCI descriptors, registry handles, config internals, and persistence helpers should not leak into public APIs unless the low-level API is explicitly intended.\n   - Public structs should document the invariants they expect callers and owner APIs to preserve; missing Rustdoc is a review risk when the struct has public fields or construction paths.\n\n3. Check for invariant bypass.\n   - A caller should not be able to mutate or construct state in a way that skips the owning abstraction's validation.\n   - Load, restore, dynamic, sealed, and Python binding paths should route through the same owner boundary when they share invariants.\n   - For every `pub(crate)` item, ask what invariant the callee can enforce\n     locally and what invariant remains owned by the caller. If the callee\n     accepts a closure or raw parts that let the caller mix these layers, treat\n     it as a boundary leak unless the owner analysis proves otherwise.\n   - Ask for evidence, not reassurance: name the validator or constructor that\n     enforces the invariant on this path, and the test that fails if it is\n     bypassed. If either is missing, that missing enforcement or missing test\n     is the finding.\n\n4. Write findings in boundary terms.\n   - State which owner boundary is being crossed or which invariant can be bypassed.\n   - Then point to the concrete visibility or module structure causing it.\n   - Recommend a module restructuring or delegation through the owning abstraction, not only a keyword change.\n   - Prefer proposing enforcement — a narrower type, a private module, a\n     validator asserted by property tests — over a prose warning; see the\n     graduation policy in `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md`.\n\n## Checklist\n\n- Which domain abstraction or subsystem owns this item?\n- Which callers genuinely need access?\n- Is this an SDK commitment, crate-internal contract, private-module contract, or implementation detail?\n- Does each public struct document its owned invariants and intended construction\u002Fmutation paths?\n- Does the module tree express that boundary without `pub(super)` or `pub(in ...)`?\n- If `pub(crate)` is used, is the cross-module reason documented and is the exposed effect narrow enough?\n- Can any visible item let callers bypass validation, persistence, or source-of-truth invariants?\n- Did you generate the visibility delta (`pub` grep or `cargo public-api diff`)\n  instead of relying on eye-scanning the diff?\n- For each new visible item, can you point to the validator or constructor that\n  protects its invariants and the test that fails on bypass? Either gap is a\n  finding on its own.\n","# Rust Module Boundary\n\nUse this skill whenever Rust code changes introduce, remove, or review module boundaries or item visibility. This applies during implementation and code review.\n\n## Position In The Workflow\n\nUse `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md` first when a change has domain meaning. This skill is the next step: translate that responsibility model into Rust modules, ownership boundaries, and visibility.\n\n## Access Scope Design Principle\n\nWhen designing access scope, do not start from the field, method, or visibility\nkeyword that would make the current call site compile. Start from the\noperation → representation → API derivation defined as the Mandatory Design\nOrder in `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md`. That order is\nowned by the domain skill; do not restate or fork it here. This skill\ntranslates its outcome into Rust module structure and visibility.\n\nFor each operation identified there, state:\n\n- which data the operation must read;\n- which data the operation must change;\n- which smaller storage components are only implementation targets of that\n  root operation;\n- which API preserves the invariants without granting broader mutation\n  authority.\n\nDerive access scope from that analysis. Grant mutation authority only to the\nobject that owns the mathematical\u002Fdomain operation. Lower-level tables or\ncollections may expose storage primitives only for the specific row-level\neffects needed by that owner; they should not expose broad `&mut` access that\nlets sibling modules perform part of the root operation without the owner.\n\n`pub(crate)` is still an API across owner boundaries. Do not use crate-internal\nvisibility as the method for preserving invariants. Use it only when a named\nowner in another top-level module must call a narrow operation whose effect can\nbe described without exposing broader mutation authority. If the justification\nis only \"SDK users cannot call it\", make the item private or reshape the module\nboundary.\n\n## Writing Flow\n\n1. Identify the owner before choosing visibility.\n   - Name the domain abstraction or internal subsystem that owns the operation.\n   - Restate the mathematical or domain operation first, then identify which\n     data it must read or modify.\n   - Identify its callers and whether those callers are inside the same module, sibling modules, the crate, or SDK users.\n   - State the invariant or API commitment that the boundary must protect.\n\n2. Choose the narrowest visibility that matches the owner boundary.\n   - Use plain private items for implementation details inside one module.\n   - Use `pub` inside a private module when sibling code inside that private module boundary needs the item; the module privacy still protects it from the crate API.\n   - Use public crate API only when the item is an intentional SDK commitment.\n   - Use `pub(crate)` only when the item must cross top-level module boundaries in this crate and the allowed effect is narrower than the caller's full semantic operation.\n\n3. Document public owner invariants.\n   - For each public Rust struct, put the invariants it owns in the struct-level Rustdoc when possible.\n   - Name the constructor, parser, builder, or owning host API that preserves those invariants.\n   - If public fields or public mutation methods exist, the docs should make clear which values callers may set directly and which owner-level invariants still must hold.\n\n4. Avoid visibility as a shortcut.\n   - Do not use `pub(super)` or `pub(in ...)` to patch around an awkward module hierarchy.\n   - First reconsider whether the module tree should express the ownership boundary more directly.\n   - Do not expose raw registry, descriptor, config, or persistence plumbing just to make a caller convenient.\n\n5. Document crate-wide visibility.\n   - If `pub(crate)` is necessary, add a short comment or documentation explaining why the item must cross top-level module boundaries.\n   - The reason should name the owner boundary or cross-module contract, not just \"used elsewhere\".\n   - Prefer names that describe concrete storage effects, such as row\n     replacement, lifecycle movement, or table-level conversion. Avoid broad\n     names like `rewrite`, `update`, `with`, or `into_parts` unless the owning\n     abstraction genuinely exposes that whole operation.\n\n## Mechanical First Pass\n\nBefore reading the diff by hand, generate the visibility delta and review that\nlisting. Eye-scanning a large diff misses added `pub` items; a generated\nlisting does not.\n\n- Enumerate every new visible item and every new mutable access path across\n  all changed Rust sources. OMMX Rust code is not confined to `rust\u002F`; the\n  PyO3 binding crate lives under `python\u002Fommx\u002Fsrc`, so match by file type\n  rather than hard-coding a directory:\n  ```\n  git diff main...HEAD -- '*.rs' | rg '^\\+.*\\bpub\\b'\n  git diff main...HEAD -- '*.rs' | rg '^\\+.*(-> *&mut|&mut self)'\n  ```\n- When `cargo-public-api` and a nightly toolchain are available, produce the\n  public API delta of the SDK crate instead of reconstructing it from the\n  diff:\n  ```\n  cargo public-api -p ommx diff main..HEAD\n  ```\n  CI already runs cargo-semver-checks, but that only answers \"is this a semver\n  break\". The API delta answers \"which public items appeared, changed, or\n  disappeared\" — every added line is an SDK commitment that needs an owner\n  justification.\n- The diff grep only sees source text. Items generated by macros — PyO3\n  `#[pymethods]`, derive macros — never appear in it. `cargo public-api`\n  (rustdoc JSON) and rust-analyzer queries see the post-expansion API, so use\n  one of them when the change touches macro-heavy code.\n- Feed each listed item into the Review Flow below: which owner, which\n  callers, which invariant.\n\n## Review Flow\n\n1. Check that visibility follows the domain owner.\n   - For each visible item, ask which domain abstraction owns it and which callers should be allowed to use it.\n   - If the item crosses an owner boundary, verify that the boundary is intentional.\n   - When rust-analyzer is available, answer \"which callers genuinely need\n     access\" with evidence: `findReferences` on the item gives the actual\n     caller set. If every caller lives in one module, the visibility is too\n     broad — make the item private or `pub` inside a private module.\n     Graduation target for over-broad visibility: `#![warn(unreachable_pub)]`\n     and clippy's `redundant_pub_crate`, which flag items whose visibility\n     exceeds their actual reachability.\n\n2. Check for hidden API commitments.\n   - Public Rust items are SDK commitments unless they are protected by a private module boundary.\n   - Raw OCI descriptors, registry handles, config internals, and persistence helpers should not leak into public APIs unless the low-level API is explicitly intended.\n   - Public structs should document the invariants they expect callers and owner APIs to preserve; missing Rustdoc is a review risk when the struct has public fields or construction paths.\n\n3. Check for invariant bypass.\n   - A caller should not be able to mutate or construct state in a way that skips the owning abstraction's validation.\n   - Load, restore, dynamic, sealed, and Python binding paths should route through the same owner boundary when they share invariants.\n   - For every `pub(crate)` item, ask what invariant the callee can enforce\n     locally and what invariant remains owned by the caller. If the callee\n     accepts a closure or raw parts that let the caller mix these layers, treat\n     it as a boundary leak unless the owner analysis proves otherwise.\n   - Ask for evidence, not reassurance: name the validator or constructor that\n     enforces the invariant on this path, and the test that fails if it is\n     bypassed. If either is missing, that missing enforcement or missing test\n     is the finding.\n\n4. Write findings in boundary terms.\n   - State which owner boundary is being crossed or which invariant can be bypassed.\n   - Then point to the concrete visibility or module structure causing it.\n   - Recommend a module restructuring or delegation through the owning abstraction, not only a keyword change.\n   - Prefer proposing enforcement — a narrower type, a private module, a\n     validator asserted by property tests — over a prose warning; see the\n     graduation policy in `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md`.\n\n## Checklist\n\n- Which domain abstraction or subsystem owns this item?\n- Which callers genuinely need access?\n- Is this an SDK commitment, crate-internal contract, private-module contract, or implementation detail?\n- Does each public struct document its owned invariants and intended construction\u002Fmutation paths?\n- Does the module tree express that boundary without `pub(super)` or `pub(in ...)`?\n- If `pub(crate)` is used, is the cross-module reason documented and is the exposed effect narrow enough?\n- Can any visible item let callers bypass validation, persistence, or source-of-truth invariants?\n- Did you generate the visibility delta (`pub` grep or `cargo public-api diff`)\n  instead of relying on eye-scanning the diff?\n- For each new visible item, can you point to the validator or constructor that\n  protects its invariants and the test that fails on bypass? Either gap is a\n  finding on its own.\n",{"name":5,"description":7},"main","abab1660a3718eb5ff83cb7e2a4d4d09975a84ee",".agents\u002Fskills\u002Frust-module-boundary",3,"https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx","https:\u002F\u002Fjij-inc-ommx.readthedocs-hosted.com\u002Fen\u002Flatest\u002F","https:\u002F\u002Fgithub.com\u002FJij-Inc","https:\u002F\u002Fwww.j-ij.com\u002F","2026-11-14 16:34:14",{"source":8,"skillName":5,"commands":57,"prompt":67,"zipAvailable":68},[58,61,64],{"tool":59,"command":60},"npx","npx skills add Jij-Inc\u002Fommx --skill rust-module-boundary",{"tool":62,"command":63},"bunx","bunx skills add Jij-Inc\u002Fommx --skill rust-module-boundary",{"tool":65,"command":66},"pnpm","pnpm dlx skills add Jij-Inc\u002Fommx --skill rust-module-boundary","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frust-module-boundary\u002FSKILL.md",true,[],[71,82,106,128,148,157],{"skillNo":72,"name":35,"nameZh":6,"description":73,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":74,"categories":75,"keywords":76,"publishedAt":42},"01M6BXKF5YXBGN5STHX39AJV9S","Placeholder for verifying OMMX skill distribution. OMMX usage guidance will be provided separately.","https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002Frust\u002Fommx\u002Fagent_plugin\u002Fplugins\u002Fommx\u002Fskills\u002Fommx\u002FSKILL.md",[],[35,77,78,79,80,81],"guidance","distribution","usage","for","placeholder",{"skillNo":83,"name":84,"nameZh":6,"description":85,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":86,"categories":87,"keywords":88,"publishedAt":42},"01M6BXKD3F5H9MRJZV4BPYHQQH","release-note","Append release note entries for the current PR to both English and Japanese release notes","https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Frelease-note\u002FSKILL.md",[],[89,90,91,92,93,94,95,80,96,97,98,99,100,101,102,103,104,105],"release note","release","note","release notes","version","true","entries","read","edit","japanese","append","Bash","english","gh","git","pr","notes",{"skillNo":107,"name":108,"nameZh":6,"description":109,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":110,"categories":111,"keywords":112,"publishedAt":42},"01M6BXKAHANG4WVSH5GEYRV4VB","sphinx-docs-review","Review OMMX documentation publication correctness: Sphinx\u002Fdocutils build and rendering failures, unresolved references, generated API wiring, and consistency of PyO3 docstrings, exports, stubs, and API pages. Use for those technical concerns, not for Book prose structure, reader prerequisites, or learning-path design alone.","https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsphinx-docs-review\u002FSKILL.md",[],[113,114,115,116,117,118,119,37,120,121,80,122,123,34,124,35,125,126,38,127],"docs","docs review","sphinx docs review","review","generated","wiring","correctness","technical","pages","consistency","learning","design","documentation","build","references",{"skillNo":129,"name":130,"nameZh":6,"description":131,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":132,"categories":133,"keywords":134,"publishedAt":42},"01M6BXK5SHD9FPD079K336Y02T","rust-error-handling","Use when designing, implementing, or reviewing OMMX Rust SDK fallible APIs, public error or signal types, anyhow error chains, `ommx::Result`, PyO3 `OmmxPyResult` conversions, Python exception mappings, or binding-local `map_err` and `?` propagation.","https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frust-error-handling\u002FSKILL.md",[],[135,136,29,137,138,41,139,36,140,141,37,142,143,144,145,146,147,35],"error","error handling","rust error handling","types","signal","binding","propagation","map","local","implementing","result","python","sdk",{"skillNo":149,"name":84,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":153,"publishedAt":42},"01M6BXK38JXA5DQMR239YF93NF","Append release note entries for the current PR to the relevant OMMX Python SDK and\u002For Rust SDK release notes","https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frelease-note\u002FSKILL.md",[],[91,90,89,29,147,104,92,105,35,146,99,154,95,155,80,156],"sdk release","python sdk","relevant",{"skillNo":158,"name":159,"nameZh":6,"description":160,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":161,"categories":162,"keywords":163,"publishedAt":42},"01M6BXK0YCB5HN9BA6WC04R277","python-sdk-review","Use when reviewing OMMX Python SDK changes, PyO3 bindings under python\u002Fommx\u002Fsrc, public Python API shape, pyo3-stub-gen output, generated stubs, Python-side wrappers, or tests for Python SDK behavior.","https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpython-sdk-review\u002FSKILL.md",[],[147,155,164,116,146,165,41,166,36,167,168,169,37,117,170,80,34,171,35],"python sdk review","behavior","stub","shape","changes","output","tests","src"]