[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXJYTZ9NFHCDXPPJ3E61SF":3,"skill-same:01M6BXJYTZ9NFHCDXPPJ3E61SF":58},{"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":30,"linkOnly":31,"markdownContent":32,"markdownBody":33,"frontMatter":34,"refName":35,"commitSha":36,"skillDirectory":37,"forksCount":38,"repositoryHtmlUrl":39,"repositoryHomepageUrl":40,"ownerHtmlUrl":41,"ownerBlogUrl":42,"ownerDescription":6,"updatedAt":43,"install":44,"resources":57},"01M6BXJYTZ9NFHCDXPPJ3E61SF","proptest-arbitrary-review",null,"Use when reviewing changes to Arbitrary implementations, proptest strategy parameters, or property-test generators in the OMMX Rust SDK, including changes to what a default strategy generates.","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\u002Fproptest-arbitrary-review\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29],"review","proptest arbitrary review","ommx","test","sdk","rust","changes","default","strategy","use","when","2026-11-10 10:12:30",false,"---\nname: proptest-arbitrary-review\ndescription: Use when reviewing changes to Arbitrary implementations, proptest strategy parameters, or property-test generators in the OMMX Rust SDK, including changes to what a default strategy generates.\n---\n\n# Proptest Arbitrary Review\n\nUse this skill when a diff touches an `Arbitrary` implementation, a\n`*Parameters` strategy type, or the space a generator samples from. The core\nquestion is always: **which domain does each property test now quantify\nover, and is that the domain the property actually claims?**\n\nThis complements `domain-responsibility-review`: that skill judges whether\nproduction code preserves invariants; this skill judges whether the test\ngenerators exercise those invariants honestly.\n\n## Default-Space Blast Radius\n\nChanging what `Default` parameters or `any::\u003CT>()` generate silently changes\nthe quantification domain of every property test that uses the default.\n\n- Enumerate all call sites before judging the diff:\n  `grep -rn \"T::arbitrary\\|any::\u003CT>\" rust\u002F` (and the parameter type name).\n  Include non-test consumers: `random_deterministic`, examples, doc examples,\n  and Python bindings that expose random generation.\n- Classify each site explicitly:\n  - The property should hold on the new, broader space → keep the default.\n    A site kept on the default is a claim that the property holds for the\n    whole space; treat an unchanged site as a positive assertion, not as\n    \"untouched code\".\n  - The property has a precondition (format compatibility, algebraic\n    restriction) → it must opt into a named subspace constructor.\n- Verify by execution, not by reading: check out the branch and run every\n  affected proptest suite. Passing N generated cases is the only proof that\n  the new default satisfies downstream expectations.\n\n## Named Subspaces Express Preconditions\n\n- Prefer intent-named constructors (`v1_compatible()`, `mps_compatible_qcqp()`)\n  over ad-hoc field overrides at test sites. The test site should read as a\n  statement of the property's precondition.\n- A named subspace constructor is a semantic claim. Require a test that fails\n  if the claim breaks (e.g. `v1_compatible` must be pinned by a v1 round-trip\n  proptest). An alias like `v1_compatible() = regular_only()` is acceptable\n  only while such a pinning test exists, because the two spaces can drift\n  apart when either evolves.\n\n## Coverage Honesty\n\nDistinguish **sampled dimensions** from **constant injected structure**.\n\n- Structure that a generator injects deterministically (fixed IDs, fixed\n  function bodies, fixed set sizes, constant metadata) covers each new\n  dimension at exactly one point. That is smoke coverage, not domain\n  coverage. Either sample the dimension from a strategy, or document the\n  limitation in the generator's rustdoc so properties over the default space\n  do not overclaim.\n- Check presence\u002Fabsence combinations. A generator in which every optional\n  feature is always present never tests feature-absent interactions;\n  \"always everything\" is as narrow as \"always nothing\" in that dimension.\n- Injected constant structure never shrinks away, so minimal counterexamples\n  carry it as noise. Weigh that cost when deciding whether the structure\n  belongs in the default space or in a dedicated named space.\n- Non-emptiness assertions over deterministically injected structure verify\n  the generator, not the domain. Such tests are generator-regression tests;\n  name and comment them as such, and do not count them as evidence that a\n  domain property holds.\n\n## Generated Data Validity\n\n- Generators must construct values through the owning validated constructor\n  (e.g. `Instance::builder()`), so that every generated case re-checks the\n  type's own invariants. Direct field assignment is acceptable only for\n  fields whose documentation explicitly states they are validation-free.\n- Hand-rolled resource allocation inside a generator (fresh variable IDs,\n  next constraint ID) must match the domain's own allocator semantics.\n  Compare against the owner's allocation function (e.g.\n  `ConstraintCollection::unused_id` considers active **and** inactive rows);\n  prefer calling the domain allocator over re-implementing it.\n- When the generator mutates the value after `build()` (conversions, direct\n  field writes), re-check which invariants that post-processing can bypass.\n\n## Review Checklist\n\n- Which property tests changed quantification domain because of this diff,\n  including the ones the diff does not touch?\n- Does every site left on the default strategy genuinely claim its property\n  over the broader space?\n- Does every named subspace have a pinning test that fails when its claim\n  breaks?\n- Which generated dimensions are sampled and which are constant? Is constant\n  structure documented as smoke coverage?\n- Does generation go through the owning constructor, and does any\n  post-`build()` mutation bypass validation?\n- Were the affected proptest suites actually executed on the branch?\n","# Proptest Arbitrary Review\n\nUse this skill when a diff touches an `Arbitrary` implementation, a\n`*Parameters` strategy type, or the space a generator samples from. The core\nquestion is always: **which domain does each property test now quantify\nover, and is that the domain the property actually claims?**\n\nThis complements `domain-responsibility-review`: that skill judges whether\nproduction code preserves invariants; this skill judges whether the test\ngenerators exercise those invariants honestly.\n\n## Default-Space Blast Radius\n\nChanging what `Default` parameters or `any::\u003CT>()` generate silently changes\nthe quantification domain of every property test that uses the default.\n\n- Enumerate all call sites before judging the diff:\n  `grep -rn \"T::arbitrary\\|any::\u003CT>\" rust\u002F` (and the parameter type name).\n  Include non-test consumers: `random_deterministic`, examples, doc examples,\n  and Python bindings that expose random generation.\n- Classify each site explicitly:\n  - The property should hold on the new, broader space → keep the default.\n    A site kept on the default is a claim that the property holds for the\n    whole space; treat an unchanged site as a positive assertion, not as\n    \"untouched code\".\n  - The property has a precondition (format compatibility, algebraic\n    restriction) → it must opt into a named subspace constructor.\n- Verify by execution, not by reading: check out the branch and run every\n  affected proptest suite. Passing N generated cases is the only proof that\n  the new default satisfies downstream expectations.\n\n## Named Subspaces Express Preconditions\n\n- Prefer intent-named constructors (`v1_compatible()`, `mps_compatible_qcqp()`)\n  over ad-hoc field overrides at test sites. The test site should read as a\n  statement of the property's precondition.\n- A named subspace constructor is a semantic claim. Require a test that fails\n  if the claim breaks (e.g. `v1_compatible` must be pinned by a v1 round-trip\n  proptest). An alias like `v1_compatible() = regular_only()` is acceptable\n  only while such a pinning test exists, because the two spaces can drift\n  apart when either evolves.\n\n## Coverage Honesty\n\nDistinguish **sampled dimensions** from **constant injected structure**.\n\n- Structure that a generator injects deterministically (fixed IDs, fixed\n  function bodies, fixed set sizes, constant metadata) covers each new\n  dimension at exactly one point. That is smoke coverage, not domain\n  coverage. Either sample the dimension from a strategy, or document the\n  limitation in the generator's rustdoc so properties over the default space\n  do not overclaim.\n- Check presence\u002Fabsence combinations. A generator in which every optional\n  feature is always present never tests feature-absent interactions;\n  \"always everything\" is as narrow as \"always nothing\" in that dimension.\n- Injected constant structure never shrinks away, so minimal counterexamples\n  carry it as noise. Weigh that cost when deciding whether the structure\n  belongs in the default space or in a dedicated named space.\n- Non-emptiness assertions over deterministically injected structure verify\n  the generator, not the domain. Such tests are generator-regression tests;\n  name and comment them as such, and do not count them as evidence that a\n  domain property holds.\n\n## Generated Data Validity\n\n- Generators must construct values through the owning validated constructor\n  (e.g. `Instance::builder()`), so that every generated case re-checks the\n  type's own invariants. Direct field assignment is acceptable only for\n  fields whose documentation explicitly states they are validation-free.\n- Hand-rolled resource allocation inside a generator (fresh variable IDs,\n  next constraint ID) must match the domain's own allocator semantics.\n  Compare against the owner's allocation function (e.g.\n  `ConstraintCollection::unused_id` considers active **and** inactive rows);\n  prefer calling the domain allocator over re-implementing it.\n- When the generator mutates the value after `build()` (conversions, direct\n  field writes), re-check which invariants that post-processing can bypass.\n\n## Review Checklist\n\n- Which property tests changed quantification domain because of this diff,\n  including the ones the diff does not touch?\n- Does every site left on the default strategy genuinely claim its property\n  over the broader space?\n- Does every named subspace have a pinning test that fails when its claim\n  breaks?\n- Which generated dimensions are sampled and which are constant? Is constant\n  structure documented as smoke coverage?\n- Does generation go through the owning constructor, and does any\n  post-`build()` mutation bypass validation?\n- Were the affected proptest suites actually executed on the branch?\n",{"name":5,"description":7},"main","e78914833dc7963f9ebff7acfe211cb81d910716",".agents\u002Fskills\u002Fproptest-arbitrary-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":45,"prompt":55,"zipAvailable":56},[46,49,52],{"tool":47,"command":48},"npx","npx skills add Jij-Inc\u002Fommx --skill proptest-arbitrary-review",{"tool":50,"command":51},"bunx","bunx skills add Jij-Inc\u002Fommx --skill proptest-arbitrary-review",{"tool":53,"command":54},"pnpm","pnpm dlx skills add Jij-Inc\u002Fommx --skill proptest-arbitrary-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fproptest-arbitrary-review\u002FSKILL.md",true,[],[59,70,94,117,141,160],{"skillNo":60,"name":21,"nameZh":6,"description":61,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":62,"categories":63,"keywords":64,"publishedAt":30},"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",[],[21,65,66,67,68,69],"for","usage","distribution","guidance","placeholder",{"skillNo":71,"name":72,"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":30},"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",[],[77,78,79,80,81,65,82,83,84,85,86,87,88,89,90,91,92,93],"release note","release","note","git","version","true","english","entries","japanese","append","edit","read","gh","Bash","release notes","pr","notes",{"skillNo":95,"name":96,"nameZh":6,"description":97,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":98,"categories":99,"keywords":100,"publishedAt":30},"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",[],[101,19,102,103,104,105,106,107,65,108,109,28,110,111,21,112,113,114,115,116],"sphinx docs review","docs","docs review","references","correctness","pages","consistency","structure","build","generated","technical","learning","wiring","documentation","design","api",{"skillNo":118,"name":119,"nameZh":6,"description":120,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":121,"categories":122,"keywords":133,"publishedAt":30},"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",[123,128],{"categoryNo":124,"categoryName":125,"taxonomyType":126,"taxonomyTypeDesc":127},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":129,"categoryName":130,"taxonomyType":131,"taxonomyTypeDesc":132},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[134,135,136,24,137,116,29,138,108,28,139,21,140],"rust module boundary","boundary","module","super","public api","public","writing",{"skillNo":142,"name":143,"nameZh":6,"description":144,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":145,"categories":146,"keywords":147,"publishedAt":30},"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",[],[148,149,150,24,151,28,139,21,23,152,153,29,154,155,156,157,158,159],"error","rust error handling","error handling","map","python","local","signal","result","implementing","types","binding","propagation",{"skillNo":161,"name":72,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":30},"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",[],[79,77,78,166,65,167,84,86,168,21,91,92,93,24,23,152],"sdk release","relevant","python sdk"]