DeveloperOct 13, 2026
Gemini 4: Video-Tutorials in Skills für produktives RL-Engineering verwandeln
Eigent
Von RL-Video-Tutorials zu Skills für produktives RL-Engineering
Die Teams hinter Terminal-Bench und Harbor haben viel hart erarbeitetes Wissen über RL-Engineering geteilt – wie sie Aufgaben paketieren, wie sie schummelnde Agenten erwischen, wie sie Rollouts in Trainingsdaten verwandeln. Das meiste davon steckt in langen Konferenzvorträgen.
Drei dieser Vorträge ergeben zusammen etwa anderthalb Stunden Video. Jede Minute lohnt sich – aber wiederverwenden lässt sich das schwer. Beim nächsten Umgebungsaufbau scrollst du wieder durch Zeitleisten, auf der Suche nach der einen Folie, an die du dich erinnerst.
Also haben wir das Anschauen einem Team von Agenten übergeben. Mit Gemini 4 in Eigent hat ein einziges Briefing drei Terminal-Bench-Vorträge in vier dateibasierte Skills für produktives RL-Umgebungs-Engineering verwandelt – plus einen Bericht mit Quellenlinks, der zeigt, woher jede Idee stammt.
Der komplette Workflow auf einen Blick
Du wählst die Vorträge aus. Ab da bringt dich ein Briefing bis zu Skills, die deine Agenten wiederverwenden können. Jede Phase hinterlässt eine Datei, sodass du die Arbeit Schritt für Schritt prüfen kannst.
| Phase | Was passiert | Was du bekommst |
|---|---|---|
| Auswählen | Die YouTube-Vorträge wählen, aus denen du lernen willst | Eine kurze Liste von Videolinks im Briefing |
| Ansehen | Untertitel und Frames herunterladen und jeden Vortrag vollständig ansehen | Eine Gliederung mit Zeitstempeln für jeden Vortrag |
| Analysieren | Methoden, Erkenntnisse, berichtete Ergebnisse und Warnungen herausarbeiten | Lernpunkte, gekennzeichnet als OBSERVED, INFERRED oder UPDATED |
| Vergleichen | Die Vorträge einander gegenüberstellen | Wo sie übereinstimmen, wo sie sich unterscheiden und wie jeder die Lücken der anderen füllt |
| Destillieren | Methoden und Erkenntnisse nach praktischer Fähigkeit gruppieren | Eine SKILL.md und eine evidence.md pro Skill |
| Validieren | Struktur prüfen, Skripte ausführen, einen Skill an einer neuen Aufgabe testen | Jeder Skill als STRUCTURALLY CHECKED, EXECUTED oder UNTESTED markiert |
| Berichten | Einen HTML-Bericht erstellen und unter 127.0.0.1 ausliefern | Eingebettete Vorträge, anklickbare Zeitstempel und eine Abdeckungsmatrix mit Lücken |
| Wiederverwenden | Einen Coworker auf eine SKILL.md verweisen | Produktives RL-Umgebungs-Engineering im eigenen Projekt |
So setzt du es selbst um, Schritt für Schritt – inklusive einer Lektion, die wir beim Schreiben des Briefings gelernt haben.
Was du am Ende hast
- Wiederverwendbare Skills – jeweils eine
SKILL.mdmit einerevidence.md, so geschrieben, dass ein anderer Agent sie anwenden kann, ohne die Vorträge anzusehen. - Ein HTML-Bericht mit Quellenlinks – lokal ausgeliefert, mit jedem Vortrag eingebettet, einer Gliederung mit Zeitstempeln und Lernpunkten, über die du per Klick direkt an die passende Stelle springst.
- Eine Abdeckungsmatrix – welcher Skill welchen Teil des RL-Workflows abdeckt und welche Bereiche keiner der Vorträge behandelt.
- Eine ehrliche Nachweiskette – jede Aussage als OBSERVED, INFERRED oder UPDATED gekennzeichnet und jeder Skill als ausgeführt, strukturell geprüft oder ungetestet markiert.
Bevor du loslegst
- Eigent ist auf deinem Rechner installiert.
- Ein Gemini-API-Key.
- Die YouTube-Links, aus denen deine Agenten lernen sollen. Wir haben diese drei verwendet:
| Vortrag | Kanal | Länge |
|---|---|---|
| Introducing Terminal-Bench: Evaluating LLM Agents in Realistic Terminal Settings | Anyscale (Ray Summit 2025) | 31:23 |
| Everything Is a Rollout - Alex Shaw + Ryan Marten | AI Engineer | 21:11 |
| Terminal-Bench 2.0: Launch + Q&A with the founders | Latent Space | 35:00 |
Gemini-API-Key hinzufügen
- Öffne Settings → Models.
- Suche Gemini und öffne die Einstellungen.
- Füge deinen API key ein.
- Setze den model type auf
gemini-4. - Klicke auf Save.
Gemini 4 auswählen
- Öffne auf dem Startbildschirm die Modellauswahl unter dem Eingabefeld.
- Wähle Gemini → gemini-4.
- Stelle bei Bedarf die Denkintensität ein – der Standardwert funktioniert.
Briefing einfügen
Kopiere das Briefing unten in das Eingabefeld Cowork with. Ersetze die Links durch deine eigenen Videos und setze die Docker-Zeile auf allowed oder not allowed.
Watch the YouTube videos listed below and turn their methods and insights into reusable,
file-based agent skills. Then publish the results as a well-designed HTML report served from a
local web server.
Videos:
- https://www.youtube.com/watch?v=zt-U4lDdenY&t=1559s
- https://www.youtube.com/watch?v=jRCpXUjz4CI
- https://www.youtube.com/watch?v=5wo0mLlG0fk&t=1815s
Use only these videos as primary sources. Do not search for, substitute, or add other videos.
You may consult official documentation and the code repositories the videos link to or name,
but only to check or update details shown in the videos.
## Focus
Extract practical, repeatable methods. Where the videos cover them, include:
- Defining tasks, observations, actions, and termination conditions.
- Creating reproducible environments and reset behaviour.
- Building verifiers and reward functions.
- Detecting reward hacking and invalid successes.
- Collecting, scoring, and reviewing agent trajectories.
- Preparing data for agent training and evaluation.
Do not invent coverage for areas the videos don't address. List those areas as gaps instead.
Capture insights, not only procedures. For every method, record why the speakers use it, what
went wrong before they did, any results or numbers they reported, and the warnings they gave.
Treat named tools and frameworks (for example Harbor or Terminal-Bench) as one implementation
of a method. Record the underlying principle first and the tool-specific steps second.
## Permissions and limits
- Allowed: reading the video pages; downloading subtitles, transcripts, and the video files
for analysis; extracting frames; reading official docs and repositories named in the
videos; creating a local virtual environment and installing open-source packages into it;
running a local static web server bound to 127.0.0.1.
- Docker: [allowed / not allowed].
- Not allowed: model training, GPU jobs, paid hosted services, calls to paid LLM APIs, or
publishing anything to a public host. For trajectory collection tests, use a scripted,
rule-based, or random policy.
- Keep all files inside ./rl-env-skills/ in the current working directory. Delete downloaded
video files when finished.
- Do not ask for confirmation for the actions allowed above. Stop and report only if a required
action falls outside them.
- If a video is private, removed, region-locked, or has no usable audio or transcript, say so in
the report. Continue with the remaining videos, and do not replace it.
## Capability honesty
Before starting, record which relevant capabilities you have: video viewing, frame
extraction, transcript access, code execution, browser preview. If you cannot inspect video
visuals, work from transcripts and mark every visual claim as "not observed".
Never describe on-screen content you did not actually see.
## Analysis
For each video:
- Record title, channel, published date, duration, and view count with the date checked.
- Watch it in full. Inspect visual demonstrations, code, diagrams, and narration where your
capabilities allow.
- Build a timestamped outline of the main sections.
- Preserve timestamps for every important procedure, decision, and warning.
- List the key insights and takeaways: design decisions and the reasons behind them, lessons
learned, failure stories, reported results, and warnings. Give each one a timestamp.
- Label each claim OBSERVED (seen or heard in the video), INFERRED (your interpretation), or
UPDATED (adapted to current official docs; cite the doc URL and the date checked).
- Re-inspect unclear moments. Record unresolved details instead of guessing.
- Paraphrase. Quotes must be under 15 words and carry a timestamp. Do not reproduce transcripts.
Then note where the videos agree, where they differ, and where one fills a gap in another.
## Skills
Create 2–4 skills grouped by practical capability. A skill may draw from several videos.
Layout:
rl-env-skills/
<skill-name>/
SKILL.md # required
evidence.md # timestamps, OBSERVED/INFERRED/UPDATED labels, source per point
scripts/ templates/ # only if they materially help; scripts must be tested
report/
index.html # the HTML report (see below)
assets/ # extracted frames or screenshots used in the report, if any
REPORT.md
manifest.json
SKILL.md must begin with YAML frontmatter:
---
name: <kebab-case, matches folder name>
description: <1–2 sentences: what it does and when to use it, including trigger phrases>
---
The body must cover: prerequisites, required inputs, key insights (the principles and lessons
behind the procedure, each with its source and timestamp), procedure (numbered steps), expected
outputs, decision rules, failure recovery, observable success checks, and a tool-agnostic path
for projects that don't use the tools shown in the videos. Another agent should be able to
apply it to a new project without watching the videos.
A skill must not be only a wrapper around one tool's features. If you removed every
tool-specific command, the insights and decision rules should still stand on their own.
Keep these four things distinct throughout: task datasets, recorded trajectories, supervised
training examples, and RL policy optimisation. Never imply that exporting trajectories is RL
training.
## Validation
- Structural: frontmatter is present and valid, the name matches the folder, every referenced
file exists, every evidence timestamp falls within the source video's duration, and every
skill has a key insights section with at least three sourced insights.
- Execution: run every script you created. Where feasible, apply at least one skill end to end on
a small example the videos don't use (e.g. a text grid-world, or a "make this failing unit
test pass" task).
- Report each item as STRUCTURALLY CHECKED, EXECUTED (with command and result), or UNTESTED
(with reason).
## HTML report (report/index.html)
### Content, in this order
1. Header: report title, date checked, the agent's capability summary (had / lacked).
2. Summary: 3–5 sentences on what was produced and the main limitations. No marketing language.
3. Sources: one row per video (title, channel, published date, duration, views with date
checked, linked code or repository, access status).
4. One section per video:
- The original video embedded with a privacy-enhanced YouTube embed
(https://www.youtube-nocookie.com/embed/<VIDEO_ID>), with a 16:9 responsive frame.
- Link to the original.
- Timestamped outline of the video.
- Key insights and takeaways, each with a clickable timestamp and a label.
- Learning points: numbered, each with a clickable timestamp that seeks the embedded player
(YouTube IFrame Player API) and an OBSERVED / INFERRED / UPDATED label.
- Unresolved details.
- If embedding is blocked, show the video thumbnail linked to youtube.com/watch?v=<ID>
and state that embedding was unavailable.
5. How the videos compare: agreements, differences, and how each fills the others' gaps.
6. One section per skill:
- Name, absolute path to SKILL.md, one-sentence purpose, and when to use it.
- Key insights the skill carries, with their sources.
- Procedure summary (the key steps, not the whole file).
- Evidence: every supporting source point as a row — video, timestamp (clickable), label,
and what the skill took from it. Include doc URLs for UPDATED items.
- Validation status with the command and result if executed.
7. Coverage matrix: skills × the videos, showing which video supports which skill, plus
the focus areas no video covered.
8. Data distinctions: a short table defining task dataset, trajectory, supervised example, and
RL policy optimisation, and which of them the skills actually produce.
9. Limitations and untested items.
10. Three copy-paste reuse requests, each in a code block with a copy button.
### Visual design: light mode, in Google's design language
- Style only: do not use Google logos or wordmarks, or suggest the report is a Google product.
- Colours: page #FFFFFF; secondary surfaces #F8F9FA; borders #DADCE0; primary text #202124;
secondary text #5F6368; links and primary actions #1A73E8. Use the Google accent set
(blue #4285F4, red #EA4335, yellow #FBBC04, green #34A853) only for status and labels,
e.g. OBSERVED blue, INFERRED yellow tint with dark text, UPDATED green, UNTESTED red.
Text must meet WCAG AA contrast.
- Type: Google Sans / Google Sans Text if available from Google Fonts, otherwise Roboto; Roboto
Mono or Google Sans Code for code and timestamps. Clear scale: one H1, H2 per section, 16px
body, 1.5 line height, comfortable line length (about 70–80 characters).
- Layout: 8px spacing grid, max content width about 1100px, sticky left table of contents on
desktop that collapses on mobile, flat cards with 1px borders or a subtle Material elevation
shadow, 8–12px corner radius, plain tables with hairline row dividers.
- Avoid the generic "AI-generated" look: no gradients, purple/indigo themes, glassmorphism,
glowing effects, emoji used as icons, sparkle icons, oversized hero banners, decorative
blobs, or hype copy ("unlock", "supercharge", "seamless"). Prefer real content, tables, and
data over decoration.
- Technical: one self-contained HTML file with inline CSS and JS. Only external requests allowed:
Google Fonts and YouTube embed/API. Responsive down to 360px width with no horizontal
page scroll. Semantic HTML, keyboard-accessible controls, alt text on images.
### Serve and verify
1. Start a static server from rl-env-skills/report/ bound to 127.0.0.1, e.g.
`python3 -m http.server 8000 --bind 127.0.0.1`. If port 8000 is busy, use the next free port.
Keep the server running when you finish.
2. Do not rely on opening the file from disk: YouTube embeds often fail without an http origin.
3. Verify: the page returns HTTP 200; every embed loads or shows the fallback; timestamp links
seek the player; all anchors and file links resolve; no console errors. If you have a browser
tool, take a desktop and a 375px-wide screenshot and save them to report/assets/.
4. Report how you verified each item, and which checks you could not run.
## Deliverables
- REPORT.md: a plain-text version of the report's findings.
- manifest.json:
{ "date_checked": "...",
"videos": [{"url","title","channel","published","duration","views","access_status"}],
"skills": [{"name","path","sources":["<video id>", "..."],
"insights": <number of sourced insights>,
"validation":"executed|structural|untested"}],
"capabilities": {"video": bool, "frames": bool, "transcripts": bool, "code_exec": bool,
"browser_preview": bool},
"report": {"path": "<absolute path to index.html>", "preview_url": "http://127.0.0.1:<port>/",
"server_command": "...", "verified": [...], "not_verified": [...]} }
- Final reply: the preview link on its own line first
(http://127.0.0.1:<port>/), then the command to restart the server if it stops, then a short
summary of the videos, skills with absolute paths, validation results, and limitations.
Einige Teile dieses Briefings leisten die eigentliche Arbeit:
- Use only these videos hält deine Agenten bei den Quellen, die du ausgewählt hast – kein Austausch, nichts zusätzlich.
- Capture insights, not only procedures sorgt dafür, dass das Warum mit dem Wie mitkommt. Mehr dazu weiter unten.
- Capability honesty verhindert, dass jemand ein Videobild beschreibt, das niemand tatsächlich gesehen hat.
- Die Labels OBSERVED / INFERRED / UPDATED halten Fakten, Interpretation und anhand der Doku geprüfte Aktualisierungen auseinander.
- Die Datenunterscheidungen halten Aufgaben-Datasets, Trajektorien, überwachte Beispiele und RL-Policy-Optimierung getrennt – damit das Exportieren von Trajektorien nie mit Training verwechselt wird.
Was wir am Briefing geändert haben – und warum
Der Lauf in unserem Video nutzte eine frühere Version dieses Briefings. Vieles daran hat gut funktioniert. Gemini 4 hat alle drei Vorträge angesehen, Details mit der Harbor-Dokumentation und dem Repository abgeglichen und vier Skills erstellt. Jedes Skill-Skript lief vollständig durch – an einer Aufgabe, die in keinem der Vorträge vorkommt: einen Python-Konfigurationsparser namens fix-ini-interpolator reparieren.
Beim Lesen der Skills fiel uns aber etwas auf. Sie stützten sich stark auf Harbor-Funktionen – Ordnerstrukturen für Aufgaben, Trajektorienformate und CLI-Befehle. Die Erkenntnisse dahinter blieben größtenteils im Bericht.
Dabei stecken die Vorträge voller Erkenntnisse. Der Bericht selbst hat diese festgehalten:
- Scaffolds zählen genauso viel wie Modelle. Hängende Befehle früh abzubrechen brachte etwa 5–10 %, verschiedene Modelle in einem Lauf zu mischen etwa 5–6 % (Vortrag auf dem Ray Summit, 18:05–19:23).
- Plane früh für Skalierung. Ein Laptop schafft höchstens etwa sechs Container gleichzeitig – deshalb sind die Teams auf Cloud-Sandboxes umgestiegen (alle drei Vorträge).
- Reward Hacking ist das Overfitting des RL. Behandle einen verdächtig hohen Score so, wie du einen verdächtig niedrigen Validierungsverlust behandeln würdest (Vortrag bei AI Engineer, 06:35).
Ein Skill, der nur weiß, wie man ein Tool ausführt, kann dir nicht sagen, wann der Ansatz scheitert – oder was auf einem Stack ohne dieses Tool zu tun ist. Deshalb haben wir vier Dinge geändert:
- Erkenntnisse sind ein vollwertiges Ergebnis. Jeder Videoabschnitt und jeder Skill hält jetzt die Überlegungen, Lektionen, Ergebnisse und Warnungen der Sprecher fest – jeweils mit Zeitstempel.
- Erst das Prinzip, dann das Tool. Harbor und Terminal-Bench gelten als eine Möglichkeit, eine Methode anzuwenden, nicht als die Methode selbst.
- Keine Tool-Wrapper. Jeder Skill braucht einen Abschnitt mit den wichtigsten Erkenntnissen und einen werkzeugunabhängigen Weg. Entfernst du die Befehle, muss der Skill trotzdem noch etwas lehren.
- Die Validierung prüft das. Jeder Skill muss mindestens drei belegte Erkenntnisse enthalten, sonst fällt er bei der Strukturprüfung durch.
Außerdem haben wir eine kleine Unstimmigkeit behoben. Das frühere Briefing sprach von „den zwei Videos“, listete aber drei Links. Gemini 4 hat das bemerkt, im Bericht vermerkt und alle drei analysiert – die neue Formulierung funktioniert für beliebig viele Videos.
Lass deine Agenten arbeiten
Schicke das Briefing ab. Gemini 4 plant die Arbeit und startet die Agenten. Von da an folgt der Lauf dem Briefing:
- Ansehen jedes Vortrags – Untertitel, Frames, Folien und Live-Demos – unter Beibehaltung der Zeitstempel.
- Destillieren der Methoden und Erkenntnisse in Skills, jeder mit eigener Nachweisdatei.
- Validieren der Skills und Festhalten, was geprüft, ausgeführt oder ungetestet blieb.
- Bericht erstellen und unter
127.0.0.1ausliefern.
In unserem Lauf haben die Agenten alle drei Vorträge heruntergeladen, über 25 Keyframes extrahiert, vollständige Transkripte mit Zeitstempeln abgerufen und Harbor-Details mit der offiziellen Dokumentation abgeglichen – und anschließend die heruntergeladenen Videodateien gelöscht, wie es das Briefing verlangt.
Bericht öffnen
Der Bericht öffnet sich auf einem lokalen Server – in unserem Lauf unter http://127.0.0.1:8000. Das findest du dort:
- Fähigkeiten – was die Agenten hatten und was ihnen fehlte, vom Ansehen der Videos bis zur Browser-Vorschau.
- Zusammenfassung und Quellen – jeder Vortrag mit Kanal, Veröffentlichungsdatum, Länge, Aufrufen und verlinkten Repositories.
- Ein Abschnitt pro Vortrag – das Video, eingebettet mit einem datenschutzfreundlichen Player, eine Gliederung mit Zeitstempeln und gekennzeichnete Lernpunkte.
- Wie sich die Vorträge vergleichen – wo sie übereinstimmen, wo sie sich unterscheiden und wie jeder die Lücken der anderen füllt.
- Ein Abschnitt pro Skill – Zweck, wichtigste Schritte, Nachweise und der genaue Validierungsbefehl.
- Einschränkungen – was ungetestet blieb und warum, etwa Cloud-Sandboxes und kostenpflichtige Modell-APIs.
Abdeckungsmatrix lesen
Die Matrix zeigt, welcher Skill welchen Teil des RL-Workflows abdeckt – und wo die Vorträge Lücken lassen.
| Schwerpunkt | Task Scaffolder | Verifier & Anti-Cheat | Rollout Collector | SFT Dataset Preparer |
|---|---|---|---|---|
| Aufgaben, Beobachtungen, Aktionen und Abbruchbedingungen definieren | Primär | Sekundär | Primär | - |
| Reproduzierbare Umgebungen und Reset | Primär | Sekundär | Sekundär | - |
| Verifier und Belohnungsfunktionen bauen | Sekundär | Primär | - | - |
| Reward Hacking und ungültige Erfolge erkennen | - | Primär | Sekundär | - |
| Trajektorien sammeln, bewerten und prüfen | - | - | Primär | Sekundär |
| Daten für SFT-Training und Evaluierung vorbereiten | - | - | - | Primär |
| Lücke: Policy-Gradient-Mathematik und Trainer-Interna | Nicht abgedeckt | Nicht abgedeckt | Nicht abgedeckt | Getrennt gehalten |
| Lücke: dichtes Process-Reward-Shaping auf Schrittebene | Nicht abgedeckt | Nur Ergebnisbelohnung | Nicht abgedeckt | Nicht abgedeckt |
Die beiden Lückenzeilen sind wichtig. Die Vorträge nennen Trainer wie SkyRL und Tinker, zeigen aber nie die Trainingsschleife – also tun die Skills auch nicht so, als würden sie sie abdecken.
Skills einsetzen
Jeder Skill liegt in einem eigenen Ordner in rl-env-skills/:
sandboxed-task-environment-scaffolder– reproduzierbare, containerisierte Aufgaben aufsetzen und validieren.verifier-and-anti-cheat-auditor– Ergebnis-Verifier bauen und auf Reward Hacking prüfen.rollout-trajectory-collector-and-debugger– Rollouts in der Sandbox ausführen, Trajektorien aufzeichnen und Fehler klassifizieren.trajectory-to-sft-dataset-preparer– verifizierte Trajektorien zu sauberen SFT-Daten filtern, streng getrennt vom RL-Training.
Verweise einen Coworker auf einen davon und gib ihm eine echte Aufgabe, zum Beispiel:
Use rl-env-skills/verifier-and-anti-cheat-auditor/SKILL.md to design a verifier
for my "make this failing unit test pass" task. Flag any way an agent could
pass without fixing the bug.
Der Skill enthält das Vorgehen, die Entscheidungsregeln und die Erfolgskriterien. Die Nachweisdatei enthält die Belege – und mit dem neuen Briefing kommen auch die Erkenntnisse mit.
Mach es zu deinem eigenen
Das Briefing funktioniert für jede Auswahl technischer Vorträge. Tausche die Videolinks und die Schwerpunktliste aus und behalte den Rest:
- Behalte die Erkenntnisregeln. Sie machen aus einem Tool-Handbuch hart erarbeitetes Urteilsvermögen.
- Behalte die Ehrlichkeitsregeln. Fähigkeitsprüfungen und Aussage-Labels machen das Ergebnis vertrauenswürdig.
- Behalte den Validierungsschritt. Ein Skill, der nie ausgeführt wurde, ist eine Notiz, kein Skill.
Anderthalb Stunden Vorträge müssen nicht anderthalb Stunden Vorträge bleiben. Gib sie deinen Agenten – und behalte, was sie lernen.
Credits: erstellt mit Gemini 4 und Eigent. Vorträge von Mike Merrill (Ray Summit 2025), Alex Shaw und Ryan Marten (AI Engineer) sowie den Terminal-Bench-Gründern bei Latent Space – die Originale gibt es auf YouTube. Musik: "Wallpaper" Kevin MacLeod (incompetech.com), lizenziert unter Creative Commons: By Attribution 4.0.
