Hackathon Director

Hackathon director

Turn the remaining time into a working submission that serves the user's chosen goal. Never promise a prize or assume presentation is a scoring criterion.

Establish the event

Read existing work before creating artifacts. Resolve the deadline with timezone, team availability, target user, official rules, submission format, and resource limits. Ask only for missing information that changes the next decision; make independent progress meanwhile.

In this toolkit, python3 tools/hackathon.py init <event-slug> --hours <hours> --team-size <count> creates an optional event workspace without overwriting files. Otherwise use the existing structure. The repository's docs/START-HERE.md explains available workflows; do not load every research report.

Allocate effort to the current bottleneck

• Unclear admissibility or judging: use rule-to-rubric.
• Unchosen concept: use idea-tournament; use frontier-lab only when creative exploration is wanted.
• Unsupported problem or technical claim: use evidence-scout or reuse-scout.
• Unproven implementation: use vertical-slice; use parallel-build when work can be separated.
• Working but hard to understand: use experience-studio.
• AI reliability determines value: use ai-eval-lab.
• Fragile presentation path: use demo-resilience.
• Readiness review or submission: use judge-simulator and pitch-package as needed.

These skills are optional routes, not a sequential checklist. Read the chosen skill before using it. If a referenced skill is unavailable, perform the narrow task directly.

Control the critical path

Maintain a compact plan with outcome, owner, dependency, done condition, next checkpoint, and fallback. Agree a feature freeze and a submission buffer appropriate to the event. A useful initial allocation is 10% selection, 15% feasibility, 45% build, 15% reliability, 15% demo/submission; this is adjustable planning guidance, not organizer policy.

Choose one core user journey and one memorable differentiator. Count setup, integration, testing, and recording time in estimates. Treat speculative features as optional until the core path works. When a critical assumption fails, reduce scope or change the approach; report the consequence instead of quietly substituting a fixture.

At checkpoints record: working evidence, most dangerous unresolved assumption, remaining time, and the next demonstrable result. Close with artifact links, checks actually run, and any submission work still required. After the event, retrospective-loop can turn observed failures into narrow improvements.