anyVideo

View saved version →

---
name: compare-explainers
description: Guide a comparison of two YouTube explanations of the same topic using a shared viewing checklist and the user's reported takeaways. Use when the user asks to compare explainers, teaching approaches, examples, or understanding across videos. Keep metadata-based selection separate from content comparison. Do not use for automatic video summaries, unsupported claims about a video's viewpoint, or a simple single-video recommendation.
---

# Compare Explainers

## Inputs

Establish the topic, the user's starting level, and what they want the comparison
to resolve. Reuse supplied links or an existing selection. Default to two videos;
include a third only when requested or needed to address a specific remaining gap.

## Workflow

1. Define a common comparison question and a short checklist: the main idea,
   examples used, assumptions or prerequisites, and what remains unclear.
   Adapt these dimensions to the user's goal.
2. Discover missing candidates with `search-videos({ query, reason? })` and read
   `results`. Select videos covering the same question, preferably with different
   formats suggested by their titles or descriptions. Deduplicate IDs and explain
   the apparent differences without asserting that the actual content differs.
   If results are unsuitable, refine the query once or ask for another link.
3. Provide each selected title, channel, returned `watchUrl`, and metadata-based
   reason for inclusion. Call `display-video({ videoId, reason? })` for the first
   selection when viewing is wanted. Extract IDs from supplied YouTube URLs.
   Accept only `status: ready` with a video; handle `invalid_video_id`,
   `video_not_found`, or a tool error by explaining the issue and offering a
   returned alternative. Do not render every candidate as a browsing gallery.
4. Invite the user to share takeaways against the checklist after each video.
   Open the next selection individually when requested. Wait for the user's
   account instead of assuming playback, understanding, or specific claims.
5. Build a comparison matrix from the supplied takeaways or pasted excerpts.
   Attribute each observation to its source, mark missing dimensions unknown,
   and distinguish a shared idea from a difference in presentation or a reported
   disagreement. Ask for the relevant excerpt before interpreting an ambiguous
   disagreement.
6. Recommend which explanation appears more useful for this user's goal based
   on their reported experience. List any unresolved question and one focused
   next step; do not manufacture a winner when the evidence is incomplete.

## Deliverable

Return a two-video selection and shared viewing checklist, followed by a
comparison matrix and a goal-specific recommendation once the user provides
content. Keep selection evidence and user-reported content clearly attributed.

## Boundaries

- Do not require annotations, access private widget state, or claim to watch or
  transcribe either video. A title-only discussion handoff supplies no takeaways.
- Do not treat channel variety, popularity, or a title as proof of accuracy,
  opposing viewpoints, independent sources, or teaching quality.
- Leave reported factual disagreements unresolved unless supporting evidence
  is available. Distinguish comparing explanations from verifying their claims.
- Use only the registered tool arguments. Keep the matrix in chat; do not
  promise synchronized players, automatic seeking, or a saved comparison board.
- If the user explicitly requests text only or no video display, call neither
  tool and compare only the material already provided.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: creative-reference-watchlist
description: Build a YouTube reference watchlist from a creative brief, with a distinct reference purpose for each video and viewing questions that turn user-reported reactions into creative directions. Use for documentary, filmmaking, animation, presentation, or other creative-project inspiration. Select from metadata without claiming to inspect visual style. Do not use for automatic scene analysis, image generation, or a general entertainment recommendation.
---

# Creative Reference Watchlist

## Inputs

Establish the project, audience, intended effect, and decisions the user needs
references to inform. Use any stated constraints or existing reference links.
Ask one focused question if the brief lacks a clear project or creative purpose.
Default to three reference needs rather than a large inspiration catalog.

## Workflow

1. Break the brief into distinct reference needs, such as an opening structure,
   interview approach, or pacing. Give each need a decision it should help the
   user make; avoid several videos serving the same purpose without explanation.
2. Call `search-videos` with `{ query, reason? }` for needs without supplied
   references. Read `results` and shortlist candidates based on titles,
   descriptions, channels, and publication dates. Deduplicate IDs. Explain what
   the metadata suggests and what the user still needs to assess while watching.
   Refine an unsuitable search once; leave a need open if no plausible fit appears.
3. Return a compact watchlist containing the reference need, selected title,
   channel, returned `watchUrl`, selection rationale, and two targeted viewing
   questions. Phrase questions as prompts to inspect the work, not assertions
   that it contains a particular shot, palette, editing rhythm, or performance.
