Fetch and index a GitHub repository so it can be taught and interviewed. Call this FIRST whenever the user provides a repo URL or asks to prep a repo that has not been ingested yet. Builds a code map (sections in a suggested teaching order) and caches file contents locally. Returns the repo summary and the first few sections — NOT full code; use get_code_section to pull code. Safe to call again on the same repo: it refreshes the code while preserving the user's progress and weakness history.

List all sections of an ingested repo in the suggested teaching order, with covered status and weakness scores. Use this to decide what to teach next (first uncovered section) or what to re-attack in an interview (highest weakness_score). Returns metadata only, never code — keep context small and pull code per-section with get_code_section.

Fetch the actual code for one section, plus its file context (imports at the top of the file). Use during TEACH mode to walk the user through their code one section at a time, and during INTERVIEW mode to ground questions in the real code. After the user demonstrates understanding of a section in teach mode, call mark_covered — this tool does not mark automatically.

Mark a section as covered in teach mode. Call this ONLY after the user has explained the section back in their own words or answered a comprehension question about it correctly — not merely after showing them the code.

Get the most probe-worthy parts of the repo for a mock interview: external API calls, auth/secrets handling, raw SQL, concurrency, long uncommented functions, leftover TODOs — plus any sections the user previously performed poorly on (weakness_score > 0 comes first). Call this at the START of every interview session and build questions from the returned reasons. Use focus='weak_spots' on returning users to re-attack past struggles.

Record one interview question and how the user performed. Call this after EVERY question-answer exchange in a mock interview — this is what powers cross-session memory of weaknesses. performance: 'strong' (clear, correct, justified), 'okay' (mostly right, some gaps), 'weak' (couldn't explain or wrong). Include the specific gap in notes when performance is weak or okay, e.g. 'could not explain why JWT is verified server-side'.

Store the prep context: job description, and optionally company name and CV text, tied to a repo. Call this when the user pastes or describes any of them. Once set, use it throughout: in teach mode, point out where the code demonstrates JD-required skills; in interview mode, probe JD-required concepts the repo does NOT demonstrate (e.g. 'the JD requires Docker and your repo has no containerization — how would you containerize this app?'). The JD is returned by get_progress so returning sessions stay JD-aware.

Get the user's full learning state for a repo: coverage %, session history, top weaknesses with notes, and recent interview performance. Call this FIRST at the start of any returning session ('let's continue', 'test me again', 'where were we') so you can resume from weak spots instead of starting over. Also call it to generate the strengths/weaknesses summary after an interview.