Aigr Pr Review

---
name: aigr-pr-review
description: >
  Review AI Gene Review pull requests and curation changes for GO term quality,
  evidence support, core function identification, and annotation action justification.
  Use for PR review comments, review follow-up automation, and QA of gene review YAML.
---

# AIGR PR Review Skill

Use this skill when reviewing AIGR pull requests or drafting review feedback about
gene review YAML, GO annotation decisions, evidence support, or UniProt-backed summaries.

Use the repository's existing guidance and agents where appropriate, especially
`CLAUDE.md` and `.claude/agents/annotation-reviewer.md`.

## Trust Validation

Do not re-check what `just validate` already covers.

If validation passes, do not spend review effort on:
- YAML formatting or whitespace
- Empty or null optional keys
- Required-vs-optional field presence
- Enum spelling, structural schema shape, or other deterministic validation concerns

The reviewer's job is the non-deterministic part: biological judgment, GO ontology judgment,
evidence quality, and whether the curation narrative is coherent.

## Focus Areas

1. GO term specificity and aspect correctness
- Prefer the most accurate GO term supported by the evidence, not the nearest generic match.
- Flag terms that are too broad, too narrow, or placed in the wrong GO aspect.
- Be especially skeptical of vague terms like `protein binding` when a more informative MF term is available.
- If recommending `MODIFY`, provide the concrete replacement term(s) with GO IDs.

2. Evidence quality
- Each annotation review should be supported by accessible evidence.
- Check that cited PMIDs, GO references, file references, and supporting text actually justify the claimed action.
- Do not accept unsupported `NEW` annotations.
- If the relevant publication or evidence cannot be accessed, prefer `UNDECIDED`.

3. Core function identification
- `core_functions` should capture the gene's main conserved molecular/cellular role.
- Do not treat every phenotype, developmental consequence, or systems-level effect as core.
- Use the combination of review YAML, UniProt annotations, deep research, notes, and cited publications to infer what is core vs peripheral.

4. Description quality
- The top-level `description` should be a standalone biological summary for a biologist.
- Flag project or workflow framing in `description`, including phrases such as `Proteostasis Network`, `PN`, `this review`, `curation`, `GOA correctly captures`, or `should be annotated`.
- Project-specific observations, disagreements with a project source list, and annotation-propagation cautions belong in `*-notes.md`, `review.reason`, `core_functions`, or `suggested_questions`, not in `description`.

5. Annotation action justification
- Every action should have a reason that matches the evidence.
- `ACCEPT` and `KEEP_AS_NON_CORE` need positive support, not just absence of contradiction.
- `REMOVE` and `MARK_AS_OVER_ANNOTATED` need a clear explanation of why the current term overshoots the evidence.
- `MODIFY` should explain both why the current term is off and why the replacement is better.

## Common Issues To Catch

- Over-generic GO terms that blur the real function.
- Wrong GO aspect classification: MF vs BP vs CC confusion.
- Missing deep research or notes support for a substantial curation conclusion.
- Existing annotations or proposed new terms with no usable evidence behind them.
- `core_functions` sections that mirror phenotypes rather than molecular/cellular function.
- `review.reason` or `review.summary` text that does not justify the chosen action.
- UniProt-backed claims that are overstated relative to the actual UniProt entry.
- Gene descriptions that read like curation notes rather than biology summaries.

## Things Not To Flag

- Formatting-only issues that `just validate` would catch.
- Empty YAML keys or omitted optional sections if the file validates.
- Requests to hand-edit derived context files such as `*-uniprot.txt`, `*-goa.tsv`, `*-deep-research*.md`, or `publications/PMID_*.md`.
  These should usually trigger a suggestion against review YAML/notes, a thread reply, or a tooling issue instead.

## Review Standard

Approve only when the PR is biologically and curatorially sound, not merely schema-valid.

Request changes when you find any blocking problem such as:
- major GO term specificity errors
- wrong aspect classification
- unsupported or mismatched evidence
- missing justification for a strong action decision
- core function summaries that materially misstate the gene's main role

Leave a comment rather than requesting changes when the issue is real but not clearly blocking,
or when the biology is ambiguous enough that a narrower question is more useful than a binary verdict.

Do not defer clear, fixable problems to a future PR. If a concrete curation problem is present now,
surface it now.