Student FAQ answer sheet

---
name: lecture-faq-answer-sheet
description: "Turn recurring student questions into an answer sheet with Vivu: lecture, start and end time, checked excerpt and slide formula for each. Use when TAs keep answering the same questions."
---

Student FAQ answer sheet with lecture timestamps

This skill takes the questions students keep asking in a course's forum (five to eight of them, pasted as text), the course outline and the recorded lectures as files, and returns an answer sheet a teaching assistant can paste from: for each question, the lecture where the instructor explains it, the start and end time, a short excerpt of what the instructor says there (checked against the lecture's captions or a local transcript), the slide title or formula read from a full frame, a link to the lecture in the LMS at that time, and an empty column for the instructor to confirm. Claude picks the four to six lectures the questions point to from the outline, prices them against the user's Vivu plan, uploads them to a private Vivu project, runs one precise search per question, reads the transcript inside every returned window to tell a full explanation from a passing mention, reads the slide or board from a frame, and writes the sheet. Nothing reaches students until the instructor has confirmed a row.

The value is in what the recording shows and the outline does not. The outline says which week covers conditional probability, not the minute; many LMS recordings have no captions to search; and instructors say things like "send the k factorial to the denominator" while the formula itself is only on the slide or the board. The hard part is that neighbouring topics mention each other: while deriving Bayes' rule, an instructor says the denominator "is total probability of the event B", and a search for the total probability question can land there. So every window Vivu returns stays a candidate until the transcript inside it shows the instructor explaining that question, and the sheet reports how many windows were set aside.

When to use

Use when someone asks "build an FAQ sheet that points students to the right lecture minute", "where in the lectures does the instructor explain X? We get this question every week", "make timestamped answers for our forum's top questions", or "which lecture and minute answers each of these student questions?".

Not for these:

1. A one off question about one lecture ("where does she define variance in week 5?"): search Vivu directly and read the transcript around the hit.
2. Captions, transcripts or lecture notes as a deliverable. The sheet quotes one or two sentences per row so the instructor can confirm the match; it is not a transcript and the skill does not produce one.
3. Cutting or editing lecture clips. The sheet points to times in the existing recording.
4. Grading answers, evaluating the instructor or rating lecture quality.
5. Lectures the institution has no right to use, such as another university's course.

Working principles

1. Report measured numbers, not estimates. When a number is an estimate, say so.
2. Nothing is verified until it has been checked against the source. Every Vivu window is a candidate until the transcript inside it shows a full explanation of the question; the slide text comes from a full frame, never from Vivu's reason text, which paraphrases and can invent words.
3. Stop and tell the user when a required capability or tool is missing. Do not guess around it.
4. Ask the user before anything that is expensive to redo (the lecture list and its index minutes, before upload) and before writing the full sheet (one sample row first). The skill posts nothing to the forum or the LMS; the TA pastes answers after the instructor confirms them.
5. A missing row is not proof that a lecture does not explain a question. Say "not found in the indexed lectures", never "not covered in the course".

What you need before starting

Check each item at the start of the run and tell the user plainly what is missing before doing anything else.

This skill needs Claude Code on the user's computer (the terminal or the Code tab of Claude Desktop), because it reads local files and runs ffmpeg. Claude on the web and cloud sessions cannot reach the files. It downloads nothing from the internet, so no residential IP is needed. Nothing recurs, so no scheduler is involved; run it again each time the question list changes.

Inputs to collect

Ask for anything missing, most important first.

