[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXK0YCB5HN9BA6WC04R277":3,"skill-same:01M6BXK0YCB5HN9BA6WC04R277":66},{"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":18,"publishedAt":38,"linkOnly":39,"markdownContent":40,"markdownBody":41,"frontMatter":42,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":6,"updatedAt":51,"install":52,"resources":65},"01M6BXK0YCB5HN9BA6WC04R277","python-sdk-review",null,"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.","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\u002Fpython-sdk-review\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37],"sdk","review","python","python sdk review","python sdk","when","stub","public","shape","behavior","changes","output","use","generated","tests","for","api","src","ommx","2026-11-10 10:12:30",false,"---\nname: python-sdk-review\ndescription: 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.\n---\n\n# Python SDK Review\n\nUse this skill to review OMMX Python SDK changes from the binding boundary\noutward: Rust\u002FPyO3 source first, generated Python surface second, runtime tests\nthird. This is not a Sphinx documentation review; use\n`.agents\u002Fskills\u002Fsphinx-docs-review\u002FSKILL.md` when the main question is Sphinx,\nAutoAPI, toctrees, or rendered documentation.\n\n## Review Order\n\n1. Identify the public Python operation.\n   - Name the user-facing class, method, function, property, or magic method.\n   - Check whether it is a stable SDK surface, an internal helper, or an\n     adapter-facing protocol.\n   - For domain operations, use `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md`\n     first and keep the Python API aligned with the owner boundary.\n   - When choosing or changing public API names or their domain meaning, use\n     [OMMX Terminology](..\u002Fommx-terminology\u002FSKILL.md).\n   - If the operation propagates Rust SDK failures or the diff touches\n     `OmmxPyResult`, `python\u002Fommx\u002Fsrc\u002Ferror.rs`, signal mappings, or binding-local\n     `map_err`, use `.agents\u002Fskills\u002Frust-error-handling\u002FSKILL.md` before choosing\n     a Python exception class.\n\n2. Review PyO3 source before generated stubs.\n   - Start from `python\u002Fommx\u002Fsrc\u002F*.rs`, not from\n     `python\u002Fommx\u002Fommx\u002F_ommx_rust\u002F__init__.pyi`.\n   - For new exports, check `python\u002Fommx\u002Fsrc\u002Flib.rs`,\n     `pyo3_stub_gen::reexport_module_members!`, and top-level Python package\n     re-exports.\n   - Treat generated stubs as evidence that the Rust binding source is modeled\n     correctly, not as the place to hide an imprecise binding type.\n\n3. Check input typing at the extraction boundary.\n   - Prefer dedicated Rust input wrapper types with `FromPyObject` and\n     `PyStubType` for public polymorphic inputs.\n   - Use type aliases such as `ToFunction`, `ToState`, or `ToSamples` when\n     users are expected to pass several supported Python shapes.\n   - Avoid accepting `PyAny` in public methods unless the input is genuinely\n     arbitrary Python data, adapter-owned, JSON-like, or intentionally opaque.\n\n4. Check output typing at the conversion boundary.\n   - Prefer a small Rust output wrapper that implements `IntoPyObject` and\n     `PyStubType` when a method returns a fixed Python object shape.\n   - Do not use `Bound\u003CPyAny>` plus `#[gen_stub(override_return_type(...))]`\n     just to make the generated `.pyi` look correct.\n   - Keep `PyAny` returns for genuinely dynamic Python values, such as arbitrary\n     attachments, adapter-owned reports, JSON payloads, trace\u002Fcontext-manager\n     objects, or APIs whose concrete Python type is intentionally not owned by\n     OMMX.\n   - If the runtime object is a non-generated Python class or dataclass, the\n     Rust wrapper may still construct that Python object in `IntoPyObject`; the\n     public PyO3 method should return the wrapper type rather than raw `PyAny`.\n\n5. Check runtime behavior and stub behavior together.\n   - Run `task python:stubgen` after PyO3 public API, docstring, or\n     `PyStubType` changes.\n   - Inspect the generated `.pyi` for the affected items and confirm imports,\n     optional defaults, overloads, and type aliases match the intended API.\n   - Add or update focused Python tests for runtime behavior, including\n     `isinstance` checks when the returned Python class matters.\n   - For user-visible text\u002FHTML\u002Ftable output, prefer snapshot tests over\n     piecemeal string fragments.\n\n## Recurring Review Checks\n\n- A correct-looking generated stub is not enough. Verify whether the Rust\n  signature itself expresses the API shape through `FromPyObject`,\n  `IntoPyObject`, `PyStubType`, `#[pyclass]`, or a type alias.\n- A public method returning `Py\u003CPyAny>`, `Bound\u003CPyAny>`, or accepting `&PyAny`\n  needs a reason. If the object shape is known, ask for a typed wrapper.\n- `#[gen_stub(override_return_type(...))]` is acceptable for exceptional\n  generated-stub limitations, not as the normal way to type a fixed return.\n- Arithmetic and magic methods often need `#[gen_stub(skip)]` or specialized\n  stub handling; review their runtime return classes and type hints together.\n- When a Python API exposes Rust-owned data plus Python convenience behavior,\n  check both ownership directions: extraction into Rust and conversion back to\n  Python.\n- Keep generated artifacts synchronized with the source change:\n  `python\u002Fommx\u002Fommx\u002F_ommx_rust\u002F__init__.pyi`,\n  generated package `__init__.py` files, and `docs\u002Fapi\u002Fapi_reference.json` when\n  stubgen updates it.\n- If the diff touches rendered docs, AutoAPI warnings, or Sphinx wiring, switch\n  to `.agents\u002Fskills\u002Fsphinx-docs-review\u002FSKILL.md` for that part.\n\n## Validation Commands\n\nUse the narrowest commands that match the diff. Python commands must run\nthrough the project environment.\n\n- After PyO3 public API or `PyStubType` changes:\n  ```\n  task python:stubgen\n  cargo check -p _ommx_rust\n  ```\n- For Python SDK behavior:\n  ```\n  uv run pytest python\u002Fommx\u002Ftests\u002F\u003Ctarget>.py\n  ```\n- For generated-file hygiene:\n  ```\n  git diff --check\n  git status -sb\n  ```\n\n## Findings\n\nLead findings with user-visible API or binding-boundary risk:\n\n- Public stub type differs from runtime behavior.\n- Public PyO3 signature uses opaque `PyAny` where a typed wrapper should own\n  extraction or conversion.\n- Generated stubs were not regenerated after a public API change.\n- Top-level Python re-exports are missing or stale.\n- Python behavior changed without focused runtime tests.\n- Output behavior changed without snapshots when the output is the feature.\n","# Python SDK Review\n\nUse this skill to review OMMX Python SDK changes from the binding boundary\noutward: Rust\u002FPyO3 source first, generated Python surface second, runtime tests\nthird. This is not a Sphinx documentation review; use\n`.agents\u002Fskills\u002Fsphinx-docs-review\u002FSKILL.md` when the main question is Sphinx,\nAutoAPI, toctrees, or rendered documentation.\n\n## Review Order\n\n1. Identify the public Python operation.\n   - Name the user-facing class, method, function, property, or magic method.\n   - Check whether it is a stable SDK surface, an internal helper, or an\n     adapter-facing protocol.\n   - For domain operations, use `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md`\n     first and keep the Python API aligned with the owner boundary.\n   - When choosing or changing public API names or their domain meaning, use\n     [OMMX Terminology](..\u002Fommx-terminology\u002FSKILL.md).\n   - If the operation propagates Rust SDK failures or the diff touches\n     `OmmxPyResult`, `python\u002Fommx\u002Fsrc\u002Ferror.rs`, signal mappings, or binding-local\n     `map_err`, use `.agents\u002Fskills\u002Frust-error-handling\u002FSKILL.md` before choosing\n     a Python exception class.\n\n2. Review PyO3 source before generated stubs.\n   - Start from `python\u002Fommx\u002Fsrc\u002F*.rs`, not from\n     `python\u002Fommx\u002Fommx\u002F_ommx_rust\u002F__init__.pyi`.\n   - For new exports, check `python\u002Fommx\u002Fsrc\u002Flib.rs`,\n     `pyo3_stub_gen::reexport_module_members!`, and top-level Python package\n     re-exports.\n   - Treat generated stubs as evidence that the Rust binding source is modeled\n     correctly, not as the place to hide an imprecise binding type.\n\n3. Check input typing at the extraction boundary.\n   - Prefer dedicated Rust input wrapper types with `FromPyObject` and\n     `PyStubType` for public polymorphic inputs.\n   - Use type aliases such as `ToFunction`, `ToState`, or `ToSamples` when\n     users are expected to pass several supported Python shapes.\n   - Avoid accepting `PyAny` in public methods unless the input is genuinely\n     arbitrary Python data, adapter-owned, JSON-like, or intentionally opaque.\n\n4. Check output typing at the conversion boundary.\n   - Prefer a small Rust output wrapper that implements `IntoPyObject` and\n     `PyStubType` when a method returns a fixed Python object shape.\n   - Do not use `Bound\u003CPyAny>` plus `#[gen_stub(override_return_type(...))]`\n     just to make the generated `.pyi` look correct.\n   - Keep `PyAny` returns for genuinely dynamic Python values, such as arbitrary\n     attachments, adapter-owned reports, JSON payloads, trace\u002Fcontext-manager\n     objects, or APIs whose concrete Python type is intentionally not owned by\n     OMMX.\n   - If the runtime object is a non-generated Python class or dataclass, the\n     Rust wrapper may still construct that Python object in `IntoPyObject`; the\n     public PyO3 method should return the wrapper type rather than raw `PyAny`.\n\n5. Check runtime behavior and stub behavior together.\n   - Run `task python:stubgen` after PyO3 public API, docstring, or\n     `PyStubType` changes.\n   - Inspect the generated `.pyi` for the affected items and confirm imports,\n     optional defaults, overloads, and type aliases match the intended API.\n   - Add or update focused Python tests for runtime behavior, including\n     `isinstance` checks when the returned Python class matters.\n   - For user-visible text\u002FHTML\u002Ftable output, prefer snapshot tests over\n     piecemeal string fragments.\n\n## Recurring Review Checks\n\n- A correct-looking generated stub is not enough. Verify whether the Rust\n  signature itself expresses the API shape through `FromPyObject`,\n  `IntoPyObject`, `PyStubType`, `#[pyclass]`, or a type alias.\n- A public method returning `Py\u003CPyAny>`, `Bound\u003CPyAny>`, or accepting `&PyAny`\n  needs a reason. If the object shape is known, ask for a typed wrapper.\n- `#[gen_stub(override_return_type(...))]` is acceptable for exceptional\n  generated-stub limitations, not as the normal way to type a fixed return.\n- Arithmetic and magic methods often need `#[gen_stub(skip)]` or specialized\n  stub handling; review their runtime return classes and type hints together.\n- When a Python API exposes Rust-owned data plus Python convenience behavior,\n  check both ownership directions: extraction into Rust and conversion back to\n  Python.\n- Keep generated artifacts synchronized with the source change:\n  `python\u002Fommx\u002Fommx\u002F_ommx_rust\u002F__init__.pyi`,\n  generated package `__init__.py` files, and `docs\u002Fapi\u002Fapi_reference.json` when\n  stubgen updates it.\n- If the diff touches rendered docs, AutoAPI warnings, or Sphinx wiring, switch\n  to `.agents\u002Fskills\u002Fsphinx-docs-review\u002FSKILL.md` for that part.\n\n## Validation Commands\n\nUse the narrowest commands that match the diff. Python commands must run\nthrough the project environment.\n\n- After PyO3 public API or `PyStubType` changes:\n  ```\n  task python:stubgen\n  cargo check -p _ommx_rust\n  ```\n- For Python SDK behavior:\n  ```\n  uv run pytest python\u002Fommx\u002Ftests\u002F\u003Ctarget>.py\n  ```\n- For generated-file hygiene:\n  ```\n  git diff --check\n  git status -sb\n  ```\n\n## Findings\n\nLead findings with user-visible API or binding-boundary risk:\n\n- Public stub type differs from runtime behavior.\n- Public PyO3 signature uses opaque `PyAny` where a typed wrapper should own\n  extraction or conversion.\n- Generated stubs were not regenerated after a public API change.\n- Top-level Python re-exports are missing or stale.\n- Python behavior changed without focused runtime tests.\n- Output behavior changed without snapshots when the output is the feature.\n",{"name":5,"description":7},"main","e78914833dc7963f9ebff7acfe211cb81d910716",".agents\u002Fskills\u002Fpython-sdk-review",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":53,"prompt":63,"zipAvailable":64},[54,57,60],{"tool":55,"command":56},"npx","npx skills add Jij-Inc\u002Fommx --skill python-sdk-review",{"tool":58,"command":59},"bunx","bunx skills add Jij-Inc\u002Fommx --skill python-sdk-review",{"tool":61,"command":62},"pnpm","pnpm dlx skills add Jij-Inc\u002Fommx --skill python-sdk-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fpython-sdk-review\u002FSKILL.md",true,[],[67,77,101,122,146,164],{"skillNo":68,"name":37,"nameZh":6,"description":69,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":38},"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",[],[37,34,73,74,75,76],"usage","distribution","guidance","placeholder",{"skillNo":78,"name":79,"nameZh":6,"description":80,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":81,"categories":82,"keywords":83,"publishedAt":38},"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",[],[84,85,86,87,88,34,89,90,91,92,93,94,95,96,97,98,99,100],"release note","release","note","git","version","true","english","entries","japanese","append","edit","read","gh","Bash","release notes","pr","notes",{"skillNo":102,"name":103,"nameZh":6,"description":104,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":105,"categories":106,"keywords":107,"publishedAt":38},"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",[],[108,20,109,110,111,112,113,114,34,115,116,31,32,117,37,118,119,120,121,35],"sphinx docs review","docs","docs review","references","correctness","pages","consistency","structure","build","technical","learning","wiring","documentation","design",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":138,"publishedAt":38},"01M6BXK7Y15AS1W95Z177MP84J","rust-module-boundary","Use when writing or reviewing Rust module structure, item visibility, public API exposure, or pub\u002Fpub(crate)\u002Fpub(super) choices in OMMX.","https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frust-module-boundary\u002FSKILL.md",[128,133],{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":134,"categoryName":135,"taxonomyType":136,"taxonomyTypeDesc":137},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[139,140,141,142,143,35,24,144,115,31,26,37,145],"rust module boundary","boundary","module","rust","super","public api","writing",{"skillNo":147,"name":148,"nameZh":6,"description":149,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":150,"categories":151,"keywords":152,"publishedAt":38},"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",[],[153,154,155,142,156,31,26,37,19,21,157,24,158,159,160,161,162,163],"error","rust error handling","error handling","map","local","signal","result","implementing","types","binding","propagation",{"skillNo":165,"name":79,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":38},"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",[],[86,84,85,170,34,171,91,93,23,37,98,99,100,142,19,21],"sdk release","relevant"]