[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXKAHANG4WVSH5GEYRV4VB":3,"skill-same:01M6BXKAHANG4WVSH5GEYRV4VB":67},{"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":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":49,"ownerHtmlUrl":50,"ownerBlogUrl":51,"ownerDescription":6,"updatedAt":52,"install":53,"resources":66},"01M6BXKAHANG4WVSH5GEYRV4VB","sphinx-docs-review",null,"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.","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\u002Fsphinx-docs-review\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"review","docs","docs review","sphinx docs review","wiring","design","for","consistency","correctness","pages","structure","build","references","use","generated","technical","ommx","learning","api","documentation","2026-11-10 10:12:30",false,"---\nname: sphinx-docs-review\ndescription: \"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.\"\n---\n\n# Sphinx Docs Review\n\nCheck whether handwritten documentation and public API declarations are\nfaithfully exposed in generated references and rendered output. This is a\ntechnical publication workflow, not a general Book-content review.\n\nSelect it for a build\u002Frender\u002Flink failure or a change to the documentation\ngeneration pipeline. A file being under `docs\u002F` is not sufficient by itself.\nFor example, a PyO3 docstring parse failure needs this workflow; reordering a\nTutorial's explanation of feasibility does not.\n\nReader prerequisites, concept order, cognitive load, and independent reading\npaths belong to `book-reading-review`. Use both only when the request actually\nincludes both concerns; neither skill requires loading the other or running\nits checks merely because documentation changed.\n\nTreat generated files as evidence of the handwritten source\u002Fconfiguration, not\nas the first review surface. Start from the owner of the documentation behavior,\nthen sample generated artifacts to confirm the behavior is reflected correctly.\n\n## Review Order\n\n1. Identify the technical publication surface affected.\n   - Rendered Book source: the relevant files under `docs\u002Fen` or `docs\u002Fja`\n     when inspecting directives, API roles, toctrees, links, or rendering.\n   - API reference: `docs\u002Fapi`, `docs\u002Fconf_base.py`,\n     `docs\u002Fapi\u002Fpyo3_stub_gen_ext.py`, AutoAPI configuration, and generated API\n     item pages.\n   - Python binding docs\u002Fstubs: `python\u002Fommx\u002Fsrc\u002F*.rs`,\n     `python\u002Fommx\u002Fsrc\u002Fdocstrings\u002F`,\n     `python\u002Fommx\u002Fsrc\u002Flib.rs`, `python\u002Fommx\u002Fsrc\u002Fbin\u002Fstub_gen.rs`,\n     `python\u002Fommx\u002Fpyproject.toml`, `python\u002Fommx\u002Fommx\u002F_ommx_rust\u002F__init__.pyi`,\n     and generated `__init__.py` files.\n\n2. Review handwritten sources before generated artifacts.\n   - For wiring or reference problems, check the relevant entrypoints\u002Ftoctrees:\n     `docs\u002Fapi\u002Findex.rst`, `docs\u002Fconf_base.py`, `docs\u002Fen\u002Findex.md`,\n     `docs\u002Fja\u002Findex.md`.\n   - For PyO3-backed API changes, check `pyo3_stub_gen::reexport_module_members!`\n     in `python\u002Fommx\u002Fsrc\u002Flib.rs` and `[tool.pyo3-stub-gen]` in\n     `python\u002Fommx\u002Fpyproject.toml`.\n   - For docstring changes, review the Rust\u002FPython source docstrings and their\n     included Markdown that feed generated stubs and `docs\u002Fapi\u002Fapi_reference.json`.\n\n3. Verify generated artifacts for consistency, not prose quality.\n   - For API\u002Fdocstring generation changes, confirm the applicable generated\n     files changed together:\n     `python\u002Fommx\u002Fommx\u002F_ommx_rust\u002F__init__.pyi`,\n     generated package `__init__.py` files, `docs\u002Fapi\u002Fapi_reference.json`,\n     `docs\u002Fapi\u002F*.rst`, and `docs\u002Fapi\u002F_items\u002F*.rst`.\n   - Check for stale generated files that should have been deleted, especially\n     old module\u002Fpackage names after public API moves:\n     ```\n     git ls-files docs\u002Fapi docs\u002Fapi\u002F_items | rg 'old-name|ommx\\.v1'\n     rg -n '\"module\": \"old-name\"|\"qualified_name\": \"old-name' docs\u002Fapi\u002Fapi_reference.json\n     ```\n   - Do not line-review large generated JSON diffs except to confirm module\n     names, item names, and docstring content are sourced from the expected\n     handwritten change.\n\n4. Separate Python import namespace from protobuf\u002Fmedia namespace.\n   - `ommx.v1` may be correct in protobuf wire formats, media types, annotation\n     namespaces, and historical migration examples.\n   - `ommx.v1` is suspect in Python SDK imports, generated API package names,\n     examples showing the current API, adapter code, and new tests.\n\n5. Review Sphinx\u002Fdocutils failure modes explicitly.\n   - A missing toctree entry can hide the next docstring parse warning; rebuild\n     after each wiring fix.\n   - Prefer reST field syntax such as `:param name:` for exported Python\n     docstrings when AutoAPI\u002Fdocutils parse stability matters.\n   - Check for `toc.not_included`, unexpected indentation, block quotes missing\n     blank lines, duplicate labels, and unresolved class\u002Fmethod references.\n\n## Markdown Docstring Sources\n\nKeep external Python binding docstrings in `python\u002Fommx\u002Fsrc\u002Fdocstrings\u002F`, using\npublic Python module names as directories and the public object name, with its\noriginal capitalization, as the filename. For example, `ommx.ConstraintCollection`\nuses `ommx\u002FConstraintCollection.md`, and `ommx.experiment.Experiment` uses\n`ommx\u002Fexperiment\u002FExperiment.md`. An external method docstring uses a filename such\nas `ommx\u002FInstance.evaluate.md`. Resolve names from public exports, not Rust type\nnames or the internal `ommx._ommx_rust` module.\n\nUse Markdown for long explanations and keep short descriptions inline in `\u002F\u002F\u002F`.\nIn Markdown sources, wrap Python REPL examples in `pycon` code fences so Markdown\nand clippy do not interpret `>>>` as block quotes. Leave a blank line before the\nclosing fence so Python doctest does not treat it as expected output.\nEach documented API has one entry source, normally one complete Markdown file.\nPrefer linking to the API that owns a shared explanation. If splitting an entry\nbecomes useful, prefix its fragments with the owning API name; choose separators\nand suffixes when a concrete split is needed rather than introducing speculative\nfragment conventions now.\n\nFeed the same complete text to runtime docstrings and stub\u002Freference metadata.\nIf fragments are introduced, compose them before those consumers; Sphinx-only\nincludes would leave `help()` and runtime doctests with incomplete documentation.\nWhen moving a source, update its includes, direct test readers, and any manifest\nsource paths together.\n\nUse `#[doc = include_str!(\"docstrings\u002Fommx\u002FPublicClass.md\")]` with the normal\n`gen_stub_pyclass` or `gen_stub_pymethods` macros. The workspace requires\n`pyo3-stub-gen` 0.23.2 or later, which preserves `include_str!` and `concat!`\nexpressions in generated metadata. For classes with a custom `PyStubType`, use\n`gen_stub_pyclass(skip_stub_type)` and retain their runtime type registration;\npreserve any explicit stub module. Manual registration may still be needed for\nmetadata the derive cannot express, such as virtual Mapping bases. Compare the\ncomplete Markdown with runtime docstrings, generated stubs, and API metadata.\n\n## Validation Commands\n\nUse the narrowest commands that match the diff. Python commands must run through\nthe project environment.\n\nBook code is explanatory pseudocode: review its meaning, without requiring or\nclaiming execution. Working API examples belong in Reference docstrings checked\nby `python\u002Fommx\u002Ftests\u002Ftest_doctests.py`; runnable end-to-end workflows belong\nin standalone Examples and their existing tests. This separation does not\nauthorize disabling, weakening, or adding skips to existing Notebook tests.\nDo not add Notebook reruns or enable execution for a Book review. An HTML build\nverifies publication, not code execution.\n\n- After PyO3 public API or docstring changes:\n  ```\n  task python:stubgen\n  ```\n- When API examples are added, changed, or moved from the Book, rebuild the\n  current SDK before checking the affected Reference doctests. Stub generation\n  alone does not refresh the imported extension's runtime docstrings. From the\n  repository root, select the affected docstring owners with `-k`; for example,\n  for changes to `Instance`:\n  ```\n  task python:sync\n  uv run --no-sync pytest -vv python\u002Fommx\u002Ftests\u002Ftest_doctests.py -k 'ommx.Instance'\n  ```\n  Use `task python:ommx:pytest-doctest` when the full doctest suite is appropriate.\n  Report the selected doctests separately from publication checks; neither a\n  generated example nor a successful HTML build establishes execution.\n- Build docs as warnings-as-errors:\n  ```\n  uv run sphinx-build -b html -W --keep-going docs\u002Fen docs\u002Fen\u002F_build\u002Fhtml\n  uv run sphinx-build -b html -W --keep-going docs\u002Fja docs\u002Fja\u002F_build\u002Fhtml\n  ```\n- Check generated-file hygiene:\n  ```\n  git diff --check\n  git status -sb\n  git ls-files docs\u002Fapi docs\u002Fapi\u002F_items | rg 'ommx\\.v1|old-package-name'\n  ```\n- For import-surface migrations, search both runtime and docs:\n  ```\n  rg -n 'from ommx\\.v1|import ommx\\.v1|ommx\\.v1\\.' python docs\n  ```\n\nWhen reviewing CI failures, fetch the exact failing Sphinx or doctest log before\nchanging docs. If a doctest imports packages by discovery, check whether a\nsentinel package is intentionally import-failing for migration guidance.\n\n## Findings\n\nLead review findings with user-visible publication risk:\n\n- Missing or stale API reference entry.\n- Generated artifacts not refreshed from the handwritten source.\n- Current examples import an obsolete public API.\n- Migration docs confuse Python import namespaces with protobuf wire namespaces.\n- Sphinx build warnings that would fail CI.\n- Docstrings that render incorrectly or break AutoAPI\u002Fdocutils parsing.\n\nKeep generated-diff summaries secondary. A large generated diff is acceptable\nwhen the owner configuration and regeneration path are correct.\nSuccessful generation or a warning-free build does not establish that a reader\ncan understand the page; report only the technical properties checked here.\n","# Sphinx Docs Review\n\nCheck whether handwritten documentation and public API declarations are\nfaithfully exposed in generated references and rendered output. This is a\ntechnical publication workflow, not a general Book-content review.\n\nSelect it for a build\u002Frender\u002Flink failure or a change to the documentation\ngeneration pipeline. A file being under `docs\u002F` is not sufficient by itself.\nFor example, a PyO3 docstring parse failure needs this workflow; reordering a\nTutorial's explanation of feasibility does not.\n\nReader prerequisites, concept order, cognitive load, and independent reading\npaths belong to `book-reading-review`. Use both only when the request actually\nincludes both concerns; neither skill requires loading the other or running\nits checks merely because documentation changed.\n\nTreat generated files as evidence of the handwritten source\u002Fconfiguration, not\nas the first review surface. Start from the owner of the documentation behavior,\nthen sample generated artifacts to confirm the behavior is reflected correctly.\n\n## Review Order\n\n1. Identify the technical publication surface affected.\n   - Rendered Book source: the relevant files under `docs\u002Fen` or `docs\u002Fja`\n     when inspecting directives, API roles, toctrees, links, or rendering.\n   - API reference: `docs\u002Fapi`, `docs\u002Fconf_base.py`,\n     `docs\u002Fapi\u002Fpyo3_stub_gen_ext.py`, AutoAPI configuration, and generated API\n     item pages.\n   - Python binding docs\u002Fstubs: `python\u002Fommx\u002Fsrc\u002F*.rs`,\n     `python\u002Fommx\u002Fsrc\u002Fdocstrings\u002F`,\n     `python\u002Fommx\u002Fsrc\u002Flib.rs`, `python\u002Fommx\u002Fsrc\u002Fbin\u002Fstub_gen.rs`,\n     `python\u002Fommx\u002Fpyproject.toml`, `python\u002Fommx\u002Fommx\u002F_ommx_rust\u002F__init__.pyi`,\n     and generated `__init__.py` files.\n\n2. Review handwritten sources before generated artifacts.\n   - For wiring or reference problems, check the relevant entrypoints\u002Ftoctrees:\n     `docs\u002Fapi\u002Findex.rst`, `docs\u002Fconf_base.py`, `docs\u002Fen\u002Findex.md`,\n     `docs\u002Fja\u002Findex.md`.\n   - For PyO3-backed API changes, check `pyo3_stub_gen::reexport_module_members!`\n     in `python\u002Fommx\u002Fsrc\u002Flib.rs` and `[tool.pyo3-stub-gen]` in\n     `python\u002Fommx\u002Fpyproject.toml`.\n   - For docstring changes, review the Rust\u002FPython source docstrings and their\n     included Markdown that feed generated stubs and `docs\u002Fapi\u002Fapi_reference.json`.\n\n3. Verify generated artifacts for consistency, not prose quality.\n   - For API\u002Fdocstring generation changes, confirm the applicable generated\n     files changed together:\n     `python\u002Fommx\u002Fommx\u002F_ommx_rust\u002F__init__.pyi`,\n     generated package `__init__.py` files, `docs\u002Fapi\u002Fapi_reference.json`,\n     `docs\u002Fapi\u002F*.rst`, and `docs\u002Fapi\u002F_items\u002F*.rst`.\n   - Check for stale generated files that should have been deleted, especially\n     old module\u002Fpackage names after public API moves:\n     ```\n     git ls-files docs\u002Fapi docs\u002Fapi\u002F_items | rg 'old-name|ommx\\.v1'\n     rg -n '\"module\": \"old-name\"|\"qualified_name\": \"old-name' docs\u002Fapi\u002Fapi_reference.json\n     ```\n   - Do not line-review large generated JSON diffs except to confirm module\n     names, item names, and docstring content are sourced from the expected\n     handwritten change.\n\n4. Separate Python import namespace from protobuf\u002Fmedia namespace.\n   - `ommx.v1` may be correct in protobuf wire formats, media types, annotation\n     namespaces, and historical migration examples.\n   - `ommx.v1` is suspect in Python SDK imports, generated API package names,\n     examples showing the current API, adapter code, and new tests.\n\n5. Review Sphinx\u002Fdocutils failure modes explicitly.\n   - A missing toctree entry can hide the next docstring parse warning; rebuild\n     after each wiring fix.\n   - Prefer reST field syntax such as `:param name:` for exported Python\n     docstrings when AutoAPI\u002Fdocutils parse stability matters.\n   - Check for `toc.not_included`, unexpected indentation, block quotes missing\n     blank lines, duplicate labels, and unresolved class\u002Fmethod references.\n\n## Markdown Docstring Sources\n\nKeep external Python binding docstrings in `python\u002Fommx\u002Fsrc\u002Fdocstrings\u002F`, using\npublic Python module names as directories and the public object name, with its\noriginal capitalization, as the filename. For example, `ommx.ConstraintCollection`\nuses `ommx\u002FConstraintCollection.md`, and `ommx.experiment.Experiment` uses\n`ommx\u002Fexperiment\u002FExperiment.md`. An external method docstring uses a filename such\nas `ommx\u002FInstance.evaluate.md`. Resolve names from public exports, not Rust type\nnames or the internal `ommx._ommx_rust` module.\n\nUse Markdown for long explanations and keep short descriptions inline in `\u002F\u002F\u002F`.\nIn Markdown sources, wrap Python REPL examples in `pycon` code fences so Markdown\nand clippy do not interpret `>>>` as block quotes. Leave a blank line before the\nclosing fence so Python doctest does not treat it as expected output.\nEach documented API has one entry source, normally one complete Markdown file.\nPrefer linking to the API that owns a shared explanation. If splitting an entry\nbecomes useful, prefix its fragments with the owning API name; choose separators\nand suffixes when a concrete split is needed rather than introducing speculative\nfragment conventions now.\n\nFeed the same complete text to runtime docstrings and stub\u002Freference metadata.\nIf fragments are introduced, compose them before those consumers; Sphinx-only\nincludes would leave `help()` and runtime doctests with incomplete documentation.\nWhen moving a source, update its includes, direct test readers, and any manifest\nsource paths together.\n\nUse `#[doc = include_str!(\"docstrings\u002Fommx\u002FPublicClass.md\")]` with the normal\n`gen_stub_pyclass` or `gen_stub_pymethods` macros. The workspace requires\n`pyo3-stub-gen` 0.23.2 or later, which preserves `include_str!` and `concat!`\nexpressions in generated metadata. For classes with a custom `PyStubType`, use\n`gen_stub_pyclass(skip_stub_type)` and retain their runtime type registration;\npreserve any explicit stub module. Manual registration may still be needed for\nmetadata the derive cannot express, such as virtual Mapping bases. Compare the\ncomplete Markdown with runtime docstrings, generated stubs, and API metadata.\n\n## Validation Commands\n\nUse the narrowest commands that match the diff. Python commands must run through\nthe project environment.\n\nBook code is explanatory pseudocode: review its meaning, without requiring or\nclaiming execution. Working API examples belong in Reference docstrings checked\nby `python\u002Fommx\u002Ftests\u002Ftest_doctests.py`; runnable end-to-end workflows belong\nin standalone Examples and their existing tests. This separation does not\nauthorize disabling, weakening, or adding skips to existing Notebook tests.\nDo not add Notebook reruns or enable execution for a Book review. An HTML build\nverifies publication, not code execution.\n\n- After PyO3 public API or docstring changes:\n  ```\n  task python:stubgen\n  ```\n- When API examples are added, changed, or moved from the Book, rebuild the\n  current SDK before checking the affected Reference doctests. Stub generation\n  alone does not refresh the imported extension's runtime docstrings. From the\n  repository root, select the affected docstring owners with `-k`; for example,\n  for changes to `Instance`:\n  ```\n  task python:sync\n  uv run --no-sync pytest -vv python\u002Fommx\u002Ftests\u002Ftest_doctests.py -k 'ommx.Instance'\n  ```\n  Use `task python:ommx:pytest-doctest` when the full doctest suite is appropriate.\n  Report the selected doctests separately from publication checks; neither a\n  generated example nor a successful HTML build establishes execution.\n- Build docs as warnings-as-errors:\n  ```\n  uv run sphinx-build -b html -W --keep-going docs\u002Fen docs\u002Fen\u002F_build\u002Fhtml\n  uv run sphinx-build -b html -W --keep-going docs\u002Fja docs\u002Fja\u002F_build\u002Fhtml\n  ```\n- Check generated-file hygiene:\n  ```\n  git diff --check\n  git status -sb\n  git ls-files docs\u002Fapi docs\u002Fapi\u002F_items | rg 'ommx\\.v1|old-package-name'\n  ```\n- For import-surface migrations, search both runtime and docs:\n  ```\n  rg -n 'from ommx\\.v1|import ommx\\.v1|ommx\\.v1\\.' python docs\n  ```\n\nWhen reviewing CI failures, fetch the exact failing Sphinx or doctest log before\nchanging docs. If a doctest imports packages by discovery, check whether a\nsentinel package is intentionally import-failing for migration guidance.\n\n## Findings\n\nLead review findings with user-visible publication risk:\n\n- Missing or stale API reference entry.\n- Generated artifacts not refreshed from the handwritten source.\n- Current examples import an obsolete public API.\n- Migration docs confuse Python import namespaces with protobuf wire namespaces.\n- Sphinx build warnings that would fail CI.\n- Docstrings that render incorrectly or break AutoAPI\u002Fdocutils parsing.\n\nKeep generated-diff summaries secondary. A large generated diff is acceptable\nwhen the owner configuration and regeneration path are correct.\nSuccessful generation or a warning-free build does not establish that a reader\ncan understand the page; report only the technical properties checked here.\n",{"name":5,"description":7},"main","f7800d0f1921fc707413939975cc6ef312d7319f",".agents\u002Fskills\u002Fsphinx-docs-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":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add Jij-Inc\u002Fommx --skill sphinx-docs-review",{"tool":59,"command":60},"bunx","bunx skills add Jij-Inc\u002Fommx --skill sphinx-docs-review",{"tool":62,"command":63},"pnpm","pnpm dlx skills add Jij-Inc\u002Fommx --skill sphinx-docs-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fsphinx-docs-review\u002FSKILL.md",true,[],[68,78,102,128,148,157],{"skillNo":69,"name":35,"nameZh":6,"description":70,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":71,"categories":72,"keywords":73,"publishedAt":39},"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,25,74,75,76,77],"usage","distribution","guidance","placeholder",{"skillNo":79,"name":80,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":39},"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",[],[85,86,87,88,89,90,91,92,93,94,95,25,96,97,98,99,100,101],"release note","release","note","true","append","edit","read","english","version","notes","entries","japanese","Bash","release notes","gh","git","pr",{"skillNo":103,"name":104,"nameZh":6,"description":105,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":106,"categories":107,"keywords":118,"publishedAt":39},"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",[108,113],{"categoryNo":109,"categoryName":110,"taxonomyType":111,"taxonomyTypeDesc":112},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":114,"categoryName":115,"taxonomyType":116,"taxonomyTypeDesc":117},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[119,120,121,122,123,124,29,125,126,32,37,127,35],"module","rust","boundary","rust module boundary","public api","public","super","when","writing",{"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":39},"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,120,137,138,126,139,124,140,141,32,142,143,144,145,146,147,35],"error","rust error handling","error handling","result","sdk","binding","propagation","map","local","implementing","types","python","signal",{"skillNo":149,"name":80,"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":39},"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",[],[87,86,85,139,101,98,94,35,120,89,154,95,155,25,156,146],"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":39},"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",[],[139,19,146,155,164,165,126,166,124,167,168,169,32,33,170,25,37,171,35],"python sdk review","behavior","stub","shape","changes","output","tests","src"]