Design Submission Check

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. 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;