[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXJKZRTBQTJK99HF6AF9CT":3,"skill-same:01M6BXJKZRTBQTJK99HF6AF9CT":107},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":54,"commitSha":55,"skillDirectory":56,"forksCount":57,"repositoryHtmlUrl":58,"repositoryHomepageUrl":59,"ownerHtmlUrl":60,"ownerBlogUrl":61,"ownerDescription":6,"updatedAt":62,"install":63,"resources":76},"01M6BXJKZRTBQTJK99HF6AF9CT","book-reading-review",null,"Plan, write, or review OMMX README and Book explanations of purpose, responsibility contracts, extensible design, adoption value, reader choices, and independent reading paths. Check prerequisites, introduction order, cognitive load, and explanation ownership across the Book and Reference; audit major SDK feature coverage when requested. Generated API wiring or Sphinx build failures alone belong to sphinx-docs-review.","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\u002Fbook-reading-review\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"review","book reading review","reading","book","build","check","across","wiring","when","load","generated","design","README","feature","value","coverage","ommx","api","plan","adoption","2026-11-10 10:12:30",false,"---\nname: book-reading-review\ndescription: Plan, write, or review OMMX README and Book explanations of purpose, responsibility contracts, extensible design, adoption value, reader choices, and independent reading paths. Check prerequisites, introduction order, cognitive load, and explanation ownership across the Book and Reference; audit major SDK feature coverage when requested. Generated API wiring or Sphinx build failures alone belong to sphinx-docs-review.\n---\n\n# Book Reading Review\n\nReview what a reader can understand, decide, or do at each point. OMMX is designed\nas an extensible system: declarations, analyses, and transformations are added\non a common problem representation while preserving shared meanings and\nresponsibilities. Connect that design to adoption value and reader choices.\nExplain it in optimization terms without requiring compiler knowledge.\n\nOMMX defines problem and candidate semantics independently of a solver. Keep\nthat common model separate from an Adapter's execution contract and the\nguarantees of an individual transformation. Preserving problem structure lets\nlater processing use its meaning; reconstruction, feasibility, objective values,\nand optimality remain distinct guarantees.\n\nThis workflow can stand alone for a reader-comprehension question. A change\nlimited to API generation, directives, or Sphinx build\u002Frender\u002Flink correctness\nbelongs to `sphinx-docs-review` and does not require this skill or its ledger.\nApply both only when the request includes both concerns; do not load the other\nskill merely because a Book file changed.\n\nWhen introducing or explaining OMMX domain distinctions, use\n[OMMX Terminology](..\u002Fommx-terminology\u002FSKILL.md) for the naming policy and its\ndefinition owners. Keep detailed user-facing meanings in the Book and Reference.\n\n## Establish the reader and source\n\n- Resolve the requested PR\u002Frevision and read its actual files. A local checkout\n  may contain a later stacked PR; do not review that as the requested change.\n- Resolve the current editorial direction from the task and accepted design.\n  Historical navigation, page roles, and ledger declarations are inputs to\n  review, not constraints that override a newer design.\n- Identify the reader's goal, starting knowledge, entry link, and useful stopping\n  point, including the understanding or decision the page should enable.\n  Knowing Python and ordinary optimization does not imply knowing OMMX types,\n  retained variables, inactive constraints, or Preparation.\n- Follow the entry that the navigation promises, including direct chapter or\n  Reference entry and alternative routes. Organize the primary navigation by\n  reader purpose and the objects they work with; document genres and chapter\n  numbers do not establish prerequisites. A declared prerequisite is different\n  from a recommended link.\n- Separate conceptual knowledge from execution dependencies. Book pseudocode\n  has no runtime prerequisite; runnable Reference or Example code still needs\n  its imports, input data, and prior runtime state, including hidden cells.\n\nReview Book pseudocode and illustrative results for explanatory and mathematical\ncorrectness, not executability. Existing Notebook execution remains owned by the\nrepository's separate tests; do not add Notebook reruns to a reading review or\nskip existing tests because the Book policy changed. Keep documented SDK versions\nand prerequisites accurate without treating a Book build as execution evidence.\n\n## Check purpose and capability explanations\n\nFor README and overview work, check whether readers can explain what OMMX\nprovides, why it matters to them, which responsibilities belong to common\nprocessing, which choices remain theirs, and where to go next. A list of APIs\nor an aspiration alone does not answer those questions. Keep the modeler,\ncommon OMMX processing, Adapter, and execution backend's responsibilities\nunderstandable without a catalogue of implementation details.\n\nFor a capability explanation, identify its use, its place in the overall flow,\nand the choices left to the reader. A small example, diagram, or counterexample\nshould teach the meaning or decision at hand. Retain the conditions needed to\ninterpret that example correctly; do not require a full implementation recipe\nfor every feature in the Book.\n\n## Explain responsibility contracts and extensible design\n\nThe Book defines OMMX's accepted domain responsibilities independently of how\ncompletely individual implementations realize them. State these contracts\nexplicitly; do not weaken them to match implementation gaps or relocate them\nentirely to API Reference. For example, an Adapter must preserve the meaning of\naccepted input, interpret backend reports against the problem actually solved,\nand carry conclusions back only with the required transformation guarantees.\nA stated contract is not evidence that every implementation already meets it.\nAPI Reference owns the concrete API contracts and supported scope.\n\nExplain how new declarations, analyses, transformations, and solving methods\njoin the same system while retaining its semantic and responsibility boundaries.\nIntegrate this explanation into the passages that own those relationships. Do\nnot turn extensibility into a separate development-direction section or a list\nof planned features. Explain what must stay true as components are added, such\nas retaining structure before choosing a formulation, stating applicability and\npreservation guarantees, and maintaining the correspondence needed to interpret\nresults. Use examples to teach those principles without implying that every\nexample has a complete implementation.\n\nTreat implementation coverage as supporting information. A brief note that\nsupport varies by feature or Adapter, with a usable API Reference destination,\nis normally sufficient. Do not make an ordinary Book edit depend on a detailed\nimplementation census or maintain a second availability matrix in the Book.\nVerify concrete API calls and executable claims when the text relies on them;\nperform broader implementation or feature-coverage audits when requested.\n\n## Audit feature coverage when requested\n\nFor a whole-Book coverage audit, start from the public SDK at the documented\nversion and the reader tasks it supports, including tasks absent from the Book\nor ledger. Group APIs by useful operations rather than requiring a page for\nevery method. Check the public bindings\u002Fexports against their owning\nimplementation; distinguish released capabilities from development-only APIs.\n\nAudit the Book's coverage of adoption reasons and choices across capabilities,\nwith entry paths to the relevant Reference or Examples. Individual API meanings\nand procedures may be fully owned by Reference; their absence from the Book is\nnot a coverage gap. An API catalogue or a release note alone does not answer the\nBook's purpose and selection questions. Inspect executable examples at their\nowning destination and record whether coverage is usable, only mentioned,\nplanned, absent, or deliberately excluded. Distinguish missing implementation of\nan existing plan from a proposed expansion of scope.\n\nReconcile gaps with the accepted workstream scope and explanation ownership\nbelow. Keep feature inventories in the review record or Book-owned ledger,\nnot in this skill. Ordinary page\u002FPR reviews remain limited to affected tasks;\nthey do not require a whole-SDK inventory.\n\n## Inspect introductions and uses\n\nFor the affected passage, classify each relevant concept as an entry\nprerequisite, local introduction, understanding-dependent use, or mere mention.\nRead enough surrounding text and the linked explanation to justify the choice.\n\n- A definition, a small example with its interpretation, or a short local gloss\n  can introduce the capability needed here. The detailed owner page need not be\n  mandatory reading. Its link alone does not teach the concept.\n- A type name, repr field, output column, navigation label, or optional section\n  does not establish mastery. Conversely, an unfamiliar API name is not itself a\n  finding when the example and adjacent explanation make its role clear.\n- Check the capability's scope. Reading a Solution's values is not the same as\n  understanding transformed feasibility or optimality. A Binary example does\n  not teach SemiInteger\u002FSemiContinuous domains. Split an overly broad concept\n  when a real use needs a narrower capability, not for every API spelling.\n- Inspect order inside a section, not just page order. A reference from an early\n  passage to a later page that requires the unfinished passage's knowledge can\n  leave a learning gap. Two pages linking to each other is not, by itself, a\n  prerequisite cycle.\n- Keep the learning budget proportional to the task. A correct overview can\n  still overload an entry with unexplained names. Move nonessential mechanics\n  to the detailed destination and teach only what the current explanation or\n  example needs.\n\n## Inspect explanation ownership\n\nFor each affected page, identify what the passage enables its reader to\nunderstand or do. Inspect retained passages as well as newly added lines.\n\nAssign ownership by the reader's question, not by a Tutorial\u002FHow-to\u002FGuide label:\n\n- README explains the project's purpose, present adoption value, and entry points.\n- Book defines the overall model and responsibility contracts, explains how the\n  system accommodates new components, and teaches adoption, choices across\n  capabilities, and result interpretation through prose, mathematics, diagrams,\n  and explanatory pseudocode.\n- API Reference owns concrete API contracts and supported scope: class meanings,\n  components, basic usage, executable examples, exact argument\u002Fdefault rules,\n  exhaustive cases, execution order, formulas, preconditions, errors, mutation\n  guarantees, and numerical contracts. Its executable API examples belong in\n  the doctest workflow.\n- Independent Examples own complete runnable workflows whose value comes from\n  following an application end to end; their tests maintain executability.\n- Setup, CLI\u002Foperational reference, and format\u002Fintegration specifications own\n  their respective environment, command, authentication, and interoperability\n  details. Python API entries cannot substitute for those destinations.\n\nKeep application-focused, end-to-end tutorials and runnable workflows\ndiscoverable as independent Examples from the relevant capability, without\nmaking them a mandatory Book sequence. Related API operations may need a\ncomplete Reference example together rather than scattered call fragments.\nReference should serve both human and AI-assisted implementation.\n\nLabel Book pseudocode explicitly and use a non-executable presentation such as a\n`text` code block. Show only the steps or relationships needed for the explanation;\ndo not present invented methods as actual SDK APIs. Review the meaning, conditions,\nand claimed guarantees, and link to the executable Reference or Example. Book\npseudocode does not need imports, environment setup, or execution tests.\n\nOverlap alone is not a finding. A short safe-use warning or a counterexample\nteaching an operation's meaning may be necessary even when the API states the\nsame fact. Flag repetition when it adds contract detail without serving the\npage's learning goal; neither mathematical notation nor an API name alone\ndetermines where an explanation belongs.\n\nFor a relocation, decide whether any explanation of adoption value, overall flow,\nor choices across capabilities must remain in the Book. Removing an entire\nclass guide without leaving a shortened copy is valid. Preserve the needed\nmeaning, contracts, and runnable examples at their owning Reference or Example\ndestination before removing them or replacing Book code with pseudocode. Fill\nmissing destination content within the authorized scope or report the gap.\n\nWhen moving or removing an explanation, read its actual replacement and follow\nthe affected incoming entry through to the definition or usable procedure.\nA page, heading, anchor, or resolving link is not evidence that the explanation\nexists. Follow onward references until the reader reaches the needed content;\ndo not accept a chain that only sends them back to the removed explanation.\nThe replacement must be available in the reviewed PR\u002Frevision, not only in a\nlater stacked PR. Report an unmet route rather than recommending Ready while\nits replacement is still planned.\n\n## Surface API friction separately\n\nDo not absorb an awkward public API into increasingly elaborate explanations.\nWhen an ordinary reader task needs raw metadata keys, repeated low-level\nselection, or surprising call semantics, distinguish:\n\n- a missing introduction or poor explanation, which belongs at the responsible\n  Book or Reference destination;\n- a necessary domain distinction, which must be taught rather than hidden;\n- API friction, where the supported operation itself makes the task needlessly\n  difficult or its effects hard to discover.\n\nVerify an API candidate against the current implementation and a minimal user\nexample, not only the length of its explanation. Respect accepted design\ntradeoffs and explicit exclusions; do not reopen them without new evidence.\nSearch existing issues and PRs first, linking relevant work rather than\ncreating duplicates.\n\nFor a confirmed new API problem, file a separate follow-up issue when the task\nauthorizes issue creation, using `ommx-issue-triage`. In a read-only review,\nreport the candidate and request authority before posting. Include the reader's\ngoal, expected versus actual behavior, minimal code, source revision, affected\nBook passage, and current workaround. Describe the missing capability and\ndomain constraints without treating a proposed API signature as decided.\n\nLink the follow-up from the review record. Keep any documented workaround\naccurate and runnable at its owning destination; do not silently redesign the\nSDK in a Book PR. An ergonomic follow-up need not block the Book when the\ndocumented workflow is correct, but filing an issue does not excuse an incorrect\nexample or promise.\n\n## Reconcile changed explanations with the ledger\n\nThe Book-owned data is `docs\u002F_meta\u002Freading_paths\u002Fmanifest.json`, not part of the\nskill's instructions. It starts as a proposed design based on an explicitly\nrecorded revision, not a certification of the current Book.\n\nKeep the ledger focused on meaningful reader outcomes, explanation owners, and\nrepresentative direct-entry routes. Reuse valid semantic concept IDs; do not\ncreate a prerequisite node for every API name or require every operation to\nappear in a Book route. The existing concept\u002Fpage\u002Froute model and helpers can\nserve a new structure without preserving old genre-based IDs or role assignments.\nRecord project-specific chapters and feature inventories in the ledger, not here.\n\nFor each changed reader-facing page affecting prerequisites, introductions, or\nnavigation, compare the actual prose and Notebook cells with the affected\nconcept, page, and route contracts. Locate the introduction and first\nunderstanding-dependent use; check their order, scope, and entry knowledge\nagainst the declarations.\nThis comparison is required, not optional because the analyzer passes. If the\npage or concept is untracked, record that coverage gap. Distinguish a current\nreading defect from a declaration superseded by the accepted design. Update\naffected contracts when the task includes ledger edits; otherwise report the\nmismatch and any deferred migration without rewriting them or forcing prose\nback into the old structure. A skill-only change does not require a manifest\nmigration. Query only the affected subset, not the whole Book.\nThe query helper returns declarations alongside whole-manifest diagnostics,\neven when contracts are inconsistent. Use those diagnostics to interpret the\ntarget; successful lookup is not a consistency or readiness verdict.\n\nThe helper commands below are optional tools for inspecting the declarations;\nthey do not replace the required comparison. Select page\u002Fconcept IDs from the\ncurrent manifest; the IDs in these examples are illustrative. If used, run them\nfrom the repository root through its Python environment:\n\n```sh\nuv run --no-sync python .agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Fquery.py docs\u002F_meta\u002Freading_paths\u002Fmanifest.json concept class.membership\nuv run --no-sync python .agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Fquery.py docs\u002F_meta\u002Freading_paths\u002Fmanifest.json page P11\nuv run --no-sync python .agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Fanalyze.py docs\u002F_meta\u002Freading_paths\u002Fmanifest.json\n```\n\nUse the environment\u002Fversion appropriate to the checkout and honor its execution\npermissions. These helpers use only the standard library and no LLM or network.\nThey check declared sets and dependencies, not natural-language comprehension.\n\nBefore editing contracts or using a source-evidence bundle, read\n[the schema and evidence rules](references\u002Fschema.md). Keep Book-specific\nconcepts, owners, and paths in the ledger rather than copying them into this\nskill. A review-only request does not authorize rewriting the ledger or posting\nfindings externally.\n\nThe analyzer teaches a section's ordered `introduces` before checking its\n`uses`. Represent a use before an explanation as an earlier section; putting\nboth into one section can hide the defect. `mentions` never teaches, optional\nchildren are not inherited, and route joins retain only common knowledge.\n\n## Report evidence, not a mechanical readiness verdict\n\nFor each finding, name the reader\u002Froute, the unanswered question or concrete use\nand source position, the understanding not yet supplied, and the smallest change\nthat restores the intended outcome. Distinguish an omitted explanation from\nmerely unfamiliar spelling. Prefer a local gloss, a reorder, or deferring an\nunnecessary detail over making the reader complete another whole chapter.\n\nFor an explanation-placement finding, identify the reader's question, the\ncanonical owner, and whether any explanation still belongs in the Book; none\nmay be needed. When reviewing a PR, distinguish newly introduced problems from\ninherited cleanup candidates in the affected pages.\n\nKeep these outcomes separate:\n\n- observed text and outputs at the reviewed revision;\n- consistency of the proposed learning contracts;\n- manual review of purpose, selection guidance, explanatory sufficiency, and\n  entry-page cognitive load;\n- code execution, version compatibility, and mathematical\u002FAPI correctness.\n\nBefore concluding, leave a concise [current-revision review record](references\u002Fschema.md#current-revision-review-record)\nin the current chat or an authorized issue\u002FPR discussion. Do not add repository\nreview-note files unless explicitly requested. Identify the reviewed revision,\nparagraphs or Notebook cells, reader routes, and actual introduction\u002Fuse and\ndestination evidence. Distinguish checked coverage from unresolved or unreviewed\nroutes; do not create a whole-Book PASS report for a scoped review.\n\nRecommend or mark Ready only for the reviewed scope and within the task's\nauthorization, after the affected prose and applicable contracts have been\nreconciled, the review record is present, and moved explanations have usable\ndestinations at that revision. A contract PASS or a warning-free Sphinx build\ncannot satisfy those conditions. Keep the\nreading review incomplete when an affected route still has a gap.\nBuild\u002FAPI-reference checks remain the responsibility of the existing Sphinx\nworkflow; do not broaden this review into SDK changes or a Book-wide redesign.\n","# Book Reading Review\n\nReview what a reader can understand, decide, or do at each point. OMMX is designed\nas an extensible system: declarations, analyses, and transformations are added\non a common problem representation while preserving shared meanings and\nresponsibilities. Connect that design to adoption value and reader choices.\nExplain it in optimization terms without requiring compiler knowledge.\n\nOMMX defines problem and candidate semantics independently of a solver. Keep\nthat common model separate from an Adapter's execution contract and the\nguarantees of an individual transformation. Preserving problem structure lets\nlater processing use its meaning; reconstruction, feasibility, objective values,\nand optimality remain distinct guarantees.\n\nThis workflow can stand alone for a reader-comprehension question. A change\nlimited to API generation, directives, or Sphinx build\u002Frender\u002Flink correctness\nbelongs to `sphinx-docs-review` and does not require this skill or its ledger.\nApply both only when the request includes both concerns; do not load the other\nskill merely because a Book file changed.\n\nWhen introducing or explaining OMMX domain distinctions, use\n[OMMX Terminology](..\u002Fommx-terminology\u002FSKILL.md) for the naming policy and its\ndefinition owners. Keep detailed user-facing meanings in the Book and Reference.\n\n## Establish the reader and source\n\n- Resolve the requested PR\u002Frevision and read its actual files. A local checkout\n  may contain a later stacked PR; do not review that as the requested change.\n- Resolve the current editorial direction from the task and accepted design.\n  Historical navigation, page roles, and ledger declarations are inputs to\n  review, not constraints that override a newer design.\n- Identify the reader's goal, starting knowledge, entry link, and useful stopping\n  point, including the understanding or decision the page should enable.\n  Knowing Python and ordinary optimization does not imply knowing OMMX types,\n  retained variables, inactive constraints, or Preparation.\n- Follow the entry that the navigation promises, including direct chapter or\n  Reference entry and alternative routes. Organize the primary navigation by\n  reader purpose and the objects they work with; document genres and chapter\n  numbers do not establish prerequisites. A declared prerequisite is different\n  from a recommended link.\n- Separate conceptual knowledge from execution dependencies. Book pseudocode\n  has no runtime prerequisite; runnable Reference or Example code still needs\n  its imports, input data, and prior runtime state, including hidden cells.\n\nReview Book pseudocode and illustrative results for explanatory and mathematical\ncorrectness, not executability. Existing Notebook execution remains owned by the\nrepository's separate tests; do not add Notebook reruns to a reading review or\nskip existing tests because the Book policy changed. Keep documented SDK versions\nand prerequisites accurate without treating a Book build as execution evidence.\n\n## Check purpose and capability explanations\n\nFor README and overview work, check whether readers can explain what OMMX\nprovides, why it matters to them, which responsibilities belong to common\nprocessing, which choices remain theirs, and where to go next. A list of APIs\nor an aspiration alone does not answer those questions. Keep the modeler,\ncommon OMMX processing, Adapter, and execution backend's responsibilities\nunderstandable without a catalogue of implementation details.\n\nFor a capability explanation, identify its use, its place in the overall flow,\nand the choices left to the reader. A small example, diagram, or counterexample\nshould teach the meaning or decision at hand. Retain the conditions needed to\ninterpret that example correctly; do not require a full implementation recipe\nfor every feature in the Book.\n\n## Explain responsibility contracts and extensible design\n\nThe Book defines OMMX's accepted domain responsibilities independently of how\ncompletely individual implementations realize them. State these contracts\nexplicitly; do not weaken them to match implementation gaps or relocate them\nentirely to API Reference. For example, an Adapter must preserve the meaning of\naccepted input, interpret backend reports against the problem actually solved,\nand carry conclusions back only with the required transformation guarantees.\nA stated contract is not evidence that every implementation already meets it.\nAPI Reference owns the concrete API contracts and supported scope.\n\nExplain how new declarations, analyses, transformations, and solving methods\njoin the same system while retaining its semantic and responsibility boundaries.\nIntegrate this explanation into the passages that own those relationships. Do\nnot turn extensibility into a separate development-direction section or a list\nof planned features. Explain what must stay true as components are added, such\nas retaining structure before choosing a formulation, stating applicability and\npreservation guarantees, and maintaining the correspondence needed to interpret\nresults. Use examples to teach those principles without implying that every\nexample has a complete implementation.\n\nTreat implementation coverage as supporting information. A brief note that\nsupport varies by feature or Adapter, with a usable API Reference destination,\nis normally sufficient. Do not make an ordinary Book edit depend on a detailed\nimplementation census or maintain a second availability matrix in the Book.\nVerify concrete API calls and executable claims when the text relies on them;\nperform broader implementation or feature-coverage audits when requested.\n\n## Audit feature coverage when requested\n\nFor a whole-Book coverage audit, start from the public SDK at the documented\nversion and the reader tasks it supports, including tasks absent from the Book\nor ledger. Group APIs by useful operations rather than requiring a page for\nevery method. Check the public bindings\u002Fexports against their owning\nimplementation; distinguish released capabilities from development-only APIs.\n\nAudit the Book's coverage of adoption reasons and choices across capabilities,\nwith entry paths to the relevant Reference or Examples. Individual API meanings\nand procedures may be fully owned by Reference; their absence from the Book is\nnot a coverage gap. An API catalogue or a release note alone does not answer the\nBook's purpose and selection questions. Inspect executable examples at their\nowning destination and record whether coverage is usable, only mentioned,\nplanned, absent, or deliberately excluded. Distinguish missing implementation of\nan existing plan from a proposed expansion of scope.\n\nReconcile gaps with the accepted workstream scope and explanation ownership\nbelow. Keep feature inventories in the review record or Book-owned ledger,\nnot in this skill. Ordinary page\u002FPR reviews remain limited to affected tasks;\nthey do not require a whole-SDK inventory.\n\n## Inspect introductions and uses\n\nFor the affected passage, classify each relevant concept as an entry\nprerequisite, local introduction, understanding-dependent use, or mere mention.\nRead enough surrounding text and the linked explanation to justify the choice.\n\n- A definition, a small example with its interpretation, or a short local gloss\n  can introduce the capability needed here. The detailed owner page need not be\n  mandatory reading. Its link alone does not teach the concept.\n- A type name, repr field, output column, navigation label, or optional section\n  does not establish mastery. Conversely, an unfamiliar API name is not itself a\n  finding when the example and adjacent explanation make its role clear.\n- Check the capability's scope. Reading a Solution's values is not the same as\n  understanding transformed feasibility or optimality. A Binary example does\n  not teach SemiInteger\u002FSemiContinuous domains. Split an overly broad concept\n  when a real use needs a narrower capability, not for every API spelling.\n- Inspect order inside a section, not just page order. A reference from an early\n  passage to a later page that requires the unfinished passage's knowledge can\n  leave a learning gap. Two pages linking to each other is not, by itself, a\n  prerequisite cycle.\n- Keep the learning budget proportional to the task. A correct overview can\n  still overload an entry with unexplained names. Move nonessential mechanics\n  to the detailed destination and teach only what the current explanation or\n  example needs.\n\n## Inspect explanation ownership\n\nFor each affected page, identify what the passage enables its reader to\nunderstand or do. Inspect retained passages as well as newly added lines.\n\nAssign ownership by the reader's question, not by a Tutorial\u002FHow-to\u002FGuide label:\n\n- README explains the project's purpose, present adoption value, and entry points.\n- Book defines the overall model and responsibility contracts, explains how the\n  system accommodates new components, and teaches adoption, choices across\n  capabilities, and result interpretation through prose, mathematics, diagrams,\n  and explanatory pseudocode.\n- API Reference owns concrete API contracts and supported scope: class meanings,\n  components, basic usage, executable examples, exact argument\u002Fdefault rules,\n  exhaustive cases, execution order, formulas, preconditions, errors, mutation\n  guarantees, and numerical contracts. Its executable API examples belong in\n  the doctest workflow.\n- Independent Examples own complete runnable workflows whose value comes from\n  following an application end to end; their tests maintain executability.\n- Setup, CLI\u002Foperational reference, and format\u002Fintegration specifications own\n  their respective environment, command, authentication, and interoperability\n  details. Python API entries cannot substitute for those destinations.\n\nKeep application-focused, end-to-end tutorials and runnable workflows\ndiscoverable as independent Examples from the relevant capability, without\nmaking them a mandatory Book sequence. Related API operations may need a\ncomplete Reference example together rather than scattered call fragments.\nReference should serve both human and AI-assisted implementation.\n\nLabel Book pseudocode explicitly and use a non-executable presentation such as a\n`text` code block. Show only the steps or relationships needed for the explanation;\ndo not present invented methods as actual SDK APIs. Review the meaning, conditions,\nand claimed guarantees, and link to the executable Reference or Example. Book\npseudocode does not need imports, environment setup, or execution tests.\n\nOverlap alone is not a finding. A short safe-use warning or a counterexample\nteaching an operation's meaning may be necessary even when the API states the\nsame fact. Flag repetition when it adds contract detail without serving the\npage's learning goal; neither mathematical notation nor an API name alone\ndetermines where an explanation belongs.\n\nFor a relocation, decide whether any explanation of adoption value, overall flow,\nor choices across capabilities must remain in the Book. Removing an entire\nclass guide without leaving a shortened copy is valid. Preserve the needed\nmeaning, contracts, and runnable examples at their owning Reference or Example\ndestination before removing them or replacing Book code with pseudocode. Fill\nmissing destination content within the authorized scope or report the gap.\n\nWhen moving or removing an explanation, read its actual replacement and follow\nthe affected incoming entry through to the definition or usable procedure.\nA page, heading, anchor, or resolving link is not evidence that the explanation\nexists. Follow onward references until the reader reaches the needed content;\ndo not accept a chain that only sends them back to the removed explanation.\nThe replacement must be available in the reviewed PR\u002Frevision, not only in a\nlater stacked PR. Report an unmet route rather than recommending Ready while\nits replacement is still planned.\n\n## Surface API friction separately\n\nDo not absorb an awkward public API into increasingly elaborate explanations.\nWhen an ordinary reader task needs raw metadata keys, repeated low-level\nselection, or surprising call semantics, distinguish:\n\n- a missing introduction or poor explanation, which belongs at the responsible\n  Book or Reference destination;\n- a necessary domain distinction, which must be taught rather than hidden;\n- API friction, where the supported operation itself makes the task needlessly\n  difficult or its effects hard to discover.\n\nVerify an API candidate against the current implementation and a minimal user\nexample, not only the length of its explanation. Respect accepted design\ntradeoffs and explicit exclusions; do not reopen them without new evidence.\nSearch existing issues and PRs first, linking relevant work rather than\ncreating duplicates.\n\nFor a confirmed new API problem, file a separate follow-up issue when the task\nauthorizes issue creation, using `ommx-issue-triage`. In a read-only review,\nreport the candidate and request authority before posting. Include the reader's\ngoal, expected versus actual behavior, minimal code, source revision, affected\nBook passage, and current workaround. Describe the missing capability and\ndomain constraints without treating a proposed API signature as decided.\n\nLink the follow-up from the review record. Keep any documented workaround\naccurate and runnable at its owning destination; do not silently redesign the\nSDK in a Book PR. An ergonomic follow-up need not block the Book when the\ndocumented workflow is correct, but filing an issue does not excuse an incorrect\nexample or promise.\n\n## Reconcile changed explanations with the ledger\n\nThe Book-owned data is `docs\u002F_meta\u002Freading_paths\u002Fmanifest.json`, not part of the\nskill's instructions. It starts as a proposed design based on an explicitly\nrecorded revision, not a certification of the current Book.\n\nKeep the ledger focused on meaningful reader outcomes, explanation owners, and\nrepresentative direct-entry routes. Reuse valid semantic concept IDs; do not\ncreate a prerequisite node for every API name or require every operation to\nappear in a Book route. The existing concept\u002Fpage\u002Froute model and helpers can\nserve a new structure without preserving old genre-based IDs or role assignments.\nRecord project-specific chapters and feature inventories in the ledger, not here.\n\nFor each changed reader-facing page affecting prerequisites, introductions, or\nnavigation, compare the actual prose and Notebook cells with the affected\nconcept, page, and route contracts. Locate the introduction and first\nunderstanding-dependent use; check their order, scope, and entry knowledge\nagainst the declarations.\nThis comparison is required, not optional because the analyzer passes. If the\npage or concept is untracked, record that coverage gap. Distinguish a current\nreading defect from a declaration superseded by the accepted design. Update\naffected contracts when the task includes ledger edits; otherwise report the\nmismatch and any deferred migration without rewriting them or forcing prose\nback into the old structure. A skill-only change does not require a manifest\nmigration. Query only the affected subset, not the whole Book.\nThe query helper returns declarations alongside whole-manifest diagnostics,\neven when contracts are inconsistent. Use those diagnostics to interpret the\ntarget; successful lookup is not a consistency or readiness verdict.\n\nThe helper commands below are optional tools for inspecting the declarations;\nthey do not replace the required comparison. Select page\u002Fconcept IDs from the\ncurrent manifest; the IDs in these examples are illustrative. If used, run them\nfrom the repository root through its Python environment:\n\n```sh\nuv run --no-sync python .agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Fquery.py docs\u002F_meta\u002Freading_paths\u002Fmanifest.json concept class.membership\nuv run --no-sync python .agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Fquery.py docs\u002F_meta\u002Freading_paths\u002Fmanifest.json page P11\nuv run --no-sync python .agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Fanalyze.py docs\u002F_meta\u002Freading_paths\u002Fmanifest.json\n```\n\nUse the environment\u002Fversion appropriate to the checkout and honor its execution\npermissions. These helpers use only the standard library and no LLM or network.\nThey check declared sets and dependencies, not natural-language comprehension.\n\nBefore editing contracts or using a source-evidence bundle, read\n[the schema and evidence rules](references\u002Fschema.md). Keep Book-specific\nconcepts, owners, and paths in the ledger rather than copying them into this\nskill. A review-only request does not authorize rewriting the ledger or posting\nfindings externally.\n\nThe analyzer teaches a section's ordered `introduces` before checking its\n`uses`. Represent a use before an explanation as an earlier section; putting\nboth into one section can hide the defect. `mentions` never teaches, optional\nchildren are not inherited, and route joins retain only common knowledge.\n\n## Report evidence, not a mechanical readiness verdict\n\nFor each finding, name the reader\u002Froute, the unanswered question or concrete use\nand source position, the understanding not yet supplied, and the smallest change\nthat restores the intended outcome. Distinguish an omitted explanation from\nmerely unfamiliar spelling. Prefer a local gloss, a reorder, or deferring an\nunnecessary detail over making the reader complete another whole chapter.\n\nFor an explanation-placement finding, identify the reader's question, the\ncanonical owner, and whether any explanation still belongs in the Book; none\nmay be needed. When reviewing a PR, distinguish newly introduced problems from\ninherited cleanup candidates in the affected pages.\n\nKeep these outcomes separate:\n\n- observed text and outputs at the reviewed revision;\n- consistency of the proposed learning contracts;\n- manual review of purpose, selection guidance, explanatory sufficiency, and\n  entry-page cognitive load;\n- code execution, version compatibility, and mathematical\u002FAPI correctness.\n\nBefore concluding, leave a concise [current-revision review record](references\u002Fschema.md#current-revision-review-record)\nin the current chat or an authorized issue\u002FPR discussion. Do not add repository\nreview-note files unless explicitly requested. Identify the reviewed revision,\nparagraphs or Notebook cells, reader routes, and actual introduction\u002Fuse and\ndestination evidence. Distinguish checked coverage from unresolved or unreviewed\nroutes; do not create a whole-Book PASS report for a scoped review.\n\nRecommend or mark Ready only for the reviewed scope and within the task's\nauthorization, after the affected prose and applicable contracts have been\nreconciled, the review record is present, and moved explanations have usable\ndestinations at that revision. A contract PASS or a warning-free Sphinx build\ncannot satisfy those conditions. Keep the\nreading review incomplete when an affected route still has a gap.\nBuild\u002FAPI-reference checks remain the responsibility of the existing Sphinx\nworkflow; do not broaden this review into SDK changes or a Book-wide redesign.\n",{"name":5,"description":7},"main","e78914833dc7963f9ebff7acfe211cb81d910716",".agents\u002Fskills\u002Fbook-reading-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":64,"prompt":74,"zipAvailable":75},[65,68,71],{"tool":66,"command":67},"npx","npx skills add Jij-Inc\u002Fommx --skill book-reading-review",{"tool":69,"command":70},"bunx","bunx skills add Jij-Inc\u002Fommx --skill book-reading-review",{"tool":72,"command":73},"pnpm","pnpm dlx skills add Jij-Inc\u002Fommx --skill book-reading-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbook-reading-review\u002FSKILL.md",true,[77,83,89,95,99,103],{"path":78,"resourceType":79,"resourceTypeDesc":80,"sizeBytes":81,"sourceHtmlUrl":82},".gitignore","OTHER","其他",13,"https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbook-reading-review\u002F.gitignore",{"path":84,"resourceType":85,"resourceTypeDesc":86,"sizeBytes":87,"sourceHtmlUrl":88},"references\u002Fschema.md","REFERENCE","参考文档",11994,"https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbook-reading-review\u002Freferences\u002Fschema.md",{"path":90,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":93,"sourceHtmlUrl":94},"scripts\u002Fanalyze.py","SCRIPT","脚本",19172,"https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Fanalyze.py",{"path":96,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":97,"sourceHtmlUrl":98},"scripts\u002Fquery.py",10885,"https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Fquery.py",{"path":100,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":101,"sourceHtmlUrl":102},"scripts\u002Ftest_analyze.py",16835,"https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Ftest_analyze.py",{"path":104,"resourceType":91,"resourceTypeDesc":92,"sizeBytes":105,"sourceHtmlUrl":106},"scripts\u002Ftest_query.py",19463,"https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fbook-reading-review\u002Fscripts\u002Ftest_query.py",[108,119,143,162,183,203],{"skillNo":109,"name":45,"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":49},"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",[],[45,114,115,116,117,118],"for","usage","distribution","guidance","placeholder",{"skillNo":120,"name":121,"nameZh":6,"description":122,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":123,"categories":124,"keywords":125,"publishedAt":49},"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",[],[126,127,128,129,130,114,131,132,133,134,135,136,137,138,139,140,141,142],"release note","release","note","git","version","true","english","entries","japanese","append","edit","read","gh","Bash","release notes","pr","notes",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"publishedAt":49},"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",[],[150,29,151,152,153,154,155,156,114,157,33,158,39,159,45,160,36,161,40,46],"sphinx docs review","docs","docs review","references","correctness","pages","consistency","structure","use","technical","learning","documentation",{"skillNo":163,"name":164,"nameZh":6,"description":165,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":166,"categories":167,"keywords":174,"publishedAt":49},"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",[168,171],{"categoryNo":169,"categoryName":170,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":172,"categoryName":173,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000036","内容创作者",[175,176,177,178,179,46,37,180,157,158,181,45,182],"rust module boundary","boundary","module","rust","super","public api","public","writing",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":189,"publishedAt":49},"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",[],[190,191,192,178,193,158,181,45,194,195,196,37,197,198,199,200,201,202],"error","rust error handling","error handling","map","sdk","python","local","signal","result","implementing","types","binding","propagation",{"skillNo":204,"name":121,"nameZh":6,"description":205,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":206,"categories":207,"keywords":208,"publishedAt":49},"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",[],[128,126,127,209,114,210,133,135,211,45,140,141,142,178,194,195],"sdk release","relevant","python sdk"]