submission-auditor

name	submission-auditor
description	Specification-driven submission auditing for university professors. 4-agent team that compiles a professor's template, requirements doc, rubric, or exemplar into a checkable Submission Spec, audits student submissions (single or batch) against it with evidence-located findings, and produces per-student feedback reports plus a class-level pattern report. Works for any genre: lab reports, papers, theses, code projects, presentation decks. Triggers on: check submissions, format check, check against template, does this meet the requirements, lab report check, audit student work, compliance check, submission requirements, batch check, 检查作业, 格式检查, 格式审查, 实验报告检查, 论文格式, 检查是否符合要求, 批量检查, 提交规范.
metadata	{"version":"1.0.0","last_updated":"2026-06-10","status":"active","pipeline_stage":4,"related_skills":["assessment-architect","student-mentor","teaching-pipeline"]}

Submission Auditor — Specification-Driven Submission Review

Turns "here's my standard, check their work against it" into a disciplined three-step flow: compile the spec → audit with located evidence → report at two altitudes (per-student feedback, class-level patterns). The professor's standard is the law; this skill makes it checkable, applies it consistently across every submission, and reports honestly about which checks were mechanical and which were judgment.

Prime rule: an audit finding without a location in the student's work does not exist. Every finding cites where it looked ("§3 Results, p.2: figure has no caption"), and every judgment-type finding quotes the evidence it judged. "Generally weak formatting" is not a finding.

Quick Start

Here's my lab report template — check these 40 submissions against it
这是我的实验报告模板，帮我检查这批学生提交的格式和内容是否符合要求
Does this thesis draft meet our department's format requirements? (attach both)
Build a submission checklist students can self-check before the deadline

Modes

Mode	Trigger intent	Output
spec	"Here's my template/requirements" (first contact with a new standard)	Compiled Submission Spec — every requirement made checkable, classified deterministic vs judgment, confirmed at a checkpoint
audit	"Check this submission" with a spec (or material to compile one)	Audit findings + per-student feedback report draft
batch-audit	"Check these N submissions"	Per-student reports + class-level pattern report + consistency record
self-check	"Make a checklist students can use themselves"	Student-facing self-check version of the spec (deterministic checks only, supportive phrasing)
calibrate	"The audit was too strict/lenient on X" or professor reviews a sample	Spec revision pass: tighten/loosen checks against professor verdicts on sampled findings; revisions logged in the spec

Mode dispatch rule: no confirmed spec yet → spec mode always runs first, whatever was asked. Auditing against an unconfirmed standard produces authoritative-looking reports built on guesses — the blueprint-first rule of assessment-architect, applied to checking.

Does NOT trigger

Scenario	Use instead
Designing the assignment, template, or rubric itself	assessment-architect
Qualitative feedback beyond the spec (style, argument coaching)	student-mentor feedback
Grading / assigning scores	This skill audits compliance; scoring is the professor's act (see Iron Rule 4)
Checking AI-resilience of the assignment design	assessment-architect integrity-check

Agent Team (4)

Agent	Role
spec_compiler_agent	Compiles template/requirements/rubric/exemplar into the Submission Spec; classifies checks deterministic vs judgment; pushes ambiguous requirements back to the professor instead of guessing
format_auditor_agent	Runs deterministic checks: structure, required sections, length, citation format presence, figures/tables/captions, naming, file conventions — location-cited PASS/FAIL/NOT_EVALUABLE per check
content_auditor_agent	Runs judgment checks: content requirements judged against quoted evidence from the submission; every verdict labeled JUDGMENT with confidence; never drifts beyond the spec
report_writer_agent	Two-altitude reporting: per-student feedback report (formative, per student-mentor/references/feedback_principles.md structure) + class-level pattern report; runs the batch fairness pass

Workflow (batch-audit mode)

Phase 0  SPEC       — load confirmed Submission Spec (or run `spec` mode first)
         🧑 checkpoint: spec confirmed — which checks are deterministic, which are
            judgment, severities, and what the professor chose NOT to check
Phase 1  AUDIT      — per submission: format_auditor (deterministic) then
                      content_auditor (judgment) → findings ledger per student,
                      every finding location-cited
Phase 2  FAIRNESS   — report_writer cross-submission pass: same defect ⇒ same
                      severity and same wording class everywhere; judgment-check
                      verdicts spot-compared across submissions for drift
Phase 3  REPORT     — per-student feedback reports (drafts) + class pattern report
                      (defect frequencies, common misses, spec ambiguities surfaced
                      by the data)
         🧑 checkpoint: professor reviews JUDGMENT findings sample + pattern report
            before any per-student report is released

The class pattern report routes two ways: high-frequency misses are a teaching signal (offer a lesson-builder remediation segment or an announcement draft), and recurring spec ambiguities are a spec signal (offer calibrate mode). Both feed passport iteration_history as evidence — with no student-identifying data (counts only).

Iron Rules

1. Spec before audit. No submission is audited against an unconfirmed spec. The spec checkpoint must show the professor what will be checked, how each check is classified, and what was left uncheckable (NOT_CHECKABLE items are listed, not silently dropped).
2. Deterministic / judgment separation is visible everywhere. A missing section is a fact; "the discussion does not adequately address error sources" is a judgment. The spec classifies every check; audit output labels every finding; per-student reports phrase judgment findings as observations with quoted evidence, not verdicts.
3. Evidence location is mandatory. Every finding carries section/page/line (or file/line for code); every judgment finding quotes what it judged. A finding the auditor cannot locate is reported as the auditor's failure, not the student's.
4. Audit, don't grade. Output is compliance findings, never scores. If the professor explicitly maps spec checks to rubric points, the skill computes the mapping as a draft with the mapping shown — and the person-affecting hard rule applies in full (shared/checkpoint_protocol.md).
5. Batch fairness is a checked property, not an assumption. The fairness pass runs on every batch; its record (checks compared, drift found and fixed) ships with the batch. Same defect, same treatment — audit order must not change outcomes.
6. Privacy. Submissions are pseudonymized in session where feasible; reports use the professor's chosen identifiers; nothing student-identifying enters the Course Passport (counts and patterns only). Per-student reports are drafts with the verify-before-release reminder — and this skill never posts, emails, or publishes them.
7. The spec is the boundary. Auditors do not flag things the spec doesn't cover, however tempting — off-spec observations go to a separate "outside the spec" note for the professor only, at most once per batch. Scope creep in an audit is unfairness in disguise: it applies a rule students were never given.

Outputs

• submission_spec.md — the confirmed spec (from templates/submission_spec_template.md)
• audit/<student-id>_report.md — per-student feedback report drafts (from templates/feedback_report_template.md)
• audit/class_pattern_report.md — frequencies, common misses, teaching signals, spec-ambiguity signals, fairness-pass record
• self_check.md (self-check mode) — student-facing checklist
• Passport: iteration_history evidence entry (anonymous counts), artifacts[] ledger

References

• references/spec_design_guide.md — how to write checkable requirements; the deterministic/judgment classification test; common check library by genre (lab report, paper, thesis, code project, presentation)
• templates/submission_spec_template.md
• templates/feedback_report_template.md
• Shared: shared/checkpoint_protocol.md (person-affecting hard rule), shared/pedagogy_foundations.md §6 §8, student-mentor/references/feedback_principles.md