Code review
AuraScore 77/100

Open Research Repository Architecture Code Review Spec

Draft an architectural code review specification for academic data repository software and digital preservation portals.

Use this template when defining pull request review standards for university research repositories, digital libraries, and open-access data platforms.

Template

Role: Principal Scientific Infrastructure Architect and Academic Open Source Lead

Context

  • Research Consortium / University: {{consortium_name}}
  • Repository System Type: {{repository_type}}
  • Backend Application Stack: {{backend_stack}}
  • Metadata Schema Standard: {{metadata_standard}}
  • Object Storage Backend: {{storage_backend}}
  • Governance & Compliance Framework: {{compliance_framework}}

Task

Produce an institutional code review specification for pull requests targeting the {{repository_type}} codebase maintained by {{consortium_name}} to ensure long-term digital preservation, API safety, and metadata compliance.

Method

  1. Establish core architectural review gates for {{backend_stack}} pull requests, focusing on non-blocking I/O, database migration safety, and transaction atomicity.
  2. Detail validation rules for ingestion endpoints serializing data against {{metadata_standard}} formats.
  3. Formulate strict verification checklists for large binary asset uploads targeting {{storage_backend}}, ensuring checksum validation (e.g., SHA-256) and multipart upload resilience.
  4. Define access control, authentication, and authorization review standards aligned with {{compliance_framework}}.
  5. Specify interface backwards-compatibility checks for public OAI-PMH, REST, and GraphQL endpoints.
  6. Standardize logging, structured audit trail generation, and telemetry requirements for all dataset state changes.
  7. Detail continuous integration (CI) gate criteria, specifying test coverage thresholds and automated vulnerability scan pass conditions.

Constraints

  • The review specification MUST mandate automated checksum verification for all write operations against {{storage_backend}}.
  • Code reviews MUST NOT approve schema migrations that cause destructive locks or irreversible metadata truncation.
  • Keep all recommendations tailored to digital asset curation under {{compliance_framework}}.
  • Maintain focus on architectural robustness, API integrity, and data preservation.

Output format

Structure the final specification under these exact markdown headers:

  1. Architecture Review Principles (max 120 words)
  2. Ingestion & Storage Code Review Spec (5-7 bulleted criteria)
  3. Metadata Validation & API Compatibility Checklist (4-6 inspection points)
  4. Security, Compliance & Audit Trail Rules (4-6 inspection points)
  5. Pull Request Sign-off Gate Requirements (table: Area, Reviewer Role, Required Automated Checks, Blocking Threshold)

Self-review

  • Ensure all 6 variables ({{consortium_name}}, {{repository_type}}, {{backend_stack}}, {{metadata_standard}}, {{storage_backend}}, {{compliance_framework}}) are cleanly integrated.
  • Confirm that data preservation, metadata fidelity, and checksum validation are directly addressed.
  • Verify that the sign-off gate table and all named sections meet the output contract.
AuraScore breakdown
77/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering8/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-code-review
education-research
open-research
data-repository
code-review