What problem does it solve? Hackathon organizers must decide who won under a fixed window between submission close and the ceremony, with limited judges, sponsor conflicts, and published rules that teams will hold them to. This Skill turns those constraints into a defensible judging design: the rubric, the allocation map, the combination rule, and the contest path. ## Core Features & Use Cases - Judge allocation arithmetic: Computes the full-coverage ceiling (N ≤ W / t), judges-per-team under a sampled panel, and the triage threshold, then prescribes the allocation band that actually fits the window. - Rubric and scoring mechanics: Weights the brief's published categories, picks the scale, builds capability ladders with negative rungs, and decides when per-judge normalization is required versus pure overhead. - Conflict of interest and results policy: Handles sponsor judges required by contract, recusal ladders, tie-break cascades, announcement plans, and a published contest path. - Use Case: With 48 teams, 9 judges, and 90 minutes before the ceremony, the Skill shows full coverage is impossible at 5 minutes per team, computes 3 judges per team, and produces a sampled-panel plan with normalization and a named allocation map. ## Quick Start Ask the Skill to design the judging plan for your hackathon given your team count, judging window in minutes, per-team demo time, and confirmed judge count.