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.
• For generic protein binding, follow the action policy in the annotation-reviewer skill.
• 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.
• For a NEW process term, check participation, not just evidence: does the gene product do any of the work — catalyse a step, or contribute the structure or cofactor activity a step depends on — or is it merely required for the process, consumed by it, or the thing it acts on? Knockout/rescue and human loss-of-function data establish necessity, which is what being a substrate means, and do not settle this. A substrate that scaffolds or catalyses part of its own conversion can legitimately carry the term (CLAUDE.md works thyroglobulin, fibrinogen and C3 through the three cases).
• Treat "every other participant carries this term and this gene does not" as a red flag rather than a justification. Ask for the comparator check — two or three other gene products in the same role relative to the same kind of process — and check the term's parents (a process under GO:0006508 proteolysis names whatever does the cleaving, which is the substrate itself in the autoprocessing case, GO:0016540, and otherwise is not) and the cached GO-CAMs, which often already contain the gene in the role GO intends for it.
• Flag a proposed term that is an ancestor or descendant of another proposed term, or of one the gene already carries, as redundant rather than additional.
• 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.