Build a recruiting debrief prep web app that helps a recruiter walk into final-round hiring debriefs fully prepared, using data already in our applicant tracking system. The goal: replace last-minute scorecard re-reading with an instant, evidence-backed brief, surface negotiation risks before we talk offer, and help run a sharper debrief meeting. Trigger it as a browser-facing web page on an HTTP route (space-authenticated), served as a single-page app. It should auto-scope to whoever is signed in — read the viewer's authenticated identity and show only their final-round candidates — so the whole team can use one link with no setup. All data access is read-only. At a high level, build these capabilities: Candidate list: pull active applications from the ATS, keep only the signed-in recruiter's candidates at the final interview stage(s), and show them in a searchable list. (Define "final stage" to match your pipeline's stage names.) Debrief brief: for a chosen candidate, gather their profile, interview scorecards, and recruiter/candidate communications, then use an LLM to produce a concise, skimmable brief — overall read, strengths/concerns, open questions, and negotiation risk flags (comp, competing offers, timing, level) — with each point traceable back to the source record. Ask chat: a chat grounded strictly in that candidate's data so the recruiter can ask follow-ups. Compare: select two or more candidates and get a ranked, evidence-based side-by-side with a recommendation. Debrief script: let the recruiter choose who's attending (pull people from your chat/directory tool and enrich with job titles from your HRIS), then generate a time-boxed facilitation script with talking points and questions tailored to each attendee's role. Live debrief assistant: an in-meeting chat where the recruiter types what the room is saying and gets a response that confirms, adds nuance, or pushes back based on the scorecard record. Keep the LLM calls fast enough to serve live HTTP requests (favor a low-latency model and trim inputs), and make every generated claim cite its source and avoid inventing data. Design each capability as its own API route the page calls; keep them independent. For the specific services, I used Greenhouse (Harvest API) as the ATS, Anthropic Claude as the LLM, Slack for the attendee roster, and BambooHR for job titles — but treat each as a swappable choice: use your own ATS, your preferred LLM, your team's chat tool for participants, and your HRIS for titles. Tools used: Greenhouse, Anthropic Claude API, Slack API, BambooHR