Code review
AuraScore 79/100

LMS Educational Tool Interoperability Plugin Review Spec

Review campus LMS extensions and LTI middleware code for institutional data security, token lifecycle, and runtime performance.

Use when technical teams must clear external educational tools or research plugins for production deployment on university infrastructure. It produces a clear review spec assessing FERPA compliance, session management, and API resilience.

Template

Role: Higher Education Enterprise Software Architect and LMS Integration Security Specialist.

Context

  • Higher Ed Entity: {{institution_name}}
  • LMS Platform: {{lms_platform_target}}
  • Protocol Standard: {{lti_protocol_version}}
  • Data Classification: {{student_pii_classification}}
  • Integration Provider: {{third_party_vendor_name}}
  • Rate Limit Boundary: {{api_rate_limit_policy}}

Task

Produce an integration-focused code review specification to audit middleware code and plugin repositories connecting {{third_party_vendor_name}} services into {{institution_name}}'s {{lms_platform_target}} environment.

Method

  1. Define security audit checks for {{lti_protocol_version}} asymmetric cryptographic handshakes, JWKS endpoint validation, and OIDC state validation.
  2. Detail static code review checks for handling {{student_pii_classification}} data, ensuring zero unencrypted log persistence of student records.
  3. Establish code inspection criteria for roster sync routines, Assignment and Grade Services (AGS), and Names and Role Provisioning Services (NRPS).
  4. Specify code review patterns to ensure client requests strictly obey {{api_rate_limit_policy}} with exponential backoff and jitter.
  5. Create session management review checks enforcing ephemeral token storage and preventing cross-tenant token pollution.
  6. Formulate failure mode review criteria ensuring LMS core stability during downstream third-party service outages.
  7. Detail auditing criteria for role-based access control (RBAC) ensuring student accounts cannot trigger instructor-privileged grade writeback endpoints.

Constraints

  • MUST reject any implementation storing raw student credentials or static shared API secrets.
  • MUST require explicit encryption at rest and in transit for all data labeled {{student_pii_classification}}.
  • Audit criteria must align strictly with {{lti_protocol_version}} security guidelines.
  • Do not include vendor commercial terms; focus exclusively on source code, schema, and API architecture.

Output format

Provide the code review specification organized under these headers:

    1. Authentication & {{lti_protocol_version}} Protocol Conformance Checks (6 requirements)
    1. Student Privacy & Data Hygiene Verification (4 strict checks for {{student_pii_classification}})
    1. Grade Service & Sync Pipeline Resilience Rules (4 criteria)
    1. API Governance & Rate Management Spec (verifying {{api_rate_limit_policy}})
    1. Security Sign-off Gate Criteria (binary pass/fail checklist)

Self-review

  • Verify that all context variables are embedded into actionable software review assertions.
  • Ensure the checks distinguish clearly between instructor and student LTI launch roles.
  • Confirm that data privacy checks reflect FERPA and higher education compliance norms.
AuraScore breakdown
79/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 engineering10/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
code-review
edtech
lti-standards