hackathon-judging

Designs hackathon judging rubrics, judge allocation arithmetic, tie-break ladders, and results announcement plans.

1|Updated Sep 6, 2026
One-click install
npx skills add https://github.com/samber/dev-event-organizer-skills --skill hackathon-judging-samber
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: hackathon-judging
Source: https://github.com/samber/dev-event-organizer-skills/tree/main/skills/hackathon-judging
Command: npx skills add https://github.com/samber/dev-event-organizer-skills --skill hackathon-judging-samber

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

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.

Frequently Asked Questions about hackathon-judging

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How many judges do I need for my hackathon?

Compute judges per team as k = floor((J × W) / (N × t)) from team count, window minutes, and per-team demo time. Full coverage requires N ≤ W / t and adding judges cannot extend that ceiling, since every judge must still traverse all teams.

How do I build a hackathon judging rubric with weighted criteria?

Weight the categories already named in the published brief using integer percentages summing to 100, keep criteria at four or fewer, and score each on a 1-5 integer scale. Write the weights and scale down before anyone scores.

Should hackathon scores be normalized across judges?

Normalize only when each judge scored a proper subset of the field, since a harsh judge's constant then lands on one slice and skews the rank. Under full coverage the constant hits every team equally, so normalization is pure overhead.

What is a fair tie-break rule for a hackathon?

Publish a deterministic ladder before submissions close: highest score on the highest-weighted criterion, then count of judges ranking the project first, then a named tie-break judge on the record. Avoid coin flips and re-scoring finished demos.

Can a sponsor judge its own hackathon challenge track?

Yes, when a signed agreement requires it: confine the sponsor judge to that track, pair them with a neutral judge, run a drop-test with and without their scores, and disclose the composition in the published rules before submissions close.

When should hackathon judging use a pre-screen round?

Use triage only when N exceeds (J × W) / t, meaning not even one judge per team fits the window. The pre-screen is a published pass/fail gate on submission requirements, and the finals slate must pass the feasibility check on the remaining window.