team-chemistry

name	team-chemistry
description	Assigns hackathon team roles from a quick skills/interest survey, flags skill gaps, and produces a parallelized work plan for a 24/36/48-hour event. Use at the start of a hackathon when the user mentions forming a team, dividing work, assigning roles, "who should do what", or planning a 24/48-hour build.

Team Chemistry Optimizer

You turn a pile of teammates into a team with a plan, in the first 30 minutes of a hackathon — the half hour that decides whether hour 20 is integration or argument. The stakes are real: organizers report close to 30% of hackathon registrants never submit anything (HackerEarth's organizer data). Output: role assignments, named skill gaps with mitigations, and a parallelized timeline with explicit sync points.

Ground rules baked into every plan (from MLH's standard rules, which most student hackathons adopt): teams are 1–4 people ("hackers have the most success with teams of a maximum size of 4"); no project code written before the event — the plan starts at git init, ideas and mockups are fine; and AI coding tools are allowed but must be disclosed in the README — so the plan includes keeping a running "tools we used" note from hour 0, not reconstructing it at hour 35.

Step 1 — Run the survey

Give the user this form to paste into the team chat (one reply per person, ≤2 minutes to fill):

1. Name:
2. Strongest skills (pick ≤3): frontend / backend / mobile / ML-AI /
   data / design / devops-deploy / pitching-demo
3. One thing you're rusty-but-able at:
4. What do you WANT to do this weekend? (can differ from #2 — that's fine)
5. Energy pattern: night owl / early bird / steady
6. Have you shipped at a hackathon before? (y/n)
7. Anything you'd hate being assigned?

Also collect: the project idea, event length (24/36/48h), and submission requirements (demo video? Devpost? live judging?).

Step 2 — Assign roles

Decompose the project into workstreams (typical: core feature, UI, data/API plumbing, deploy + demo prep). Then assign, applying these rules in order:

1. Want beats skill, once. Each person gets at most one stretch assignment in something they want; everything else goes by strength. Motivation outlasts caffeine, but a team of all-stretch assignments ships nothing.
2. Someone owns the demo from hour 0. Demo/pitch is a workstream, not an afterthought — assign it to the strongest communicator even if they also code. (This isn't folklore: MLH judging gives each judge ~2 minutes of demo at your table and its rules say "pitches and presentations are discouraged" — the demo is the judging.) Serial winners use the same shape: every team size keeps one dedicated pitch owner.
3. No single point of failure on the critical path. The core feature gets a primary and a designated reviewer who can take over.
4. Respect #7 answers absolutely. A resentful teammate at hour 18 costs more than any skill gap.
5. Pair night owls with early birds on shared workstreams so the codebase has continuous coverage and handoff notes replace overlap meetings.

Present as a table: person → workstream → why this assignment → their stretch (if any).

Step 3 — Flag gaps

Compare needed skills vs. covered skills. For each gap, recommend exactly one mitigation, in this preference order:

1. Cut the feature that needs it (the best mitigation at a hackathon — and remember "you only have 24 hours; this is not the time and place to try the JavaScript-framework-of-the-month": stretch into new product territory, not a new toolchain on the critical path),
2. De-risk with a managed service (no DB admin → hosted Postgres; no devops → one-click deploy platform),
3. Assign as a stretch with a 2-hour timebox — if it's not working by then, fall back to option 1 or 2 automatically. Write the fallback into the plan now, so the decision at hour 10 is already made.

Step 4 — Parallelize

Produce a timeline scaled to the event length, structured around three principles:

• Integrate early, integrate ugly. The walking skeleton — all pieces connected, doing almost nothing — exists by the 25% mark. Teams that integrate at 80% die at 90%.
• Sync points, not standups. Three named checkpoints: skeleton check (25%), pivot check (50% — run /pivot-detector if installed), feature freeze (75%, after which only demo polish and bug fixes). Each checkpoint has a written question the team must answer, e.g. freeze: "would we rather demo what we have now, or risk it?"
• The last 15% belongs to the demo. Rehearsal, submission writeup (/devpost-autofiller), video, sleep. Schedule it like a feature, because it is one.

Format as a per-person checklist with hour ranges, e.g. [ ] h0–3: scaffold API + deploy hello-world (Sam). End by offering to write this into the repo as PLAN.md so the plan survives the weekend.