Purpose
Scan a roster or enrollment dataset for the specific data-integrity failures that break program operations — missing enrollment links, email mismatches, invalid statuses, duplicates, and orphaned records — and return a row-level discrepancy report with severity, root-cause hypothesis, and a concrete fix for each flagged entry. Turns a messy export into a triaged cleanup queue.
When to Use
Invoke this skill when the user asks to:
- Audit an enrollment or roster export for data errors before an import or sync
- Investigate why learners aren't appearing, receiving access, or syncing to a downstream system
- Reconcile a roster against a source-of-truth system (CRM, SIS, LMS, billing)
- Find duplicate, orphaned, or status-mismatched enrollment records
- Clean up a spreadsheet or CSV of enrollments before onboarding a new cohort
- Validate roster data quality on a recurring basis (weekly/monthly hygiene check)
Inputs Required
Before starting, collect:
- Roster data: The dataset to analyze — pasted rows, CSV, or table (headers included)
- Expected schema: The columns that should exist and which are required (e.g., learner_id, email, enrollment_link, status)
- Valid status values: The allowed enrollment statuses (e.g., Active, Pending, Completed, Withdrawn)
- Unique identifier: Which field(s) should be unique per record (learner_id, email, or a composite)
- Source-of-truth reference (optional): A second dataset to reconcile against, if available
- Email domain rules (optional): Expected domains or format constraints (e.g., corporate domain, no free-mail)
- Volume expectation (optional): Approximate expected row count, to catch truncated or over-large exports
If valid status values or the unique identifier aren't provided, infer them from the data and state the assumption explicitly before flagging.
Instructions
Step 1: Schema & Structural Validation
Before checking values, confirm the shape of the data:
- Confirm all expected columns are present; flag any missing or unexpected columns
- Check header casing/naming inconsistencies that would break a mapped import
- Report total row count vs. expected volume — flag if truncated (suspiciously low) or bloated
- Detect fully blank rows and trailing empty rows from export artifacts
- If the schema is malformed enough to make row-level analysis unreliable, report that first and stop
Step 2: Missing & Broken Link Detection
Identify records that cannot function downstream:
- Missing required fields: Any row where a required column (enrollment_link, learner_id, email) is empty or whitespace-only
- Malformed links: Enrollment URLs that don't match expected pattern (missing protocol, truncated, placeholder text like "N/A" or "TBD")
- Orphaned records: Rows referencing a program/course/cohort ID that doesn't appear anywhere valid in the dataset
- Tag each with the specific field(s) at fault
Step 3: Email Validation & Mismatch Detection
Catch the most common access-breaking error:
- Format errors: Missing @, missing domain, double @, leading/trailing spaces, non-standard characters
- Domain rule violations: Emails outside allowed domains (if rules provided) or free-mail addresses where corporate is expected
- Internal mismatches: Same learner_id appearing with two different emails, or same email tied to two different learner_ids
- Cross-source mismatches: If a source-of-truth reference is provided, flag emails that differ between roster and reference for the same identifier (case-insensitive comparison, but flag case-only differences separately)
Step 4: Status Anomaly Analysis
Validate the enrollment lifecycle field:
- Invalid values: Any status not in the allowed set (or inferred set) — including casing/spacing variants like "active " vs "Active"
- Blank statuses: Required-but-empty status fields
- Logical contradictions: Status conflicts with other fields (e.g., "Completed" with no completion date, "Active" with a withdrawal date, "Withdrawn" but still linked to an active cohort)
- Stale states: "Pending" records older than a reasonable threshold if a date field is available
Step 5: Duplicate & Uniqueness Analysis
Find records that violate the unique key:
- Group rows by the unique identifier and flag any identifier appearing more than once
- Distinguish exact duplicates (all fields identical — safe to dedupe) from conflicting duplicates (same key, different values — require manual resolution)
- For conflicting duplicates, list the specific fields that differ so the operator knows what to reconcile
Step 6: Severity Rating & Triage
Assign each finding a severity so the operator knows what to fix first:
- Critical: Record cannot function — missing required field, malformed email, broken enrollment link, conflicting duplicate on the unique key
- High: Record functions but is wrong — status contradiction, cross-source email mismatch, invalid status value
- Medium: Record works but is risky — domain rule violation, stale pending status, case-only email difference
- Low: Cosmetic — trailing whitespace, casing inconsistency, exact duplicate
Step 7: Remediation & Summary
- For each flagged row, provide a specific fix action (not "review this" — say what to change it to when determinable)
- Produce a summary table: count of findings by category and by severity
- Surface the top 3 systemic issues (patterns affecting many rows) with a root-cause hypothesis (e.g., "12 email mismatches all trace to a bulk import that lowercased corporate domains")
Output Format
- Structure: Executive summary → discrepancy counts table → row-level findings table → systemic issues → remediation checklist
- Length: 700–1,100 words, scaling with dataset size and finding count
- Format: Structured document with a findings table (Row / Identifier / Category / Severity / Issue / Fix Action) plus prose for summary and systemic issues
- Sections: Summary → Counts by Category & Severity → Row-Level Findings Table → Top 3 Systemic Issues → Prioritized Remediation Checklist
- Tone: Data operations analyst — precise, unemotional, action-first; every flag names the exact field and the exact fix
Quality Checklist
Before delivering output, verify:
- [ ] Every flagged row cites the specific field(s) at fault — no vague "bad data" flags
- [ ] Every finding has a severity rating from the defined four-level scale
- [ ] The counts table totals reconcile with the number of rows in the findings table
- [ ] Duplicates are split into exact vs. conflicting — not lumped together
- [ ] Any inferred assumptions (status set, unique key) are stated explicitly before flagging begins
- [ ] Each remediation action specifies what to change, with the corrected value when determinable
Notes
- The single most common access-breaking issue is email mismatch — check Step 3 findings first even when other severities are present
- When a source-of-truth reference is provided, treat the reference as authoritative and describe mismatches as "roster differs from source," not the reverse
- Case-only and whitespace-only differences are low severity but high volume — grouping them into a single systemic finding keeps the report readable
- If the dataset exceeds what can be analyzed exhaustively, analyze in full where possible and clearly state the row range covered rather than silently sampling
How to use this skill
This file is a Claude Code skill in Anthropic's standard format — markdown with YAML frontmatter at the top.
Installing in Claude Code:
~/.claude/skills/<folder-name>/SKILL.md— auto-loads in every session anywhere on your machine (recommended for skills you'll use across multiple projects)<your-project>/.claude/skills/<folder-name>/SKILL.md— auto-loads only when working in that project (recommended for project-specific skills)
Restart Claude Code or open a new session to register.
Using in Claude.ai, ChatGPT, Gemini, or other AI tools:
- Drag this file into a new chat, or copy and paste its contents
- Send your task or request as your next message — the AI will apply the skill where it fits
For Claude Code skill details: https://docs.anthropic.com/en/docs/claude-code/skills