/design-submission-check

name: design-submission-check
description: "Audit a design-award submission package against the current official rules for a specific award cycle. Check required materials and technical constraints, cross-material facts and claims, rights and disclosure risks, and final submission readiness. Use when a user asks for a pre-submission check, compliance review, missing-material audit, consistency check, or final go/no-go decision. Do not use this skill to choose an award, retrieve winners, judge the design itself, rewrite the whole entry, or give a legal clearance opinion."

Design Submission Check

Purpose

Determine whether a concrete design-award submission package is complete, internally consistent, and ready to submit under the current official rules for one exact award, track, category, and cycle.

Return one of three decisions:

• `Ready`: no Blocker or Important findings remain.
• `Conditionally ready`: no Blocker remains, but one or more Important findings require attention.
• `Not ready`: at least one Blocker remains.

Scope Boundary

• Convert current official submission rules into a project-specific checklist.
• Check required files, fields, declarations, and technical constraints.
• Compare names, facts, claims, credits, metrics, and versions across materials.
• Screen rights, permissions, confidentiality, personal-data, and disclosure risks.
• Perform a final package-level audit and prioritize fixes.
• Stop after the audit. Do not select the award, score design quality, redesign the project, or perform comprehensive copy-editing.

Use `$design-award-match` before this skill when the award, track, or category has not been selected. Route design-quality questions to `design-evaluation` and substantive redesign or rewriting to `design-optimization` when those skills are available.

Severity Model

Read [references/checking-framework.md](references/checking-framework.md). Classify every finding:

• `Blocker`: likely prevents submission, violates an explicit hard rule, invalidates eligibility, or leaves a mandatory item absent.
• `Important`: materially weakens clarity, credibility, consistency, or rights readiness but is not a confirmed hard-rule failure.
• `Optimization`: optional improvement that does not affect basic submission readiness.

Never hide an unresolved rule or unreadable file inside an overall percentage. The highest unresolved severity controls the final decision.

User Interaction Contract

Accept:

• the exact award, track, category, and submission cycle;
• official rule page, entry guide, or terms when supplied;
• the submission files or a manifest describing them;
• applicant, team, project, release, authorship, and rights facts relevant to the entry.

If the award, track/category, or cycle is missing, ask one concise question containing only the missing identifiers. If materials are incomplete, audit what is available and list everything that could not be checked; do not invent a pass.

Offer this template when the user asks how to use the skill:

Award / cycle: {exact award and year}
Track / category: {exact official names}
Official rules: {URL or attached guide, optional}
Applicant / team: {names, roles, organization, country or student status}
Submission materials: {attach files or provide paths}
Known third-party content: {images, fonts, music, data, trademarks, AI-generated content}
Requested mode: {full audit / technical check / consistency check / final check}

Audit Workflow

1. Lock the submission target

Record the exact award program, cycle, track, category, applicant type, submission stage, deadline, and official timezone. Do not combine requirements from different cycles, categories, or judging stages.

If the selected target appears inconsistent with the package, report it and refer category selection back to `$design-award-match`; do not silently change the target.

2. Verify and extract current rules

Read [references/rule-evidence-policy.md](references/rule-evidence-policy.md). At request time, verify current official sources and create a requirement ledger containing:

• mandatory and optional materials;
• form fields and declarations;
• accepted file types, counts, sizes, dimensions, aspect ratios, duration, word or character limits, and languages;
• filename, anonymity, branding, caption, and credit rules;
• applicant, authorship, release-window, prototype, and publication restrictions relevant to final submission;
• rights, consent, AI-use, confidentiality, and disclosure requirements;
• deadline with an absolute date and official timezone.

Attach an official URL and `checked on` date to each rule group. Search snippets and third-party summaries are discovery evidence only. When official sources conflict, the most specific current official terms control; report unresolved conflicts as Blockers.

3. Inventory the package

List every supplied file and form field. Assign each item to exactly one requirement ID and record its version, file type, size, technical metadata, language, and readable/openable status.

Use `scripts/check_submission_manifest.py` for deterministic checks when a local package or structured manifest is available. Prepare inputs using the schemas in [examples/rules.example.json](examples/rules.example.json) and [examples/manifest.example.json](examples/manifest.example.json).

python scripts/check_submission_manifest.py `
  --rules examples/rules.example.json `
  --manifest examples/manifest.example.json `
  --pretty

The script checks declared metadata and available filesystem facts. It does not replace opening documents, inspecting images, playing videos, or verifying portal behavior.

4. Check completeness and technical compliance

For each requirement, check:

• presence and required count;
• readable/openable state;
• extension and actual format when detectable;
• file size, dimensions, aspect ratio, resolution, duration, word or character count;