# Hackathon inspiration pack

Teams are mixed: advanced and newer, technical and not. So this is one menu rather than an engineer list and a PM list, ordered from the gentlest terminal on-ramp to the most technical, and every idea says what *each half of the pair* does. Pick something the newer half can get a real win on *inside Claude Code*. ⭐ = pre-spec'd starter, the contract is already filled in, so grab it and start building.

### ⭐ 1. Unstructured → structured extraction (+ your first eval)
- **Who + before-state:** Russell has done this by hand, parsing fields out of unstructured text into CSV.
- **In a mixed pair:** the newer half drives the extraction prompts; the technical half writes the checker script with Claude, which is the room's first deterministic eval.
- **Terminal on-ramp:** drop one sanitised text file in a working folder, ask Claude to pull three named fields into a table. One file, one prompt, visible result.
- **Proof hook:** run the extraction on a held-back file live; show the checker script pass.
- **Reusable asset:** an extraction skill plus a small deterministic eval.
- **Contract:** [starters/starter-extraction.md](starters/starter-extraction.md)

### 2. Ticket → spec grill
- **Who + before-state:** Adam: tickets under-specified. Richard: deliberately vague. The gap between them is the spec.
- **In a mixed pair:** the product half gets grilled on a real ticket; the technical half judges whether the resulting contract is buildable.
- **Terminal on-ramp:** paste one real (sanitised) ticket, say "grill me until WHO/WHAT/WHY/NOT/DONE are explicit." With the Jira MCP: "grab ticket X and grill me."
- **Proof hook:** before and after of the same ticket, vague line against filled contract.
- **Reusable asset:** the grilled ticket becomes tomorrow's example; the grill prompt becomes a team skill.

### 3. Business-area briefing (sourced, not invented)
- **Who + before-state:** Adam's team already uses "teach me about this area of the business" via the Atlassian MCP and it works.
- **In a mixed pair:** the half that *doesn't* know the area asks; the half that does fact-checks the briefing against what they know. That's live evaluation.
- **Terminal on-ramp:** one question against approved Confluence spaces, every claim carrying its source link.
- **Proof hook:** click two source links live; both support the claim.
- **Reusable asset:** the briefing prompt plus a source checklist.
- **Watch the cost:** the Atlassian MCP loads ~20–40k tokens before you ask anything, so Lab 6's lesson applies. Load it when you need it.

### 4. Frontend prototype from a raw requirement
- **Who + before-state:** screens get described in tickets, and engineers translate.
- **In a mixed pair:** the product half writes the requirement paragraph and drives; the technical half reviews what the generated code actually does. Comprehension practice.
- **Terminal on-ramp:** working folder + the `frontend-design` skill + one paragraph of requirement → a clickable screen.
- **Proof hook:** open the prototype in a browser live; change one thing on request.
- **Reusable asset:** the requirement-paragraph-to-prototype workflow, written down.

### 5. Slide deck in Oodle's own house style
- **Who + before-state:** decks are hand-built each time, and Oodle keeps brand assets (colours, logo, template) somewhere already.
- **In a mixed pair:** one half curates the brand assets and outline; the other builds the skill that applies them. Both judge the output.
- **Terminal on-ramp:** point Claude at the brand assets folder plus an outline → a styled deck. Start with one slide, not the deck.
- **Proof hook:** one generated slide next to a hand-made one; the room guesses which is which.
- **Reusable asset:** an Oodle deck skill pointed at *their* saved design system.

### 6. Cross-language code comprehension
- **Who + before-state:** Adam's team faces the Java loan-booking engine, which isn't the DS team's forte.
- **In a mixed pair:** the technical half points at the right repo and spot-checks; the newer half asks the questions. Unfamiliarity is the asset here, and it's read-only, so nothing can break.
- **Terminal on-ramp:** "explain the booking flow, file by file," the deck's own demo prompt, on the real repo.
- **Proof hook:** a walkthrough doc another engineer confirms is accurate in one spot-check.
- **Reusable asset:** a comprehension-report format the team keeps using.

### ⭐ 7. Retrospective code-vs-business-logic audit
- **Who + before-state:** Richard's headline: nobody reviews the decision-engine code *retrospectively* against the business documents ("the elephant in the dark room").
- **In a mixed pair:** the technical half traces doc to code; the product half judges whether each finding reads sensibly and drafts the realignment tickets.
- **Terminal on-ramp:** read-only. First win: "list where rule X is implemented, with file:line references."
- **Proof hook:** show one real mismatch (or one confirmed alignment) traced from doc to code to line.
- **Reusable asset:** the audit prompt or skill, plus a findings-ticket template.
- **Contract:** [starters/starter-code-audit.md](starters/starter-code-audit.md)

### ⭐ 8. Polars migration with tests as the oracle
- **Who + before-state:** the decision engine runs on Pandas, and Adam converted one simpler repo "in an afternoon."
- **In a mixed pair:** the technical half owns the migration; the newer half owns the evidence: baseline test run, after test run, diff stat, migration log. Someone owns the proof.
- **Terminal on-ramp:** first win is *running the existing tests*. Green before you touch anything.
- **Proof hook:** same test suite green on Polars; show the diff stat.
- **Reusable asset:** a repeatable codemod recipe (skill) for the next repo.
- **Contract:** [starters/starter-polars.md](starters/starter-polars.md)

---

**Choosing:** pick the idea whose *proof hook you could demo in 90 seconds*. The list runs from gentlest terminal on-ramp to most technical, so if two ideas tie, take the lower one only if the newer half of your pair wants the stretch. The contract template for non-starred ideas is [templates/requirement.md](templates/requirement.md).