4. Call `display-video` with `{ videoId, reason? }` for the reference the user
   wants to view, or the first selection when they ask to begin. Extract an ID
   from a supplied YouTube URL. Accept only `status: ready` with a video; explain
   `invalid_video_id`, `video_not_found`, or a tool error and offer a returned
   alternative. Open further references individually when requested.
5. Invite the user to report what they liked, what they would avoid, and why.
   Wait for these reactions before describing the reference's actual execution.
   Keep metadata, user observations, and assistant suggestions distinguishable.
6. Translate the reported reactions into two or three creative directions for
   the user's project. For each direction, name the underlying principle,
   a possible original application, and the next decision or small experiment.
   Attribute the reference to the user's account and keep unviewed aspects open.

## Deliverable

Provide a purposeful reference watchlist and viewing questions. After the user
shares reactions, provide a short creative-direction brief tied to their project
and supported by those reactions.

## Boundaries

- Work through ordinary playback and chat. Do not require tags, observation
  logs, transcripts, private widget state, or automatic viewing detection.
- Do not infer visual or audio execution from thumbnails, titles, or popularity.
  Do not claim the model watched scenes or measured pacing.
- Keep the watchlist and brief in chat; do not promise a saved mood board,
  downloadable clips, a YouTube playlist, or editing and generation features.
- Use only the registered tool arguments. Express preferences through `query`
  without inventing style filters. If the user explicitly requests text only
  or no video display, call neither tool and organize their supplied references.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: rediscover-a-video
description: Find a vaguely remembered YouTube video by reconstructing clues, refining searches, comparing returned metadata, and asking the user to confirm a candidate. Use when the title, channel, or link is forgotten or uncertain. Keep possible matches tentative until confirmed. Do not use for generic recommendations, an exact-ID display request, watch-history access, or guaranteed identification from an unseen scene.
---

# Rediscover a Video

## Inputs

Collect clues already present in the conversation: subject, remembered title
words, creator, language, approximate period, and distinctive details. Separate
confident clues from uncertain memories. Ask at most one high-value question
before searching when a missing clue would meaningfully narrow the results.
Clarify whether a remembered date means upload date or when the user watched.

## Workflow

1. If an exact ID or usable YouTube URL is supplied, extract the ID and skip
   discovery. Otherwise, summarize the strongest clues briefly and form a query
   combining the topic with distinctive title words or a creator clue.
2. Call `search-videos` with `{ query, reason? }` and read `results`. Compare
   returned titles, descriptions, channels, and publication dates with the clues.
   Treat a remembered scene as a search hint, not as something confirmed by the
   metadata. Do not assume upload date equals the user's viewing date.
3. Present at most three plausible candidates with their titles, channels,
   returned `watchUrl` values, supported matches, and unresolved or conflicting
   clues. Mark the candidates tentative. Do not claim an exact match from
   search rank or similarity alone.
4. Ask which candidate looks familiar or request one discriminating clue. Use
   the reply to refine the next query: keep strong clues, relax an uncertain
   one, and avoid repeating the same failed search. Deduplicate IDs across rounds.
   Limit discovery to three rounds before offering the best remaining shortlist
   and the specific missing clue that would help continue.
5. Call `display-video` with `{ videoId, reason? }` for a candidate the user
   chooses, an unambiguous metadata match offered for verification, or a supplied
   exact ID when viewing is wanted. Do not display every tentative candidate.
   Accept only `status: ready` with a video. Explain `invalid_video_id`,
   `video_not_found`, or a tool error; offer another actual candidate or request
   a corrected link without declaring the search resolved.
6. Invite the user to verify by watching. Mark the video confirmed only after
   they explicitly recognize it. If rejected, record the useful exclusion in
   the conversation and continue within the search limit or with a new clue.

## Deliverable

Provide either a user-confirmed video with its title, channel, and watch link,
or a clearly tentative shortlist with matched clues, conflicts, and the most
useful next question. State honestly when no plausible match was found.

## Boundaries

- Do not access or claim access to YouTube accounts, viewing history, saved
  playlists, private widget state, or playback events.
- Do not rely on tagging, transcripts, or automatic scene recognition. Use the
  user's remembered details as clues without inventing corroborating content.
- Do not claim an absent result proves deletion or that all of YouTube has been
  searched. A limited search cannot establish either conclusion.
- Use only the registered tool arguments; channel and date words in `query`
  are search hints, not enforced filters. Keep clue tracking in the conversation.
