$npx -y skills add SeanJ1ang/design-judge-skills --skill design-award-matchMatch a design project to supported design-award programs, tracks, and entry categories; apply structural eligibility gates; verify current official rules; compare published criteria and cautiously described winner trends; and output fit, evidence confidence, and submission prior
| 1 | # Design Award Match |
| 2 | |
| 3 | ## Purpose |
| 4 | |
| 5 | Identify the most defensible award, program, track, and category for a design project. Treat fit scores as transparent decision aids, never as probabilities of winning. |
| 6 | |
| 7 | ## Scope |
| 8 | |
| 9 | - Extract decision-relevant project facts. |
| 10 | - Pre-filter the configured award allowlist with stable eligibility gates. |
| 11 | - Verify all dynamic requirements on current official pages. |
| 12 | - Compare project evidence with published criteria and observable winner trends. |
| 13 | - Score, rank, and explain strategic fit. |
| 14 | - Stop after recommendation; do not audit every submission file or redesign the project. |
| 15 | |
| 16 | Use `$design-award-search` for verified same-category winners. Route file format, size, naming, declarations, and upload completeness to `$design-submission-check`. |
| 17 | |
| 18 | ## Input Contract |
| 19 | |
| 20 | Accept a brief, images, PDF, portfolio page, or structured JSON. Extract or request only facts that can change the recommendation: |
| 21 | |
| 22 | - primary function, target user, and use context; |
| 23 | - innovation and supporting evidence; |
| 24 | - project state and completion, launch, or release date; |
| 25 | - applicant type, student status, country or region; |
| 26 | - candidate awards, intended cycle, budget, and geographic constraints. |
| 27 | |
| 28 | Use the canonical values in [references/category-crosswalk.json](references/category-crosswalk.json). If the primary function is unclear, ask one short question. If an eligibility fact is missing, continue with `Eligibility: Unknown`; never assume a pass. |
| 29 | |
| 30 | Offer this template when the user asks how to use the skill: |
| 31 | |
| 32 | ```text |
| 33 | Project: {name and one-sentence description} |
| 34 | Primary function: {job performed or problem solved} |
| 35 | Target user / context: {optional} |
| 36 | Innovation and evidence: {optional} |
| 37 | Development status / launch date: {optional} |
| 38 | Applicant: {student, individual, studio, company; country/region} |
| 39 | Candidate awards: {optional; omit to search the supported allowlist} |
| 40 | Submission cycle / constraints: {optional year, region, budget} |
| 41 | ``` |
| 42 | |
| 43 | ## Workflow |
| 44 | |
| 45 | ### 1. Build the project profile |
| 46 | |
| 47 | Read [../design-judge-shared/category-taxonomy.md](../design-judge-shared/category-taxonomy.md) and [references/category-crosswalk.json](references/category-crosswalk.json). Classify by primary function before appearance. Record one canonical category, no more than two adjacent categories, project state, applicant type, evidence, timing, and constraints. Label material inferences. |
| 48 | |
| 49 | For command-line pre-filtering, prepare JSON like [examples/project-profile.example.json](examples/project-profile.example.json). |
| 50 | |
| 51 | ### 2. Validate and load the supported award set |
| 52 | |
| 53 | Read [references/awards/index.json](references/awards/index.json) and [references/award-profile-guide.md](references/award-profile-guide.md). Analyze only the programs in the allowlist. Treat Red Dot Product and Red Dot Design Concept as separate programs. If a requested award is absent, return `Unsupported` rather than researching and silently adding it. |
| 54 | |
| 55 | When a shell is available, validate configuration before analysis: |
| 56 | |
| 57 | ```powershell |
| 58 | python scripts/validate_award_profiles.py --pretty |
| 59 | ``` |
| 60 | |
| 61 | Build a focused candidate set, normally three to five routes: |
| 62 | |
| 63 | ```powershell |
| 64 | python scripts/build_candidate_set.py examples/project-profile.example.json --limit 5 --pretty |
| 65 | ``` |
| 66 | |
| 67 | Use `--award` repeatedly to restrict candidates. Award ids and declared aliases are accepted. |
| 68 | |
| 69 | ### 3. Apply stable gates |
| 70 | |
| 71 | Use each selected profile's `routes`, `required_project_fields`, and `stable_constraints`. When needed, run: |
| 72 | |
| 73 | ```powershell |
| 74 | python scripts/filter_eligible_awards.py examples/project-profile.example.json --include-ineligible --pretty |
| 75 | ``` |
| 76 | |
| 77 | Assign: |
| 78 | |
| 79 | - `Eligible`: all stable and current official gates pass. |
| 80 | - `Ineligible`: a confirmed rule excludes the entry. |
| 81 | - `Unknown`: a project fact is missing or any live gate remains unchecked. |
| 82 | |
| 83 | Exclude `Ineligible` routes from ranking but state the exact reason. Keep `Unknown` routes conditional. |
| 84 | |
| 85 | ### 4. Verify dynamic rules live |
| 86 | |
| 87 | Read only the selected award profiles under `references/awards/`. For every `dynamic_gate` and relevant `dynamic_field`, verify current official pages at request time: |
| 88 | |
| 89 | - cycle status and absolute deadlines; |
| 90 | - applicant, geography, age, enrollment, and graduation rules; |
| 91 | - completion, publication, distribution, or launch windows; |
| 92 | - exact track |