[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6BXJSMANFNGY62M6RMC7RA0":3,"skill-same:01M6BXJSMANFNGY62M6RMC7RA0":78},{"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":40,"linkOnly":41,"markdownContent":42,"markdownBody":43,"frontMatter":44,"refName":45,"commitSha":46,"skillDirectory":47,"forksCount":48,"repositoryHtmlUrl":49,"repositoryHomepageUrl":50,"ownerHtmlUrl":51,"ownerBlogUrl":52,"ownerDescription":6,"updatedAt":53,"install":54,"resources":67},"01M6BXJSMANFNGY62M6RMC7RA0","ommx-issue-triage",null,"Use when triaging, labeling, closing, rewriting, or organizing GitHub issues in Jij-Inc\u002Fommx, especially when deciding consistent issue labels, separating issue backlog labels from PR release-note labels, auditing open issues, or applying GitHub issue metadata changes.","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\u002Fommx-issue-triage\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38,39],"triage","issue","ommx issue triage","ommx","issue triage","release","issues","metadata","open","github issues","pr","use","github issue","github","issue labels","backlog","note","closing","changes","labels","when","2026-11-10 10:12:30",false,"---\nname: ommx-issue-triage\ndescription: Use when triaging, labeling, closing, rewriting, or organizing GitHub issues in Jij-Inc\u002Fommx, especially when deciding consistent issue labels, separating issue backlog labels from PR release-note labels, auditing open issues, or applying GitHub issue metadata changes.\n---\n\n# OMMX Issue Triage\n\nUse this skill to manage OMMX GitHub issues consistently. Keep the live GitHub\nstate as the source of truth; do not rely on stale memory, old issue summaries,\nor local assumptions when labels, open\u002Fclosed state, assignees, or milestones\nmatter.\n\n## Scope\n\nApply this skill to issues, not PR release preparation. When the task is to\nlabel a PR for release notes, hand off to the PR review or publish workflow and\njudge labels from the actual diff.\n\nUse labels rather than GitHub Issue type for normal issue management in this\nrepo. Current GitHub CLI versions may expose issue type, but OMMX's triage and\nrelease workflows are label-based, and CLI availability varies across agent\nenvironments.\n\n## Label Model\n\nTreat labels in two groups. Keep label names short and stable; improve\nconsistency through descriptions and usage rules before creating new labels.\n\nRelease-note labels are shared with PRs and are interpreted by\n`.github\u002Frelease.yml`. Do not rename, delete, or change the meaning of these\nlabels during issue triage:\n\n- `breaking change`: accepted work intentionally breaks compatibility.\n- `bug`: observed incorrect behavior or failing workflow.\n- `proto`: accepted work changes protobuf schema or generated protobuf contract.\n- `python`: PR changes the Python SDK public API, generated stubs, or adapter\n  public API.\n- `rust`: PR changes the Rust SDK public API.\n- `documentation`: accepted work is primarily docs, examples, tutorials,\n  migration guides, or API reference.\n- `dependencies`: dependency update work; GitHub release notes exclude it.\n\nNon-release labels are decision aids. Design them from the viewpoint of who\nuses the label and what decision it supports; do not treat them as a flat\ntaxonomy.\n\nReporter-facing labels classify what kind of problem a library user is\nreporting:\n\n- `feature request`: user tried or planned to use OMMX and needs a missing\n  capability, API, format support, integration, or workflow.\n- `performance`: existing supported behavior works, but is slower, larger, or\n  less scalable than expected. Require benchmarks before claiming improvement.\n- `bug` is also reporter-facing, but it is a release-note label because bug-fix\n  PRs must be categorized in releases.\n\nDo not apply `rust` or `python` to issues. Those labels answer what API surface\nactually changed in a PR; an issue can discuss likely implementation areas\nwithout carrying a speculative API-change label.\n\nDeveloper-facing labels classify the implementation work:\n\n- `maintenance`: internal quality, repository operation, tooling, linting,\n  cleanup, migration hygiene, or development workflow work that is neither a\n  user feature nor an observed bug.\n- `rfc`: direction-setting issue used to reach agreement on API, schema,\n  architecture, semantics, responsibility boundary, or scope. Use this when the\n  outcome may be an accepted direction, rejection, or follow-up implementation\n  issues rather than a single concrete implementation PR.\n\nManager-facing labels classify backlog handling:\n\n- `workstream`: parent issue that tracks progress across multiple PRs, child\n  issues, or implementation slices. Do not use for single-PR work.\n- `needs info`: cannot be assigned or scoped until reproduction details,\n  expected behavior, affected version, or acceptance criteria are clarified.\n- `blocked`: work is accepted but waiting on an external dependency, upstream\n  decision, credential\u002Fpermission change, or prerequisite PR.\n- `help wanted`: scoped enough for an external contributor; maintainers welcome\n  help.\n- `good first issue`: small, low-risk, and well-specified enough for a new\n  contributor.\n\nTriage-outcome labels close or redirect work:\n\n- `duplicate`: same underlying work is tracked elsewhere.\n- `wontfix`: the work will not be pursued.\n\nAutomation labels such as `github_actions` and `python:uv` are Dependabot-owned\nPR labels in this repository. Ignore them during issue triage and do not apply\nthem manually to issues. If Dependabot noise becomes a problem, fix the\nDependabot configuration separately instead of repurposing these labels.\n\nDo not add domain labels such as `artifact`, `experiment`, `adapter`, or\n`dataset` just because an issue belongs to that area; those topics are\nsearchable from titles and bodies. Propose a new domain label only after several\nactive issues need the same planning queue and existing labels cannot express it\nwithout overloading release-note semantics.\n\nPrefer GitHub Projects or milestones over labels for priority, owner, status,\nand due date. Labels should remain stable filters, not a second project board.\n\n## Issue Relationships\n\nUse GitHub issue Relationships for strict issue-to-issue blocking\ndependencies. Treat them as the machine-readable dependency graph, not as a\ngeneral \"related issue\" list.\n\nAdd a Relationship when:\n\n- issue B cannot be implemented safely until issue A is decided or completed;\n- doing B before A would likely cause rework or produce an invalid API shape;\n- maintainers need the dependency graph to decide whether B is ready to start.\n\nDo not add a Relationship for loose topical links, follow-up reading,\nalternative proposals, same-area work, or \"nice to do together\" coordination.\nUse issue links in the body or comments for those cases.\n\nKeep the rationale outside the Relationship itself:\n\n- use the issue body for workstream status, child issue lists, accepted\n  decisions, and remaining work;\n- use comments for the audit trail explaining why a dependency was added,\n  removed, or reclassified;\n- use `workstream` for the parent issue that tracks progress across multiple\n  PRs or child issues, even when some children also have Relationships.\n\nThe `blocked` label is broader than Relationships: use it when accepted work is\nwaiting on an external dependency, upstream decision, permission, credential, or\nprerequisite PR. Use Relationships only for GitHub issue-to-issue dependencies.\n\nPrefer the supported `gh issue` fields and flags when the local GitHub CLI\nexposes them:\n\n```bash\ngh issue view 123 --repo Jij-Inc\u002Fommx --json number,title,blockedBy,blocking\ngh issue edit 456 --repo Jij-Inc\u002Fommx --add-blocked-by 123\ngh issue edit 123 --repo Jij-Inc\u002Fommx --add-blocking 456\n```\n\nBefore mutating Relationships, restate the exact dependency edge, for example\n\"`#123` blocks `#456`\". Use `--remove-blocked-by` or `--remove-blocking` to\nremove the same edge.\n\nSome agent environments have older `gh` versions whose `issue view --json` and\n`issue edit` commands do not expose Relationship fields or flags. In that case,\nfall back to GraphQL for reads:\n\n```bash\ngh api graphql -f query='\nquery($owner:String!, $repo:String!, $number:Int!) {\n  repository(owner:$owner, name:$repo) {\n    issue(number:$number) {\n      number\n      title\n      issueDependenciesSummary { totalBlockedBy totalBlocking }\n      blockedBy(first:50) {\n        totalCount\n        nodes { number title url repository { nameWithOwner } }\n      }\n      blocking(first:50) {\n        totalCount\n        nodes { number title url repository { nameWithOwner } }\n      }\n    }\n  }\n}' -f owner=Jij-Inc -f repo=ommx -F number=123\n```\n\nUse raw GraphQL mutations only when the supported `gh issue edit` flags are not\navailable in the local CLI.\n\n## Recommended GitHub Descriptions\n\nWhen brushing up labels on GitHub, prefer description-only updates unless the\nuser explicitly wants renames or color changes:\n\n| Label | Recommended description |\n| --- | --- |\n| `breaking change` | Accepted work intentionally breaks compatibility |\n| `bug` | Observed incorrect behavior or failing workflow |\n| `dependencies` | Dependency update work; excluded from release notes |\n| `blocked` | Accepted work is waiting on an external dependency or prerequisite |\n| `documentation` | Docs, examples, tutorials, migration guides, or API reference |\n| `duplicate` | Same underlying work is tracked elsewhere |\n| `feature request` | User needs a missing capability, API, format support, integration, or workflow |\n| `good first issue` | Small, well-scoped, low-risk issue for new contributors |\n| `help wanted` | Maintainers welcome external help on this scoped issue |\n| `maintenance` | Internal quality, repository operation, tooling, linting, or cleanup work |\n| `needs info` | Needs reproduction details, expected behavior, version, or acceptance criteria |\n| `performance` | Performance, scaling, storage size, streaming, or repeated-cost concern |\n| `proto` | Protobuf schema or generated protobuf contract changes |\n| `python` | PR changes the Python SDK public API, generated stubs, or adapter public API |\n| `rfc` | Direction-setting discussion for API, schema, architecture, semantics, or scope |\n| `rust` | PR changes the Rust SDK public API |\n| `workstream` | Parent issue tracking multiple PRs, child issues, or implementation slices |\n| `wontfix` | This work will not be pursued |\n\n## Triage Workflow\n\n1. Resolve live state.\n   - Read the current labels:\n     `gh label list --repo Jij-Inc\u002Fommx --limit 100 --json name,description,color`.\n   - Read current open issues:\n     `gh issue list --repo Jij-Inc\u002Fommx --state open --limit 100 --json number,title,labels,assignees,milestone,updatedAt,createdAt,url`.\n   - For unlabeled, stale, or ambiguous issues, fetch the issue body before\n     classifying. Titles alone are not enough.\n   - For dependency audits, read `blockedBy` and `blocking` through\n     `gh issue view --json number,title,blockedBy,blocking` when available.\n     If the local CLI reports unknown fields, fall back to GraphQL.\n\n2. Classify by audience and decision.\n   - Reporter-facing: is this a missing capability (`feature request`), an\n     observed failure (`bug`), or a speed\u002Fscale problem (`performance`)?\n   - Developer-facing: is this direction-setting (`rfc`), or internal\n     quality\u002Ftooling\u002Fprocess work (`maintenance`)?\n   - Manager-facing: is this a multi-PR parent (`workstream`), waiting for\n     information (`needs info`), blocked (`blocked`), suitable for outside help\n     (`help wanted`), or suitable for a newcomer (`good first issue`)?\n   - Ask what code\u002Fdocs would change if this issue were implemented.\n   - Do not add `rust` or `python` to issues based on expected implementation\n     surface. Apply those labels only to PRs after checking the actual diff and\n     confirming an SDK API change.\n   - If the issue carries API, architecture, invariant, or scope tradeoffs but\n     also has concrete acceptance criteria for a single implementation task, do\n     not add a separate label only for those tradeoffs; keep the reasoning in\n     the issue or PR body.\n   - If the issue describes an observed failure, use `bug` even when the eventual\n     fix will touch `rust`, `python`, `documentation`, or repository workflows.\n\n3. Treat `feature request`, `rfc`, and `workstream` as different questions.\n   - `feature request` answers: what new user-visible capability or workflow is\n     being requested?\n   - `rfc` answers: which API, schema, architecture, semantic, responsibility, or\n     scope direction should be accepted before implementation issues are split\n     out or PR work proceeds?\n   - `workstream` answers: where do we track progress, decisions, and remaining\n     work across multiple PRs or child issues?\n   - Use `feature request` for concrete implementation tasks even when the body\n     includes design questions.\n   - Use `rfc` for direction-setting documents whose natural result is a\n     decision or follow-up issues, not one direct PR.\n   - Use `workstream` for parent issues with status tables, checklists, child\n     issues, or multi-PR progress tracking.\n\n4. Preserve PR release-note semantics.\n   - Do not use `rust`, `python`, `proto`, `documentation`, or `bug` as vague\n     topic tags.\n   - Do not apply `rust` or `python` during issue triage. Use them only in PR\n     review\u002Frelease-note workflows after the actual API change is visible.\n   - Do not relabel open PRs from this skill unless the user explicitly asks; PR\n     labels should be judged from the actual diff.\n\n5. Propose before mutating.\n   - Unless the user explicitly asks to apply changes immediately, first show a\n     table with issue number, current labels, proposed labels, and reason.\n   - Separate additions from removals.\n   - Mark ambiguous cases and explain what evidence would decide them.\n\n6. Apply changes narrowly.\n   - Before a write, restate the exact issue number and label changes.\n   - Prefer additive label changes when the existing label is still correct.\n   - Remove a label only when it conflicts with the model above.\n   - Before mutating Relationships, restate the exact dependency edge, for\n     example \"`#1007` blocks `#1030`\".\n   - Do not encode loose related links as Relationships; use body links or\n     comments instead.\n   - Do not close, reopen, assign, or edit issue bodies as part of label cleanup\n     unless the user asks for that action.\n\n## Common OMMX Judgments\n\n- Do not use `rust` or `python` to say \"this issue probably touches that part of\n  the codebase.\" Those labels mean the reviewed PR changed the Rust or Python\n  SDK API.\n- Migration guides, Sphinx pages, API-reference wiring, tutorials, and example\n  prose may use `documentation` when the issue itself is documentation work.\n- Wire-format schema, protobuf root messages, generated message compatibility,\n  and Buf publication work may use `proto` when the issue is explicitly about\n  the protobuf contract.\n- GitHub token permissions, PR workflows, CI jobs, release automation, and\n  registry push jobs driven by Actions imply `bug` when they are failing\n  unexpectedly. Do not use `github_actions` for issue triage; it is a\n  Dependabot PR label in this repository.\n\n## Output\n\nFor audit-only requests, summarize counts and the highest-leverage cleanup\ngroups. For action requests, return the applied changes and any skipped\nambiguous issues. Keep the output issue-focused and avoid release-note prose\nunless PR labeling is explicitly in scope.\n","# OMMX Issue Triage\n\nUse this skill to manage OMMX GitHub issues consistently. Keep the live GitHub\nstate as the source of truth; do not rely on stale memory, old issue summaries,\nor local assumptions when labels, open\u002Fclosed state, assignees, or milestones\nmatter.\n\n## Scope\n\nApply this skill to issues, not PR release preparation. When the task is to\nlabel a PR for release notes, hand off to the PR review or publish workflow and\njudge labels from the actual diff.\n\nUse labels rather than GitHub Issue type for normal issue management in this\nrepo. Current GitHub CLI versions may expose issue type, but OMMX's triage and\nrelease workflows are label-based, and CLI availability varies across agent\nenvironments.\n\n## Label Model\n\nTreat labels in two groups. Keep label names short and stable; improve\nconsistency through descriptions and usage rules before creating new labels.\n\nRelease-note labels are shared with PRs and are interpreted by\n`.github\u002Frelease.yml`. Do not rename, delete, or change the meaning of these\nlabels during issue triage:\n\n- `breaking change`: accepted work intentionally breaks compatibility.\n- `bug`: observed incorrect behavior or failing workflow.\n- `proto`: accepted work changes protobuf schema or generated protobuf contract.\n- `python`: PR changes the Python SDK public API, generated stubs, or adapter\n  public API.\n- `rust`: PR changes the Rust SDK public API.\n- `documentation`: accepted work is primarily docs, examples, tutorials,\n  migration guides, or API reference.\n- `dependencies`: dependency update work; GitHub release notes exclude it.\n\nNon-release labels are decision aids. Design them from the viewpoint of who\nuses the label and what decision it supports; do not treat them as a flat\ntaxonomy.\n\nReporter-facing labels classify what kind of problem a library user is\nreporting:\n\n- `feature request`: user tried or planned to use OMMX and needs a missing\n  capability, API, format support, integration, or workflow.\n- `performance`: existing supported behavior works, but is slower, larger, or\n  less scalable than expected. Require benchmarks before claiming improvement.\n- `bug` is also reporter-facing, but it is a release-note label because bug-fix\n  PRs must be categorized in releases.\n\nDo not apply `rust` or `python` to issues. Those labels answer what API surface\nactually changed in a PR; an issue can discuss likely implementation areas\nwithout carrying a speculative API-change label.\n\nDeveloper-facing labels classify the implementation work:\n\n- `maintenance`: internal quality, repository operation, tooling, linting,\n  cleanup, migration hygiene, or development workflow work that is neither a\n  user feature nor an observed bug.\n- `rfc`: direction-setting issue used to reach agreement on API, schema,\n  architecture, semantics, responsibility boundary, or scope. Use this when the\n  outcome may be an accepted direction, rejection, or follow-up implementation\n  issues rather than a single concrete implementation PR.\n\nManager-facing labels classify backlog handling:\n\n- `workstream`: parent issue that tracks progress across multiple PRs, child\n  issues, or implementation slices. Do not use for single-PR work.\n- `needs info`: cannot be assigned or scoped until reproduction details,\n  expected behavior, affected version, or acceptance criteria are clarified.\n- `blocked`: work is accepted but waiting on an external dependency, upstream\n  decision, credential\u002Fpermission change, or prerequisite PR.\n- `help wanted`: scoped enough for an external contributor; maintainers welcome\n  help.\n- `good first issue`: small, low-risk, and well-specified enough for a new\n  contributor.\n\nTriage-outcome labels close or redirect work:\n\n- `duplicate`: same underlying work is tracked elsewhere.\n- `wontfix`: the work will not be pursued.\n\nAutomation labels such as `github_actions` and `python:uv` are Dependabot-owned\nPR labels in this repository. Ignore them during issue triage and do not apply\nthem manually to issues. If Dependabot noise becomes a problem, fix the\nDependabot configuration separately instead of repurposing these labels.\n\nDo not add domain labels such as `artifact`, `experiment`, `adapter`, or\n`dataset` just because an issue belongs to that area; those topics are\nsearchable from titles and bodies. Propose a new domain label only after several\nactive issues need the same planning queue and existing labels cannot express it\nwithout overloading release-note semantics.\n\nPrefer GitHub Projects or milestones over labels for priority, owner, status,\nand due date. Labels should remain stable filters, not a second project board.\n\n## Issue Relationships\n\nUse GitHub issue Relationships for strict issue-to-issue blocking\ndependencies. Treat them as the machine-readable dependency graph, not as a\ngeneral \"related issue\" list.\n\nAdd a Relationship when:\n\n- issue B cannot be implemented safely until issue A is decided or completed;\n- doing B before A would likely cause rework or produce an invalid API shape;\n- maintainers need the dependency graph to decide whether B is ready to start.\n\nDo not add a Relationship for loose topical links, follow-up reading,\nalternative proposals, same-area work, or \"nice to do together\" coordination.\nUse issue links in the body or comments for those cases.\n\nKeep the rationale outside the Relationship itself:\n\n- use the issue body for workstream status, child issue lists, accepted\n  decisions, and remaining work;\n- use comments for the audit trail explaining why a dependency was added,\n  removed, or reclassified;\n- use `workstream` for the parent issue that tracks progress across multiple\n  PRs or child issues, even when some children also have Relationships.\n\nThe `blocked` label is broader than Relationships: use it when accepted work is\nwaiting on an external dependency, upstream decision, permission, credential, or\nprerequisite PR. Use Relationships only for GitHub issue-to-issue dependencies.\n\nPrefer the supported `gh issue` fields and flags when the local GitHub CLI\nexposes them:\n\n```bash\ngh issue view 123 --repo Jij-Inc\u002Fommx --json number,title,blockedBy,blocking\ngh issue edit 456 --repo Jij-Inc\u002Fommx --add-blocked-by 123\ngh issue edit 123 --repo Jij-Inc\u002Fommx --add-blocking 456\n```\n\nBefore mutating Relationships, restate the exact dependency edge, for example\n\"`#123` blocks `#456`\". Use `--remove-blocked-by` or `--remove-blocking` to\nremove the same edge.\n\nSome agent environments have older `gh` versions whose `issue view --json` and\n`issue edit` commands do not expose Relationship fields or flags. In that case,\nfall back to GraphQL for reads:\n\n```bash\ngh api graphql -f query='\nquery($owner:String!, $repo:String!, $number:Int!) {\n  repository(owner:$owner, name:$repo) {\n    issue(number:$number) {\n      number\n      title\n      issueDependenciesSummary { totalBlockedBy totalBlocking }\n      blockedBy(first:50) {\n        totalCount\n        nodes { number title url repository { nameWithOwner } }\n      }\n      blocking(first:50) {\n        totalCount\n        nodes { number title url repository { nameWithOwner } }\n      }\n    }\n  }\n}' -f owner=Jij-Inc -f repo=ommx -F number=123\n```\n\nUse raw GraphQL mutations only when the supported `gh issue edit` flags are not\navailable in the local CLI.\n\n## Recommended GitHub Descriptions\n\nWhen brushing up labels on GitHub, prefer description-only updates unless the\nuser explicitly wants renames or color changes:\n\n| Label | Recommended description |\n| --- | --- |\n| `breaking change` | Accepted work intentionally breaks compatibility |\n| `bug` | Observed incorrect behavior or failing workflow |\n| `dependencies` | Dependency update work; excluded from release notes |\n| `blocked` | Accepted work is waiting on an external dependency or prerequisite |\n| `documentation` | Docs, examples, tutorials, migration guides, or API reference |\n| `duplicate` | Same underlying work is tracked elsewhere |\n| `feature request` | User needs a missing capability, API, format support, integration, or workflow |\n| `good first issue` | Small, well-scoped, low-risk issue for new contributors |\n| `help wanted` | Maintainers welcome external help on this scoped issue |\n| `maintenance` | Internal quality, repository operation, tooling, linting, or cleanup work |\n| `needs info` | Needs reproduction details, expected behavior, version, or acceptance criteria |\n| `performance` | Performance, scaling, storage size, streaming, or repeated-cost concern |\n| `proto` | Protobuf schema or generated protobuf contract changes |\n| `python` | PR changes the Python SDK public API, generated stubs, or adapter public API |\n| `rfc` | Direction-setting discussion for API, schema, architecture, semantics, or scope |\n| `rust` | PR changes the Rust SDK public API |\n| `workstream` | Parent issue tracking multiple PRs, child issues, or implementation slices |\n| `wontfix` | This work will not be pursued |\n\n## Triage Workflow\n\n1. Resolve live state.\n   - Read the current labels:\n     `gh label list --repo Jij-Inc\u002Fommx --limit 100 --json name,description,color`.\n   - Read current open issues:\n     `gh issue list --repo Jij-Inc\u002Fommx --state open --limit 100 --json number,title,labels,assignees,milestone,updatedAt,createdAt,url`.\n   - For unlabeled, stale, or ambiguous issues, fetch the issue body before\n     classifying. Titles alone are not enough.\n   - For dependency audits, read `blockedBy` and `blocking` through\n     `gh issue view --json number,title,blockedBy,blocking` when available.\n     If the local CLI reports unknown fields, fall back to GraphQL.\n\n2. Classify by audience and decision.\n   - Reporter-facing: is this a missing capability (`feature request`), an\n     observed failure (`bug`), or a speed\u002Fscale problem (`performance`)?\n   - Developer-facing: is this direction-setting (`rfc`), or internal\n     quality\u002Ftooling\u002Fprocess work (`maintenance`)?\n   - Manager-facing: is this a multi-PR parent (`workstream`), waiting for\n     information (`needs info`), blocked (`blocked`), suitable for outside help\n     (`help wanted`), or suitable for a newcomer (`good first issue`)?\n   - Ask what code\u002Fdocs would change if this issue were implemented.\n   - Do not add `rust` or `python` to issues based on expected implementation\n     surface. Apply those labels only to PRs after checking the actual diff and\n     confirming an SDK API change.\n   - If the issue carries API, architecture, invariant, or scope tradeoffs but\n     also has concrete acceptance criteria for a single implementation task, do\n     not add a separate label only for those tradeoffs; keep the reasoning in\n     the issue or PR body.\n   - If the issue describes an observed failure, use `bug` even when the eventual\n     fix will touch `rust`, `python`, `documentation`, or repository workflows.\n\n3. Treat `feature request`, `rfc`, and `workstream` as different questions.\n   - `feature request` answers: what new user-visible capability or workflow is\n     being requested?\n   - `rfc` answers: which API, schema, architecture, semantic, responsibility, or\n     scope direction should be accepted before implementation issues are split\n     out or PR work proceeds?\n   - `workstream` answers: where do we track progress, decisions, and remaining\n     work across multiple PRs or child issues?\n   - Use `feature request` for concrete implementation tasks even when the body\n     includes design questions.\n   - Use `rfc` for direction-setting documents whose natural result is a\n     decision or follow-up issues, not one direct PR.\n   - Use `workstream` for parent issues with status tables, checklists, child\n     issues, or multi-PR progress tracking.\n\n4. Preserve PR release-note semantics.\n   - Do not use `rust`, `python`, `proto`, `documentation`, or `bug` as vague\n     topic tags.\n   - Do not apply `rust` or `python` during issue triage. Use them only in PR\n     review\u002Frelease-note workflows after the actual API change is visible.\n   - Do not relabel open PRs from this skill unless the user explicitly asks; PR\n     labels should be judged from the actual diff.\n\n5. Propose before mutating.\n   - Unless the user explicitly asks to apply changes immediately, first show a\n     table with issue number, current labels, proposed labels, and reason.\n   - Separate additions from removals.\n   - Mark ambiguous cases and explain what evidence would decide them.\n\n6. Apply changes narrowly.\n   - Before a write, restate the exact issue number and label changes.\n   - Prefer additive label changes when the existing label is still correct.\n   - Remove a label only when it conflicts with the model above.\n   - Before mutating Relationships, restate the exact dependency edge, for\n     example \"`#1007` blocks `#1030`\".\n   - Do not encode loose related links as Relationships; use body links or\n     comments instead.\n   - Do not close, reopen, assign, or edit issue bodies as part of label cleanup\n     unless the user asks for that action.\n\n## Common OMMX Judgments\n\n- Do not use `rust` or `python` to say \"this issue probably touches that part of\n  the codebase.\" Those labels mean the reviewed PR changed the Rust or Python\n  SDK API.\n- Migration guides, Sphinx pages, API-reference wiring, tutorials, and example\n  prose may use `documentation` when the issue itself is documentation work.\n- Wire-format schema, protobuf root messages, generated message compatibility,\n  and Buf publication work may use `proto` when the issue is explicitly about\n  the protobuf contract.\n- GitHub token permissions, PR workflows, CI jobs, release automation, and\n  registry push jobs driven by Actions imply `bug` when they are failing\n  unexpectedly. Do not use `github_actions` for issue triage; it is a\n  Dependabot PR label in this repository.\n\n## Output\n\nFor audit-only requests, summarize counts and the highest-leverage cleanup\ngroups. For action requests, return the applied changes and any skipped\nambiguous issues. Keep the output issue-focused and avoid release-note prose\nunless PR labeling is explicitly in scope.\n",{"name":5,"description":7},"main","abab1660a3718eb5ff83cb7e2a4d4d09975a84ee",".agents\u002Fskills\u002Fommx-issue-triage",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":55,"prompt":65,"zipAvailable":66},[56,59,62],{"tool":57,"command":58},"npx","npx skills add Jij-Inc\u002Fommx --skill ommx-issue-triage",{"tool":60,"command":61},"bunx","bunx skills add Jij-Inc\u002Fommx --skill ommx-issue-triage",{"tool":63,"command":64},"pnpm","pnpm dlx skills add Jij-Inc\u002Fommx --skill ommx-issue-triage","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fommx-issue-triage\u002FSKILL.md",true,[68,74],{"path":69,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":72,"sourceHtmlUrl":73},"agents\u002Fopenai.yaml","REFERENCE","参考文档",121,"https:\u002F\u002Fgithub.com\u002FJij-Inc\u002Fommx\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Fommx-issue-triage\u002Fagents\u002Fopenai.yaml",{"path":75,"resourceType":70,"resourceTypeDesc":71,"sizeBytes":76,"sourceHtmlUrl":77},"references\u002Fdetailed-guide.md",36653,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-azure-functions\u002Freferences\u002Fdetailed-guide.md",[79,90,111,135,160,180],{"skillNo":80,"name":22,"nameZh":6,"description":81,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":82,"categories":83,"keywords":84,"publishedAt":40},"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",[],[22,85,86,87,88,89],"for","usage","distribution","guidance","placeholder",{"skillNo":91,"name":92,"nameZh":6,"description":93,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":94,"categories":95,"keywords":96,"publishedAt":40},"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",[],[97,24,35,98,99,85,100,101,102,103,104,105,106,107,108,109,29,110],"release note","git","version","true","english","entries","japanese","append","edit","read","gh","Bash","release notes","notes",{"skillNo":112,"name":113,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":117,"publishedAt":40},"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",[],[118,119,120,121,122,123,124,125,85,126,127,30,128,129,22,130,131,132,133,134],"sphinx docs review","review","docs","docs review","references","correctness","pages","consistency","structure","build","generated","technical","learning","wiring","documentation","design","api",{"skillNo":136,"name":137,"nameZh":6,"description":138,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":139,"categories":140,"keywords":151,"publishedAt":40},"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",[141,146],{"categoryNo":142,"categoryName":143,"taxonomyType":144,"taxonomyTypeDesc":145},"01JBSEEDCAT000000000000018","写作与文案","SCENARIO","使用场景",{"categoryNo":147,"categoryName":148,"taxonomyType":149,"taxonomyTypeDesc":150},"01JBSEEDCAT000000000000036","内容创作者","PROFESSION","适用职业",[152,153,154,155,156,134,39,157,126,30,158,22,159],"rust module boundary","boundary","module","rust","super","public api","public","writing",{"skillNo":161,"name":162,"nameZh":6,"description":163,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":164,"categories":165,"keywords":166,"publishedAt":40},"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",[],[167,168,169,155,170,30,158,22,171,172,173,39,174,175,176,177,178,179],"error","rust error handling","error handling","map","sdk","python","local","signal","result","implementing","types","binding","propagation",{"skillNo":181,"name":92,"nameZh":6,"description":182,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":183,"categories":184,"keywords":185,"publishedAt":40},"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",[],[35,97,24,186,85,187,102,104,188,22,109,29,110,155,171,172],"sdk release","relevant","python sdk"]