1. QUESTIONS: the recurring student questions, five to eight, as students wrote them. Required.
2. The course outline and LECTURES_DIR, the folder with the lecture files. Required.
3. The LMS link pattern for a lecture at a time (for example https://LMS_HOST/video/VIDEO_ID?t=SECONDS), or one working link per lecture. Required for the link column; without it the column says the lecture and time only.
4. TRANSCRIPTS: where the caption files are, or which local ASR tool to run. Default: caption files with the same name as the video in LECTURES_DIR.
5. WORK_NAME: a short name for the working folder and the Vivu project. Default: the course code.

Files and state

Keep everything in one working folder next to LECTURES_DIR:

faq-WORK_NAME/
  config.json               questions with their query, chosen lectures, Vivu project id, link pattern
  lectures.csv              file, listed_name, lecture_title, duration_s, video_id, transcript_file
  results/                  one JSON per question: search results without the result page link
  sheets/                   contact sheets for windows kept as full explanations
  frames/                   full frames the slide or board text was read from
  candidates.csv            every window Vivu returned, with the transcript verdict and the reason
  faq_answer_sheet.csv      one row per question with a checked explanation
  answer_replies.txt        one short forum reply per row, for the TA to paste after confirmation
  state.json                steps done, files uploaded, questions searched with job ids, windows checked

Run the commands in Steps 3, 6 and 7 from the folder that holds both LECTURES_DIR and faq-WORK_NAME/, so their relative paths resolve.

A rerun reads state.json first and skips finished steps: a file marked uploaded is not uploaded again, a question with a saved result is not searched again, and a window with a recorded verdict is not checked again. When new questions arrive later in the term, add them to config.json and run Steps 5 to 8 against the same project; upload only lectures the project does not have yet.

Step 1: Check the Vivu connector and the setup

Goal: confirm every requirement before spending anything.

1. Call vivu_get_account. If the tool does not exist, tell the user to add the Vivu connector in Claude (https://mcp.vivu.ai/mcp) and stop. If the account does not show can_create_projects: true, or a later write call fails with "has not granted vivu.write", ask the user to reconnect Vivu and allow write access, then stop until they have.
2. Run ffmpeg -version and ffprobe -version.
3. List LECTURES_DIR, run the ffprobe length command on one file, and open its caption file (or run the ASR tool's version command).

In our test run vivu_get_account returned can_create_projects: true and the lectures came with the platform's own caption files. Running a local speech to text tool on a lecture without captions was not exercised in our test run.

Done when vivu_get_account shows can_create_projects: true, ffmpeg and ffprobe print their versions, ffprobe prints a length for a lecture file, and a transcript source is confirmed for it.

Step 2: Turn questions into queries and pick the lectures

Goal: one search query per question and a short list of lectures worth indexing.

1. Rewrite each question as a description of the instructor explaining it, in the course's own words, plus what the explanation works through. Template: "the instructor explains TOPIC, working through WHY_OR_HOW". Example: "If two events are disjoint, aren't they independent?" becomes "the instructor explains why two disjoint events are not independent". Keep the student's wording in config.json next to it; the sheet shows the student's question, the search uses the instructor's framing, because the search matches what is said and shown in the lecture, not how students phrase their confusion.
2. Match each question to lectures from the outline titles. Keep the lecture where the topic is introduced; add the next one only when the outline says the topic continues. Four to six lectures usually cover eight questions. Titles are text, so this costs nothing; indexing the whole course would not fit a monthly plan.
3. Write lectures.csv with file, lecture_title and transcript_file. Add listed_name: the file name with spaces and punctuation replaced by underscores (hyphens and the dot before the extension stay), because that is how Vivu lists names.
4. Show the question to query table and the lecture list to the user.

In our test run the six questions were written by us from the course topics, not taken from a real forum, and the lectures were picked by title from the course's lecture list. Confirming the queries and the lecture list with a TA or instructor was not exercised in our test run.

Done when the user approves the queries and the lecture list, and both are saved in config.json and lectures.csv.

Step 3: Measure the lectures and price them

Goal: an indexed set the user's plan can pay for, approved before upload.

1. Run the ffprobe length command on every file in lectures.csv and write duration_s.
2. Call vivu_get_usage and show one table:

Plan facts: Free is $0 a month with 20 index minutes a month and 50 search credits a month; Premium is $30 a month with 180 index minutes and 500 search credits. A precise search uses 5 credits in total. Five 24 minute lectures are about 120 index minutes (estimate), which fits Premium in one month; Free covers about one such lecture a month (estimate).

3. If the lectures do not fit, offer levers in this order: index only the lectures the most frequent questions point to, split the question list across two months, and only then move to a larger plan. Never drop a lecture the user asked for without saying which one, and never trim or recompress a file to save minutes.

In our test run the four lecture sections measured 45.18 minutes. The account used in our test run returns no allowance figures, so the comparison with a real plan and the user's approval were not exercised in our test run.

Done when the user approves the lecture list and its index minutes, and config.json records both.

Step 4: Confirm rights, upload and index

Goal: every approved lecture indexed in a private Vivu project.

1. Confirm the Compliance items with the user before the first upload.
2. Call vivu_list_projects and reuse a project named "FAQ WORK_NAME" if one exists. Otherwise call vivu_create_project with that name and visibility "private". The default visibility is organization, which shows the project to everyone in the user's Vivu organization; lecture recordings can include students' voices or faces.
3. Call vivu_open_upload_page with the project ID immediately before uploading. The link expires in 180 seconds and works once, so never post or store it. Give it to the user to open in their own browser and select the files, or open it in a browser tool that can attach local files. Claude in Chrome accepts at most 10 MB per upload call and a lecture is usually far larger, so lectures normally go through the user's own browser or the Vivu web app. Never split or recompress a file to fit.
4. Poll vivu_list_videos until every file shows ready. Match each Vivu file name to lectures.csv by listed_name; when a name does not match, match by length (duration_ms against duration_s in milliseconds). Record each video_id in lectures.csv and state.json.

In our test run the four sections (45.18 minutes) were all ready 328 seconds after the upload started. Each duration_ms equaled the ffprobe length of its file and every name matched listed_name, so the length fallback was not exercised in our test run. The files went through the upload page with an automated browser, so opening the link in the user's own browser was not exercised in our test run.

Done when every file in lectures.csv shows ready and has a video_id.

Step 5: Search each question

Goal: a saved list of candidate windows for every question.

One precise search per question, because each question is its own row. Every search is precise: only precise returns a time window, and fast returns whole files with an empty reason, which the lecture list from the outline already gives. The chain behind each row: the precise search suggests windows, the transcript inside each window decides whether it is a full explanation or a passing mention (Step 6), and a frame inside a kept window gives the slide or board text (Step 7). The flip from what is said to what is shown is Step 7: the formula a student needs is usually on the slide, and the transcript only says "this term".

Run vivu_search_videos (project_id, query, mode "precise", maximum_results 10) for each question. Ten is enough to surface the passing mentions of the same topic in neighbouring material, which is what Step 6 has to reject; it is also the recall ceiling, so a question discussed in more than ten places needs a higher value. vivu_search_videos returns a job ID; call vivu_get_search_results until complete is true. Each status call can wait up to 45 seconds, so a pending search is not a stalled one. Save the results to results/QUESTION_KEY.json without the result page link, and show the result page link only in the live reply: it expires after four hours, so it never goes into the sheet, candidates.csv or a forum reply.

The queries from our test run, on a probability course, show the pattern. Adapt the topic and the "working through" part to your course.

In our test run the total_probability and bayes wordings above came after 1 rewording each on the same corpus. The first wordings were shorter ("the instructor explains Bayes' rule: reversing the conditioning to infer which scenario caused an observed effect") and each returned one window that was not the explanation (Step 6 has the details). Naming what the explanation works through, and for a topic that other explanations reuse, saying that a reuse does not count, removed both.

Done when every question has a saved result file and its job id is in state.json.

Step 6: Check every window against the transcript

Goal: each window labeled full explanation, passing mention, or other, before anything reaches the sheet.

This is the step that keeps wrong answers out. In our test run 2 of the 13 windows returned on the first wordings were false, and both came from the same lecture as the real explanation.

1. For each window, convert start_ms and end_ms to seconds and read the transcript lines whose times fall inside it. In a .vtt or .srt file the times are on the line above the text, so grep -n "^00:MM:" TRANSCRIPT finds the line numbers for minute MM; read from the window's start line to its end line.
2. Label the window:
   • full explanation: for most of the window the instructor is working through this question (a definition, a derivation, an example built for it, or a student's question about it and the answer);
   • passing mention: the topic is named or used in one or two sentences inside a different explanation ("the denominator is the total probability of B");
   • other: the window is about something else.
3. Only full explanations go on to Step 7. Write every window, with its label and a one line reason, into candidates.csv, and count the passing mentions and others as false positives for the question. Vivu's reason text is a paraphrase and can name a formula that is not on screen, so it never decides the label.
4. When a question has several full explanation windows, keep the one that starts earliest in the lecture where the topic is introduced, and list the others in candidates.csv.
5. A question with no full explanation window gets a row saying "not found in the indexed lectures" and goes back to the user, who can add a lecture or reword the query (one rerun costs 5 credits).

Worked example from our test run

The corpus was public lecture recordings: four sections of a university probability course, 45.18 minutes in all, an instructor with projected slides and a blackboard. We wrote six student questions and marked each question's full explanation in the official captions, plus the passing mentions we expected, before searching.

The first wordings returned 13 windows: 11 full explanations and 2 false. One false window was a passing mention we had listed in advance: inside the Bayes' rule derivation the instructor says the denominator "is total probability of the event B", and the total probability search returned that window with a reason describing it as an explanation. The other was returned for Bayes' rule at the start of a lecture section, where the transcript is the introduction of total probability. After 1 rewording each of those two questions on the same corpus, the final wordings returned 11 windows: 11 real, 0 false, and 0 missed questions. Material that uses the same words but answers a different question (the expected value of a function right after the definition, a callback to disjoint events inside the conditional independence example) was not returned. Per question, the median window was 48 to 64 seconds wide.

The transcript check is what caught both false windows; the reason text would have let them through. The rewordings were tuned on the same small corpus, so on a new course expect passing mentions again and keep this step.

Done when every window in results/ has a label and a reason in candidates.csv, and each question has either a kept window or a "not found" note.

Step 7: Read the slide or board from a full frame

Goal: for each kept window, the slide title or formula on screen, read from the picture.

1. Cut a contact sheet across the kept window, one frame every five seconds (slides and boards change slowly, and the camera often cuts between the room, the board and the projector):

ffmpeg -v error -y -ss START -to END -i "LECTURES_DIR/FILE" -vf "fps=1/5,scale=320:-1,tile=6x5" -frames:v 1 faq-WORK_NAME/sheets/QUESTION_KEY.png

START and END are the window in seconds; a window longer than 150 seconds needs a second sheet from START plus 150. Look at the sheet and pick the tile where the slide or board for this explanation is most readable (projector or board filling the frame, not the room shot). Tile k is at START plus 5 times k seconds, counting from 0 at the top left. 2. Extract that moment as a full frame and read it:

ffmpeg -v error -y -ss SECONDS -i "LECTURES_DIR/FILE" -frames:v 1 -q:v 3 faq-WORK_NAME/frames/QUESTION_KEY.png

3. Write the slide title or the formula as it appears. Handwritten board text and small projected annotations can be hard to read at lecture resolution: write only what is legible and mark the rest UNCERTAIN, never complete a formula from memory or from the reason text.

In our test run the chosen tile matched the extracted full frame for each of the six kept windows, and the slide or board text was legible in all six at the recordings' low resolution; in one the board formula ran past the edge of the frame and its end was marked UNCERTAIN. A separate search for the slide itself (the n choose k formula on screen) returned 4 windows in our test run: 3 real and 1 false, where the reason described a formula in chalk on a board that showed a tree diagram. That is why the slide text comes from the frame and never from the reason.

Done when every kept window has a frame in frames/ and a slide_or_board_text value (or UNCERTAIN).

Step 8: Write the answer sheet and the reply drafts

Goal: a sheet the TA can paste from, confirmed row by row by the instructor.

1. Show the user one sample row and the field mapping, and wait for a yes before writing the rest:

question,lecture,file,start,end,explanation_excerpt,slide_or_board_text,frame,video_link,transcript_checked,instructor_confirmed
"Why do we divide by k factorial in n choose k?",Lecture 4 Counting,L4_counting.mp4,07:32,08:20,"And now that we have this relation, we can send the k factorial to the denominator. And that tells us what that number, n choose k, is going to be.","board: n!/(n-k)! ordered lists; arrow labeled k!",frames/n_choose_k.png,https://LMS_HOST/video/VIDEO_ID?t=452,yes,

2. Write faq_answer_sheet.csv and answer_replies.txt. Each reply names the lecture, the start time and the link, and one sentence of what to look for on the slide; it does not paste the explanation, so students go back to the lecture.
3. Tell the user the counts: questions with a kept window, questions not found, windows set aside as passing mentions or other.
4. Remind the user that answers go to students only after the instructor fills instructor_confirmed. The skill does not post to the forum or the LMS.

A window often covers only part of a long explanation. In our test run the counting question's window was the last 48 seconds of the derivation, where the instructor states the result; the sheet points there, and the instructor can move the start earlier when confirming the row.

In our test run the sheet has six rows, one per question, each with transcript_checked yes. Our files were sections cut from public lectures, so the links point to the public video at the section's offset plus the window start. The user's approval of the sample row and the instructor's confirmation were not exercised in our test run, and nothing was posted.

Done when faq_answer_sheet.csv has one row per question (kept or "not found"), answer_replies.txt has a reply for each kept row, and the user has approved the sample row.

Compliance

1. Index only lectures the institution has the right to use for this purpose, under its agreements with the instructor and the recording platform's terms. Confirm this before Step 4.
2. Students can be heard or seen in lecture recordings. Follow the institution's recording notice or consent policy, and keep the project private. For K-12 courses where minors appear on camera, the skill needs guardian consent under the school's policy, or it is not used.
3. The videos stay in the user's Vivu project until the user deletes them. Delete a project or video only when the user asks, and confirm first.
4. The sheet quotes one or two sentences per row for the instructor's check. It is not a transcript or caption file, and the skill does not distribute recordings or clips.
5. Answers reach students only after the instructor confirms them. The skill does not evaluate or rate the instructor.
6. The skill identifies no one: no face or voice recognition, no naming of students heard in the recording.

Known failure modes