# Hackathon Director > Coordinate a hackathon from event brief through build, demo, and submission; use for whole-event planning or rescue, not ordinary isolated coding tasks. - Skill: `shreyp087/hackathon-director` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add shreyp087/hackathon-director` - Raw SKILL.md: https://api.skillmd.com/api/skills/shreyp087/hackathon-director/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Coding & Dev Tools - Author: Shreyp087 (https://skillmd.com/u/shreyp087) - Updated: 2026-09-22 - Page: https://skillmd.com/skills/shreyp087/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 --hours --team-size ` 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.