[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXK5SHD9FPD079K336Y02T":3,"skill-same:01M6BXK5SHD9FPD079K336Y02T":71},{"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":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":42,"commitSha":43,"skillDirectory":44,"forksCount":45,"repositoryHtmlUrl":46,"repositoryHomepageUrl":47,"ownerHtmlUrl":48,"ownerBlogUrl":49,"ownerDescription":6,"updatedAt":50,"install":51,"resources":64},"01M6BXK5SHD9FPD079K336Y02T","rust-error-handling",null,"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.","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-error-handling\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36],"rust","error handling","rust error handling","error","local","when","signal","result","implementing","types","binding","propagation","python","map","use","public","ommx","sdk","2026-11-10 10:12:30",false,"---\nname: rust-error-handling\ndescription: 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.\n---\n\n# Rust Error Handling\n\nUse `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md` first to establish\nthe domain owner. Read `rust\u002Fommx\u002Fdoc\u002Ftutorial\u002Ferror_handling.md` before changing\nor reviewing a public Rust error surface. Treat every public signal and Python\nexception classification as an SDK contract.\n\n## Mandatory Decision Order\n\n1. Name the failing domain operation and its owner.\n2. State the caller's concrete recovery action: what will the caller inspect,\n   change, retry, skip, or select differently?\n3. Verify that recovery is an intentional, stable contract of that public\n   operation, not merely a hypothetical reaction available to one internal or\n   application-specific consumer.\n4. Choose the narrowest error surface that supports that contract.\n\nIf no stable, intentional recovery contract can be named, do not add a public\nsignal merely to improve diagnostics or select a Python exception class. If an\noperation is already documented as producing an existing signal for that\ncondition, treat an untyped path as a contract bug rather than inventing a new\nparallel signal.\n\n| Condition | Error surface |\n| --- | --- |\n| No stable caller recovery path | `ommx::Result\u003CT>` with an ordinary `ommx::Error` |\n| One recoverable condition among broader failures | Public OMMX-owned signal preserved in the `ommx::Error` chain |\n| A narrow API has one signal failure that callers commonly match directly | A typed `Result\u003CT, Signal>` may be justified |\n| Python owns the failure semantics | Explicit `PyErr` classification at the binding site |\n\n## Rust SDK Policy\n\n- Keep `ommx::Result\u003CT>` as the default public fallible return type. Do not\n  replace it with a closed SDK-wide error enum.\n- Curate public signal types for stable programmatic recovery. Preserve them in\n  the `anyhow::Error` chain so callers can use `is` or `downcast_ref`.\n- Keep each signal with the narrowest domain owner that has enough information\n  to define it. Reuse an existing owner signal before introducing another type.\n- Do not create an operation-wide umbrella type that combines failures with\n  different owners or recovery actions. A domain-owned enum remains appropriate\n  when its variants form one stable matching contract.\n- Do not expose `prost`, `serde_json`, OCI, registry-client, or other dependency\n  errors as the OMMX consumer contract. Normalize them at the OMMX boundary only\n  when callers need a stable OMMX-owned signal.\n- Preserve sources and diagnostic context while their recovery semantics remain\n  valid at the outer owner boundary. Do not replace such a signal with a\n  rendered string or duplicate its message in a wrapper.\n- Review nested signals independently from their outer owner. If the inner\n  signal still truthfully describes the cause and the outer owner has its own\n  stable recovery contract, preserve the inner source beneath that outer\n  OMMX-owned signal and map the outer signal first. Rust callers may then\n  intentionally downcast to either layer while Python follows outer ownership.\n- Do not leave an inner signal discoverable when its recovery contract becomes\n  false or misleading after an ownership transition, such as caller-input\n  validation reused to validate internally derived state. Convert that cause\n  to non-signal diagnostic context, then emit an outer OMMX-owned signal if one\n  is justified or an ordinary `ommx::Error` otherwise. Retain the relevant\n  cause and values as structured tracing fields and regression-test the outer\n  mapping or fallback semantics.\n- Expose the payload a caller needs for recovery through public fields or\n  accessors. Document its meaning and use `#[non_exhaustive]` when callers should\n  inspect but not exhaustively construct the signal.\n- Keep failures without a stable recovery path as ordinary `ommx::Error`\n  values, with structured tracing at the fail site.\n\nFor every new public signal, also use\n`.agents\u002Fskills\u002Frust-module-boundary\u002FSKILL.md` to justify its module owner,\nvisibility, payload, and public API commitment.\n\n## PyO3 Boundary Policy\n\nClassify ownership before choosing a Python exception.\n\n### Rust SDK-owned failures\n\n- Return `OmmxPyResult\u003CT>` from exposed bindings that can propagate Rust-owned\n  failures.\n- Declare each OMMX-owned signal mapping once in the shared mapping table in\n  `python\u002Fommx\u002Fsrc\u002Ferror.rs`. Generate both the direct `From\u003CSignal>` conversion\n  and fallback dispatch for a signal already erased into `ommx::Error`.\n- Use normal `?` propagation at binding call sites. Do not add per-call\n  `map_err` closures for Rust SDK-owned failures.\n- Preserve outer domain ownership when an error chain contains nested signals;\n  keep fallback classification order explicit where it affects the contract.\n- Map unclassified Rust SDK failures to `RuntimeError`.\n- Do not enable or depend on PyO3's blanket `anyhow` conversion, add a generic\n  conversion that absorbs arbitrary errors, or classify by rendered message.\n\n### Python-owned failures\n\nKeep Python semantics explicit at the binding boundary. Do not force these\nthrough the Rust SDK signal mapper:\n\n- Python argument extraction or protocol violations (`TypeError`)\n- Python integer conversion overflow (`OverflowError`)\n- Mapping-like lookup behavior owned by the Python API (`KeyError`)\n- Python object or JSON input validation (`ValueError`)\n- Exceptions from imports, callbacks, adapters, pandas, codecs, or other Python\n  libraries; preserve the original `PyErr`\n\nMalformed payloads received by the private cross-extension bridge are\nbinding-internal Rust failures and fall back to `RuntimeError`; they are not\nPython call-signature `TypeError` cases unless an original `PyErr` exists.\n\nThe existence of a local `map_err` is not itself a defect. First determine\nwhether Rust SDK or Python owns the failure.\n\n## Review Workflow\n\n1. Inventory the changed failure paths.\n   - List every public Rust entry point and exposed PyO3 method affected.\n   - Search sibling paths for the same failure so equivalent operations do not\n     acquire different contracts.\n2. Classify every failure.\n   - Name its owner and caller recovery action.\n   - Search for an existing signal before adding one.\n   - Separate caller input, persisted corruption, dependency failure, and\n     internal invariant failure.\n3. Verify propagation.\n   - Confirm the signal survives direct typed conversion and prior erasure into\n     `ommx::Error`.\n   - Confirm nested mapped signals do not override a more specific outer owner;\n     declaration order is part of the Python contract.\n   - Confirm Python-owned `PyErr` values pass through unchanged.\n   - Confirm ordinary SDK failures reach the `RuntimeError` fallback.\n4. Verify mutation and payload behavior.\n   - Validate all inputs before mutation or prove rollback\u002Fatomicity.\n   - Test every recovery-relevant payload field, including value direction and\n     the complete set of missing or unknown IDs.\n5. Verify user-facing consistency.\n   - Test equivalent failures across entry points against the same Python\n     exception class.\n   - Update Rustdoc, Python docstrings, migration notes, release notes, stubs,\n     and API metadata when the public contract changes.\n\n## Evidence and Commands\n\nRequire both enforcing code and a regression test for every claimed contract.\nThe shared mapping mechanism must have unit coverage for direct and erased\nconversion, ordinary fallback, and unchanged `PyErr` pass-through. A macro does\nnot need the same mechanism test repeated for every entry, but every newly\nmapped signal needs a focused Python integration test through its real public\noperation. Add both direct and erased tests for a particular signal only when\nit can reach the boundary through distinct conversion paths not already proved\nby the shared mechanism. When mapped outer and inner signals can coexist in one\nchain, test that declaration order selects the outer Python contract. When an\nownership transition intentionally removes an obsolete inner signal, test both\nthat Rust can no longer downcast to it and that Python selects the intended\nouter or fallback exception.\n\nUse focused commands that match the touched surface:\n\n```bash\nrg -n \"OmmxPyResult|define_ommx_error_mappings|map_err|new_err|downcast_ref\" \\\n  rust\u002Fommx\u002Fsrc python\u002Fommx\u002Fsrc\ncargo test -p ommx affected_module --lib\nenv PYO3_PYTHON=\"$PWD\u002F.venv\u002Fbin\u002Fpython3\" cargo test -p _ommx_rust error::tests --lib\nuv run --no-sync pytest -q python\u002Fommx\u002Ftests\u002Ftest_affected_behavior.py\ncargo tree -p _ommx_rust -e features -i pyo3\n```\n\nRun `task python:sync` first when the project `.venv` is absent.\nRun `task python:stubgen` after a public PyO3 signature or docstring change.\nRun `cargo fmt --all -- --check` and `git diff --check` before handoff.\n\n## Checklist\n\n- What will a caller do differently after identifying this failure, and is that\n  recovery an intentional contract of this operation?\n- Which domain owns the signal and its payload?\n- Can an existing signal express the same recovery contract?\n- Does the public API remain on `ommx::Result` unless a narrow typed result is\n  justified?\n- Does the error chain preserve only signals whose recovery semantics remain\n  valid at the outer owner, plus the useful source and diagnostic context?\n- Are dependency types and rendered messages absent from the public contract?\n- Do direct and erased Rust errors share one declarative Python mapping?\n- Are Python-owned exceptions kept outside the SDK mapper?\n- Are all recovery payload fields, fallback behavior, and mutation atomicity\n  protected by tests?\n","# Rust Error Handling\n\nUse `.agents\u002Fskills\u002Fdomain-responsibility-review\u002FSKILL.md` first to establish\nthe domain owner. Read `rust\u002Fommx\u002Fdoc\u002Ftutorial\u002Ferror_handling.md` before changing\nor reviewing a public Rust error surface. Treat every public signal and Python\nexception classification as an SDK contract.\n\n## Mandatory Decision Order\n\n1. Name the failing domain operation and its owner.\n2. State the caller's concrete recovery action: what will the caller inspect,\n   change, retry, skip, or select differently?\n3. Verify that recovery is an intentional, stable contract of that public\n   operation, not merely a hypothetical reaction available to one internal or\n   application-specific consumer.\n4. Choose the narrowest error surface that supports that contract.\n\nIf no stable, intentional recovery contract can be named, do not add a public\nsignal merely to improve diagnostics or select a Python exception class. If an\noperation is already documented as producing an existing signal for that\ncondition, treat an untyped path as a contract bug rather than inventing a new\nparallel signal.\n\n| Condition | Error surface |\n| --- | --- |\n| No stable caller recovery path | `ommx::Result\u003CT>` with an ordinary `ommx::Error` |\n| One recoverable condition among broader failures | Public OMMX-owned signal preserved in the `ommx::Error` chain |\n| A narrow API has one signal failure that callers commonly match directly | A typed `Result\u003CT, Signal>` may be justified |\n| Python owns the failure semantics | Explicit `PyErr` classification at the binding site |\n\n## Rust SDK Policy\n\n- Keep `ommx::Result\u003CT>` as the default public fallible return type. Do not\n  replace it with a closed SDK-wide error enum.\n- Curate public signal types for stable programmatic recovery. Preserve them in\n  the `anyhow::Error` chain so callers can use `is` or `downcast_ref`.\n- Keep each signal with the narrowest domain owner that has enough information\n  to define it. Reuse an existing owner signal before introducing another type.\n- Do not create an operation-wide umbrella type that combines failures with\n  different owners or recovery actions. A domain-owned enum remains appropriate\n  when its variants form one stable matching contract.\n- Do not expose `prost`, `serde_json`, OCI, registry-client, or other dependency\n  errors as the OMMX consumer contract. Normalize them at the OMMX boundary only\n  when callers need a stable OMMX-owned signal.\n- Preserve sources and diagnostic context while their recovery semantics remain\n  valid at the outer owner boundary. Do not replace such a signal with a\n  rendered string or duplicate its message in a wrapper.\n- Review nested signals independently from their outer owner. If the inner\n  signal still truthfully describes the cause and the outer owner has its own\n  stable recovery contract, preserve the inner source beneath that outer\n  OMMX-owned signal and map the outer signal first. Rust callers may then\n  intentionally downcast to either layer while Python follows outer ownership.\n- Do not leave an inner signal discoverable when its recovery contract becomes\n  false or misleading after an ownership transition, such as caller-input\n  validation reused to validate internally derived state. Convert that cause\n  to non-signal diagnostic context, then emit an outer OMMX-owned signal if one\n  is justified or an ordinary `ommx::Error` otherwise. Retain the relevant\n  cause and values as structured tracing fields and regression-test the outer\n  mapping or fallback semantics.\n- Expose the payload a caller needs for recovery through public fields or\n  accessors. Document its meaning and use `#[non_exhaustive]` when callers should\n  inspect but not exhaustively construct the signal.\n- Keep failures without a stable recovery path as ordinary `ommx::Error`\n  values, with structured tracing at the fail site.\n\nFor every new public signal, also use\n`.agents\u002Fskills\u002Frust-module-boundary\u002FSKILL.md` to justify its module owner,\nvisibility, payload, and public API commitment.\n\n## PyO3 Boundary Policy\n\nClassify ownership before choosing a Python exception.\n\n### Rust SDK-owned failures\n\n- Return `OmmxPyResult\u003CT>` from exposed bindings that can propagate Rust-owned\n  failures.\n- Declare each OMMX-owned signal mapping once in the shared mapping table in\n  `python\u002Fommx\u002Fsrc\u002Ferror.rs`. Generate both the direct `From\u003CSignal>` conversion\n  and fallback dispatch for a signal already erased into `ommx::Error`.\n- Use normal `?` propagation at binding call sites. Do not add per-call\n  `map_err` closures for Rust SDK-owned failures.\n- Preserve outer domain ownership when an error chain contains nested signals;\n  keep fallback classification order explicit where it affects the contract.\n- Map unclassified Rust SDK failures to `RuntimeError`.\n- Do not enable or depend on PyO3's blanket `anyhow` conversion, add a generic\n  conversion that absorbs arbitrary errors, or classify by rendered message.\n\n### Python-owned failures\n\nKeep Python semantics explicit at the binding boundary. Do not force these\nthrough the Rust SDK signal mapper:\n\n- Python argument extraction or protocol violations (`TypeError`)\n- Python integer conversion overflow (`OverflowError`)\n- Mapping-like lookup behavior owned by the Python API (`KeyError`)\n- Python object or JSON input validation (`ValueError`)\n- Exceptions from imports, callbacks, adapters, pandas, codecs, or other Python\n  libraries; preserve the original `PyErr`\n\nMalformed payloads received by the private cross-extension bridge are\nbinding-internal Rust failures and fall back to `RuntimeError`; they are not\nPython call-signature `TypeError` cases unless an original `PyErr` exists.\n\nThe existence of a local `map_err` is not itself a defect. First determine\nwhether Rust SDK or Python owns the failure.\n\n## Review Workflow\n\n1. Inventory the changed failure paths.\n   - List every public Rust entry point and exposed PyO3 method affected.\n   - Search sibling paths for the same failure so equivalent operations do not\n     acquire different contracts.\n2. Classify every failure.\n   - Name its owner and caller recovery action.\n   - Search for an existing signal before adding one.\n   - Separate caller input, persisted corruption, dependency failure, and\n     internal invariant failure.\n3. Verify propagation.\n   - Confirm the signal survives direct typed conversion and prior erasure into\n     `ommx::Error`.\n   - Confirm nested mapped signals do not override a more specific outer owner;\n     declaration order is part of the Python contract.\n   - Confirm Python-owned `PyErr` values pass through unchanged.\n   - Confirm ordinary SDK failures reach the `RuntimeError` fallback.\n4. Verify mutation and payload behavior.\n   - Validate all inputs before mutation or prove rollback\u002Fatomicity.\n   - Test every recovery-relevant payload field, including value direction and\n     the complete set of missing or unknown IDs.\n5. Verify user-facing consistency.\n   - Test equivalent failures across entry points against the same Python\n     exception class.\n   - Update Rustdoc, Python docstrings, migration notes, release notes, stubs,\n     and API metadata when the public contract changes.\n\n## Evidence and Commands\n\nRequire both enforcing code and a regression test for every claimed contract.\nThe shared mapping mechanism must have unit coverage for direct and erased\nconversion, ordinary fallback, and unchanged `PyErr` pass-through. A macro does\nnot need the same mechanism test repeated for every entry, but every newly\nmapped signal needs a focused Python integration test through its real public\noperation. Add both direct and erased tests for a particular signal only when\nit can reach the boundary through distinct conversion paths not already proved\nby the shared mechanism. When mapped outer and inner signals can coexist in one\nchain, test that declaration order selects the outer Python contract. When an\nownership transition intentionally removes an obsolete inner signal, test both\nthat Rust can no longer downcast to it and that Python selects the intended\nouter or fallback exception.\n\nUse focused commands that match the touched surface:\n\n```bash\nrg -n \"OmmxPyResult|define_ommx_error_mappings|map_err|new_err|downcast_ref\" \\\n  rust\u002Fommx\u002Fsrc python\u002Fommx\u002Fsrc\ncargo test -p ommx affected_module --lib\nenv PYO3_PYTHON=\"$PWD\u002F.venv\u002Fbin\u002Fpython3\" cargo test -p _ommx_rust error::tests --lib\nuv run --no-sync pytest -q python\u002Fommx\u002Ftests\u002Ftest_affected_behavior.py\ncargo tree -p _ommx_rust -e features -i pyo3\n```\n\nRun `task python:sync` first when the project `.venv` is absent.\nRun `task python:stubgen` after a public PyO3 signature or docstring change.\nRun `cargo fmt --all -- --check` and `git diff --check` before handoff.\n\n## Checklist\n\n- What will a caller do differently after identifying this failure, and is that\n  recovery an intentional contract of this operation?\n- Which domain owns the signal and its payload?\n- Can an existing signal express the same recovery contract?\n- Does the public API remain on `ommx::Result` unless a narrow typed result is\n  justified?\n- Does the error chain preserve only signals whose recovery semantics remain\n  valid at the outer owner, plus the useful source and diagnostic context?\n- Are dependency types and rendered messages absent from the public contract?\n- Do direct and erased Rust errors share one declarative Python mapping?\n- Are Python-owned exceptions kept outside the SDK mapper?\n- Are all recovery payload fields, fallback behavior, and mutation atomicity\n  protected by tests?\n",{"name":5,"description":7},"main","f7800d0f1921fc707413939975cc6ef312d7319f",".agents\u002Fskills\u002Frust-error-handling",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-12 21:15:07",{"source":8,"skillName":5,"commands":52,"prompt":62,"zipAvailable":63},[53,56,59],{"tool":54,"command":55},"npx","npx skills add Jij-Inc\u002Fommx --skill rust-error-handling",{"tool":57,"command":58},"bunx","bunx skills add Jij-Inc\u002Fommx --skill rust-error-handling",{"tool":60,"command":61},"pnpm","pnpm dlx skills add Jij-Inc\u002Fommx --skill rust-error-handling","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frust-error-handling\u002FSKILL.md",true,[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"agents\u002Fopenai.yaml","REFERENCE","参考文档",258,"https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Frust-error-handling\u002Fagents\u002Fopenai.yaml",[72,83,107,131,154,163],{"skillNo":73,"name":35,"nameZh":6,"description":74,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":75,"categories":76,"keywords":77,"publishedAt":37},"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,78,79,80,81,82],"for","usage","distribution","guidance","placeholder",{"skillNo":84,"name":85,"nameZh":6,"description":86,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":87,"categories":88,"keywords":89,"publishedAt":37},"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",[],[90,91,92,93,94,95,96,97,98,99,78,100,101,102,103,104,105,106],"note","release","release note","entries","append","edit","read","english","version","true","japanese","Bash","release notes","gh","git","pr","notes",{"skillNo":108,"name":109,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":113,"publishedAt":37},"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",[],[114,115,116,117,118,119,120,121,33,122,123,124,78,125,126,127,128,129,130,35],"sphinx docs review","docs review","docs","review","design","wiring","references","correctness","technical","generated","pages","consistency","learning","api","structure","build","documentation",{"skillNo":132,"name":133,"nameZh":6,"description":134,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":135,"categories":136,"keywords":147,"publishedAt":37},"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",[137,142],{"categoryNo":138,"categoryName":139,"taxonomyType":140,"taxonomyTypeDesc":141},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":143,"categoryName":144,"taxonomyType":145,"taxonomyTypeDesc":146},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[148,149,19,150,35,34,128,151,152,24,33,127,153],"module","rust module boundary","boundary","super","public api","writing",{"skillNo":155,"name":85,"nameZh":6,"description":156,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":157,"categories":158,"keywords":159,"publishedAt":37},"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,92,90,105,102,106,35,36,94,160,93,161,78,162,31,19],"sdk release","python sdk","relevant",{"skillNo":164,"name":165,"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":37},"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",[],[36,161,170,31,117,171,24,172,34,173,174,175,33,123,176,78,127,177,35],"python sdk review","changes","stub","shape","behavior","output","tests","src"]