- If the user explicitly requests text only or no video display, call neither
  tool; help reconstruct clues from their supplied material instead.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: video-discussion-club
description: Organize a group discussion around a YouTube video with an audience-aware selection, facilitator agenda, open questions, and a synthesis of participant responses shared in chat. Use for a video club, classroom discussion, team viewing session, or moderated group conversation. Do not use for automatic video summaries, participant messaging, meeting scheduling, or a solo tutorial exercise.
---

# Video Discussion Club

## Inputs

Establish the topic, audience, discussion purpose, and available discussion time.
Reuse a supplied video or previous selection. Ask one focused question if the
audience or purpose is unclear enough to change the selection or agenda.
Distinguish time for watching from time for discussion.

## Workflow

1. Turn the purpose into one central discussion question. If a video is needed,
   call `search-videos` with `{ query, reason? }`, read `results`, and shortlist
   two or three candidates using titles, descriptions, channels, and publication
   dates. Explain their apparent fit and recommend one. Refine an unsuitable
   search once; ask for a link if a suitable selection remains unavailable.
2. Call `display-video` with `{ videoId, reason? }` for the chosen video when
   viewing is wanted. Extract an ID from a supplied YouTube URL. Use only a
   `status: ready` result with a video as the loaded selection. Explain
   `invalid_video_id`, `video_not_found`, or a tool error and offer an alternative
   from actual results rather than presenting an unavailable video as playable.
3. Provide a facilitator agenda: a brief opening question, individual viewing,
   an initial round of reactions, focused discussion, and a closing takeaway.
   Allocate discussion time separately. Include video runtime only when returned
   in `video.contentDetails.duration`; leave unverified watch time unknown.
4. Prepare three to five open questions grounded in the topic and the stated
   purpose. Frame video-specific points as things for participants to identify,
   rather than scenes or claims the model has inspected. Include a prompt for
   participants to distinguish what they saw from how they interpreted it.
5. Invite the facilitator to share participant responses in chat. End the
   preparation response with the agenda; do not invent a discussion or assume
   participants have watched. During facilitation, ask one question at a time
   and adapt to the responses actually provided.
6. Synthesize the shared responses into areas of agreement, differing
   interpretations, open questions, and one closing takeaway. Preserve meaningful
   disagreement and attribute contributions only as the facilitator identifies
   them; do not infer attendance or individual opinions.

## Deliverable

Provide the selected video, a timed discussion agenda, and facilitator questions.
After responses arrive, provide a concise discussion recap grounded in those
responses, with unresolved points left open.

## Boundaries

- Use ordinary viewing and chat; do not require observations, transcripts,
  private widget state, or automatic playback tracking.
- Treat the discussion button as a title-only handoff. Request participant
  responses before producing a content-specific recap.
- Do not claim metadata verifies the full content, suitability for the audience,
  caption availability, or factual accuracy. Identify uncertain fit plainly.
- Keep coordination in chat. Do not send invitations, schedule meetings, control
  shared playback, or claim persistent attendance or discussion storage.
- Use only the registered tool arguments. If the user explicitly requests text
  only or no video display, call neither tool and prepare from supplied material.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: watch-and-apply
description: Turn one YouTube tutorial into a practical learning cycle with a viewing goal, a user-reported takeaway, a small exercise, and feedback on the user's attempt. Use when the user wants to practise or apply something learned from a video. Ground video-specific work in text or takeaways shared in chat. Do not use for an ordered curriculum, automatic video analysis, or observation-panel coaching.
---

# Watch and Apply

## Inputs

Establish the skill the user wants to practise and what a successful small result
would look like. Reuse the current video or a supplied link when available.
Account for the user's starting level, available materials, and time for practice.
Ask a focused question only if these details materially affect the exercise.

## Workflow

1. Define one achievable learning goal. If discovery is needed, call
   `search-videos` with `{ query, reason? }`, read its `results`, and choose a
   tutorial whose title and description plausibly support that goal. Explain
   the metadata basis without claiming the tutorial's method has been verified.
   Refine an unsuitable search once before asking for a link or narrower goal.
2. Call `display-video` with `{ videoId, reason? }` for the selected or supplied
   video. Extract the ID from a YouTube link when needed. Continue the viewing
   step only for `status: ready` with a video. For `invalid_video_id`,
   `video_not_found`, or a tool error, explain the issue and offer another returned
   candidate or work from material the user provides.
3. Give a short viewing brief: the goal and two things to pay attention to.
   Frame these as questions for the learner, not claims about scenes or steps
   that the model has seen. Invite the user to return with their main takeaway,
   one unclear point, or the method they want to try. End the response here.
