Review Issue Skill
Use this skill when the user wants to understand one or more issues in an ontology repository—for example to pick work, assess difficulty, or see what a new term request (NTR) or other issue requires. You summarize issue type, required fields (vs any template), labels, and suitability for a first contribution or agent-driven change.
When to Use
- User asks to review an issue (by number or URL) or "is this a good first issue".
- User wants to summarize open issues for a repo (e.g. list by type, filter by label).
- User asks "what does this NTR need" or what to provide for a synonym/obsoletion/term-merge issue.
- After analyze-project or clone-project: to choose which issue to implement before making edits.
Use web fetch (GitHub issue/API pages) or, if the repo is cloned under projects/<slug>/, you can combine with reading CONTRIBUTING/issue templates from disk. Do not name specific real-world ontologies as examples; use hypotheticals (e.g. "an OBO ontology", "a repo with NTR templates").
Workflow
- Identify repo and issue(s): From the user's message, get the repo (owner/name or URL) and either a single issue number (or URL) or a request to list/filter issues (e.g. open, with label "good first issue" or "New term request").
- Fetch issue data: For each issue, obtain title, body, labels, and if possible the issue template used (from
.github/ISSUE_TEMPLATE/ or from the issue form). Use the GitHub web interface or API (e.g. fetch issue page, list issues).
- Classify: For each issue, determine:
- Type: e.g. new term request (NTR), synonym, definition, obsoletion, term merge, missing parent/superclass, bug, documentation, refactoring, mapping.
- Labels: workflow/type labels (NTR, bug, help wanted, good first issue) and any domain/project labels.
- Required fields: From the issue template or CONTRIBUTING, what the maintainers expect (e.g. label, definition, parent, PMIDs, hierarchy position, replace_by/consider for obsoletion).
- Suitability: Whether it looks like a good first contribution, or agent-friendly (well-scoped, template-driven), or needs more discussion/clarification.
- Summarize: Produce a short review (see Output format).
Output Format
For one issue:
- Issue: #N – title.
- Type: e.g. NTR, synonym, obsoletion, bug.
- Labels: list relevant labels.
- Required / expected: What the template or CONTRIBUTING says to provide (e.g. definition, parent, refs).
- Suitability: Good first issue? Agent-friendly? Needs more info?
For multiple issues (list/summary):
- Repo: owner/repo (or slug).
- Issues: Table or list with issue number, title, type, key labels, one-line summary; optionally mark "good first" or "NTR with template".
- Suggested next step: e.g. "Implement #N (NTR with clear template)" or "Clarify #M with maintainers."
Use hypothetical examples only; do not name specific ontologies from a fixed list.
Notes
- If CONTRIBUTING or issue templates were captured in analyze-project, reuse that to interpret what "required" means for NTRs or other types.
- This skill does not implement the issue; it only reviews and summarizes. Implementation is done in the project directory (e.g.
projects/<slug>/) using the ontology-editor tools (plus check_consistency/sparql_query for local checks), then create-pull-request for branch and PR.
1---2name: review-issue3description: Summarize and triage ontology repo issues for contribution. Use whenever the user wants to review an issue, find good first issues, summarize open issues for an ontology, or understand what an NTR or other issue needs—e.g. "review this issue", "is this a good first issue", "summarize open issues for this ontology", "what does this NTR need". Use for both single-issue review and listing/batching issues.4---56# Review Issue Skill78Use this skill when the user wants to **understand one or more issues** in an ontology repository—for example to pick work, assess difficulty, or see what a new term request (NTR) or other issue requires. You summarize issue type, required fields (vs any template), labels, and suitability for a first contribution or agent-driven change.910## When to Use1112- User asks to **review an issue** (by number or URL) or **"is this a good first issue"**.13- User wants to **summarize open issues** for a repo (e.g. list by type, filter by label).14- User asks **"what does this NTR need"** or what to provide for a synonym/obsoletion/term-merge issue.15- After **analyze-project** or **clone-project**: to choose which issue to implement before making edits.1617Use **web fetch** (GitHub issue/API pages) or, if the repo is cloned under `projects/<slug>/`, you can combine with reading CONTRIBUTING/issue templates from disk. Do not name specific real-world ontologies as examples; use hypotheticals (e.g. "an OBO ontology", "a repo with NTR templates").1819## Workflow20211. **Identify repo and issue(s)**: From the user's message, get the repo (owner/name or URL) and either a single issue number (or URL) or a request to list/filter issues (e.g. open, with label "good first issue" or "New term request").222. **Fetch issue data**: For each issue, obtain title, body, labels, and if possible the issue template used (from `.github/ISSUE_TEMPLATE/` or from the issue form). Use the GitHub web interface or API (e.g. fetch issue page, list issues).233. **Classify**: For each issue, determine:24 - **Type**: e.g. new term request (NTR), synonym, definition, obsoletion, term merge, missing parent/superclass, bug, documentation, refactoring, mapping.25 - **Labels**: workflow/type labels (NTR, bug, help wanted, good first issue) and any domain/project labels.26 - **Required fields**: From the issue template or CONTRIBUTING, what the maintainers expect (e.g. label, definition, parent, PMIDs, hierarchy position, replace_by/consider for obsoletion).27 - **Suitability**: Whether it looks like a good first contribution, or agent-friendly (well-scoped, template-driven), or needs more discussion/clarification.284. **Summarize**: Produce a short review (see Output format).2930## Output Format3132For **one issue**:3334- **Issue**: #N – title.35- **Type**: e.g. NTR, synonym, obsoletion, bug.36- **Labels**: list relevant labels.37- **Required / expected**: What the template or CONTRIBUTING says to provide (e.g. definition, parent, refs).38- **Suitability**: Good first issue? Agent-friendly? Needs more info?3940For **multiple issues** (list/summary):4142- **Repo**: owner/repo (or slug).43- **Issues**: Table or list with issue number, title, type, key labels, one-line summary; optionally mark "good first" or "NTR with template".44- **Suggested next step**: e.g. "Implement #N (NTR with clear template)" or "Clarify #M with maintainers."4546Use hypothetical examples only; do not name specific ontologies from a fixed list.4748## Notes4950- If CONTRIBUTING or issue templates were captured in **analyze-project**, reuse that to interpret what "required" means for NTRs or other types.51- This skill does not implement the issue; it only reviews and summarizes. Implementation is done in the project directory (e.g. `projects/<slug>/`) using the ontology-editor tools (plus `check_consistency`/`sparql_query` for local checks), then **create-pull-request** for branch and PR.
Minitour