4. Resume when the user supplies that input. Separate their account of the video
   from general subject knowledge. Ask for a missing step or pasted excerpt if
   reproducing the specific method would otherwise require guessing.
5. Design one small exercise using the reported method and the user's constraints.
   State the task, a concrete completion criterion, and what result the user can
   share for feedback. Label any exercise devised from general knowledge as an
   assistant-proposed exercise rather than something taken from the video.
6. Review the user's attempt against the stated criterion. Explain one useful
   correction and offer one retry or extension. Base feedback only on the work
   they share; do not claim to observe their practice or the video's demonstration.

## Deliverable

Provide a viewing brief, then a practical exercise, then focused feedback as the
user supplies the needed information. Preserve the learning goal across turns
without inventing takeaways, attempts, or completion.

## Boundaries

- Use ordinary playback and chat. Do not require tagging, observation logs,
  transcripts, private widget state, or a playback-completion signal.
- Do not watch, pause, seek, or advance the player on the user's behalf. A
  displayed video is not evidence that the user watched or understood it.
- Treat the discussion button as a title-only handoff; ask for the user's
  takeaway when it provides no account of the content.
- Use only the registered tool arguments; do not add exercise, duration, or
  playback parameters. Keep the exercise in chat, without promising saved progress.
- If the user explicitly requests text only or no video display, call neither
  tool and build the practice cycle from the information they supply.

Referenced files: 1 — file references are metadata, not package contents.

View saved version →

---
name: youtube-learning-path
description: Build an ordered YouTube learning path for a topic, starting level, and practical goal. Use when the user asks for a sequence of videos, a beginner progression, or a small video curriculum. Select and sequence videos using returned metadata, and adjust the path using the learner's feedback. Do not use for a single-video lookup, automatic video summaries, or timestamped coaching.
---

# YouTube Learning Path

## Inputs

Establish the topic, starting knowledge, and desired outcome from the conversation.
Use any stated language, preferred format, video count, or time budget. Ask one
focused question only when a missing goal or level would change the sequence.
Default to three stages when the user gives no preferred length.

## Workflow

1. Translate the goal into a short progression: foundations, a worked example,
   and independent application. Adapt these stages to the topic and learner.
2. Call `search-videos` with `{ query, reason? }` for stages needing discovery.
   Reuse supplied videos and known IDs instead of searching for them again.
   Read candidates from the returned `results`; compare titles, descriptions,
   channels, and publication dates against each stage's objective.
3. Select one candidate per stage, remove duplicate IDs, and explain its apparent
   fit using metadata. Describe the planned learning objective separately from
   any coverage explicitly supported by the description. Refine an empty or
   unsuitable search once; leave a stage unfilled if no defensible match appears.
4. Return the ordered path with each selected title, channel, returned `watchUrl`,
   stage objective, and reason for its position. Mark any inferred level or
   coverage as tentative. Add one short question to guide watching at each stage.
5. Call `display-video` with `{ videoId, reason? }` for the first selected video
   when the user wants to watch. Extract an ID from a supplied YouTube URL rather
   than passing the URL as `videoId`. Treat only `status: ready` with a video as
   loaded; explain `invalid_video_id`, `video_not_found`, or a tool error plainly
   and offer another returned candidate without claiming playback succeeded.
6. On the learner's next message, use their reported understanding or difficulty
   to revise the next stage. Open subsequent videos individually when requested;
   do not assume a video has finished or advance the sequence automatically.

## Deliverable

Provide a compact numbered learning path and the requested playable selection.
Keep revisions in the conversation, and explain how each revision serves the
learner's stated goal.

## Boundaries

- Work with ordinary playback and chat; do not require observations or tags.
- Do not claim to have watched videos, obtained transcripts, or verified that
  the videos teach every planned objective. Use user-supplied takeaways or text
  for content-specific follow-up.
- Read a verified duration only from a ready `display-video` result's
  `video.contentDetails.duration`. Mark other lengths unknown; do not promise
  that the full path fits a time budget using search metadata alone.
- Do not create a YouTube playlist, autoplay queue, persistent progress record,
  or reminder. The path is a list in chat, and displaying a video renders a widget.
- Use only the registered arguments; express search preferences in `query`
  without claiming they are enforced filters. If the user explicitly requests
  text only or no video display, call neither tool and organize supplied material.

Referenced files: 1 — file references are metadata, not package contents.