pr-walkthrough by tldraw/tldraw
npx skills add https://github.com/tldraw/tldraw --skill pr-walkthrough为拉取请求创建带旁白的讲解视频。这旨在成为一个内部产物,提供与拉取请求作者创建的 Loom 视频相同的益处——逐步讲解代码变更,解释做了什么以及为什么这样做,以便任何观看者都能快速理解该 PR。
输入: 一个 GitHub 拉取请求 URL(例如,https://github.com/tldraw/tldraw/pull/7924)。如果只给出 PR 编号或其他描述,则假定该 PR 位于 tldraw/tldraw 仓库。
输出: 一个 1600x900 分辨率、带有音频旁白和标准化介绍/结尾幻灯片的 MP4 视频,保存到 .claude/skills/pr-walkthrough/out/pr-<编号>-walkthrough.mp4。
所有中间文件(音频、清单、脚本)都放在 .claude/skills/pr-walkthrough/tmp/pr-<编号>/ 中。此目录被 git 忽略。只有最终的 .mp4 文件位于 .claude/skills/pr-walkthrough/out/。
这是从作者视角进行的讲解。 目标与 PR 作者坐下来向某人逐步讲解变更相同——展示特定代码,解释更改了什么以及为什么更改,按照有助于理解的顺序进行。观看者应该能理解 代码的作用 以及 如何思考这些变更。
这意味着:
广告位招租
在这里展示您的产品或服务
触达数万 AI 开发者,精准高效
阅读 PR 提交、差异和描述。理解叙事脉络:
这解决了什么问题?
方法是什么?
关键机制是什么?
gh pr view <编号> --json title,body,commits git log main..HEAD --oneline git diff main..HEAD --stat
将旁白撰写为连续文本,分成逻辑段落。每个段落是讲解的一个节拍——一个概念、一个变更或一组相关的变更。将此保存为 .claude/skills/pr-walkthrough/tmp/pr-<编号>/SCRIPT.md。
旁白应读起来像是作者向同事解释 PR:“那么,我们在这里做的是...核心问题是 X...我采用的方法是 Y...如果你看这里的这个函数...”
结构:介绍 → 背景/问题 → 代码讲解 → 总结。请参阅下面的脚本结构。
如果提交内容简单且组织良好(通常在分支名称中包含 -clean),你可以遵循其提交消息和描述来指导你的旁白。否则,检查代码并创建你自己的叙述。按照能建立在前一个概念之上的顺序引入概念。
避免冗余,尤其是在介绍和第一个内容段落之间。
将所有旁白生成为单个音频文件,然后将其分割成每个段落的片段。这能在整个讲解过程中产生一致的语音、音量和节奏。
编写一个 narration.json 文件,然后运行 generate-audio.sh CLI 工具:
.claude/skills/pr-walkthrough/scripts/generate-audio.sh narration.json .claude/skills/pr-walkthrough/tmp/pr-<编号>/
API 密钥: 自动从仓库 .env 文件(GEMINI_API_KEY)中获取。
{
"style": "以平静、稳定、专业的语调朗读以下讲解旁白。以从容的语速讲述,就像拉取请求的作者在向同事逐步讲解代码变更一样。在每个编号部分之间,留出短暂的停顿——不超过一秒钟的静音。",
"voice": "Iapetus",
"slides": [
"这个拉取请求为箭头工具添加了支持群组的绑定解析...",
"核心问题是当目标形状...时,箭头绑定会失效...",
"如果你查看 ArrowBindingUtil.ts 中的 getBindingTarget 方法..."
]
}
style — 语音角色和节奏指示。保持简短且具体。voice — Gemini 语音名称(默认:Iapetus)。slides — 旁白文本数组,每个条目对应一个段落。脚本会自动添加 [1]、[2] 等段落标记。gemini-2.5-pro-tts 的 API 调用生成完整的旁白作为单个 WAV 文件。32k 令牌的上下文窗口对于 5-7 分钟的音频来说绰绰有余。gemini-2.5-flash 来听取音频并同时处理段落文本,返回每个段落的开始时间戳(以秒为单位)。脚本根据这些边界进行分割。输出: 每个段落的音频片段(audio-00.wav,...)和一个 durations.json 文件,将每个音频文件名映射到其持续时间(以秒为单位)。
依赖项: ffmpeg / ffprobe。除了标准库外,不需要 Python 包。
请勿在旁白文本中使用 [pause long] 或 [pause medium] 等标记标签——模型可能会逐字朗读它们。
TTS 截断: 如果 generate-audio.sh 因 TTS 输出被截断(末尾出现零长度片段)而失败,请勿缩短旁白。相反,应减少脚本中的 MAX_WORDS_PER_CHUNK(例如,从 600 减少到 400),以便将旁白分割到更多的 TTS API 调用中。该脚本已经支持多块生成——它会分别生成每个块并连接结果。修复方法总是分割成更多块,而不是从脚本中删除内容。
清单是一个 JSON 文件,描述视频中的每一张幻灯片。它连接了旁白/音频步骤和 Remotion 渲染器。
从步骤 3 读取 durations.json 以获取每个音频片段的持续时间(以秒为单位)。然后在音频文件旁边编写一个 manifest.json:
{
"pr": 7865,
"slides": [
{
"type": "intro",
"title": "修复 canvas-in-front z-index 层级 #7865",
"date": "February 14, 2026",
"audio": "audio-00.wav",
"durationInSeconds": 3.2
},
{
"type": "diff",
"filename": "packages/editor/editor.css",
"language": "css",
"diff": "@@ -12,7 +12,7 @@\n --tl-z-canvas: 100;\n- --tl-z-canvas-in-front: 600;\n+ --tl-z-canvas-in-front: 250;\n --tl-z-shapes: 300;",
"audio": "audio-01.wav",
"durationInSeconds": 25.8
},
{
"type": "code",
"filename": "packages/editor/src/lib/Editor.ts",
"language": "typescript",
"code": "function getZIndex() {\n return 250\n}",
"audio": "audio-02.wav",
"durationInSeconds": 13.5
},
{
"type": "text",
"title": "总结",
"subtitle": "将 canvas-in-front 的 z-index 从 600 移动到 250。",
"audio": "audio-07.wav",
"durationInSeconds": 7.4
},
{
"type": "list",
"title": "关键变更",
"items": ["降低了 z-index", "更新了测试", "添加了迁移"],
"audio": "audio-06.wav",
"durationInSeconds": 10.2
},
{
"type": "outro",
"durationInSeconds": 3
}
]
}
| 类型 | 必填字段 | 描述 |
|---|---|---|
intro | title, date, audio, durationInSeconds | 徽标 + 标题 + 日期 |
diff | filename, language, diff, audio, durationInSeconds | 语法高亮的统一差异 |
code | filename, language, code, audio, durationInSeconds | 语法高亮的源代码 |
text | title, audio, durationInSeconds | 标题 + 可选的 subtitle |
list | title, items, audio, durationInSeconds | 标题 + 编号项目 |
image | src, audio, durationInSeconds | 预渲染图像(备用) |
segment | title, durationInSeconds | 段落之间的静音标题卡 |
outro | durationInSeconds | 仅徽标,无音频 |
focus 的动画滚动对于较长的差异或代码(超过约 30 行),渲染器将字体保持在可读的 16px,并使用在焦点之间滚动的动画视口。向 diff 或 code 幻灯片添加 focus 数组:
{
"type": "diff",
"filename": "packages/editor/src/lib/Editor.ts",
"language": "typescript",
"diff": "... 60-line diff ...",
"focus": [
{ "line": 3, "at": 0 },
{ "line": 25, "at": 0.4 },
{ "line": 50, "at": 0.8 }
],
"audio": "audio-03.wav",
"durationInSeconds": 30
}
line — 要居中在屏幕上的行号(相对于解析后的差异/代码行的 0 起始索引)。at — 何时到达此位置,作为幻灯片持续时间的分数(0 = 开始,1 = 结束)。视口在焦点之间平滑过渡。在第一个点之前,它保持在第一个位置;在最后一个点之后,它保持在那里。
何时使用 focus: 任何超过约 30 行的差异或代码幻灯片。没有 focus,长内容从顶部开始并保持静态——观看者看不到底部。有了 focus,你可以引导观看者的视线到每个时刻正在讨论的代码。
何时省略 focus: 短的差异(≤30 行)在 16px 下适合屏幕,不需要滚动。
对于 diff 幻灯片,粘贴相关块(hunk)的统一差异。这是该文件部分的 git diff 输出——包括 @@ 块头部和 +/-/ 行前缀。渲染器解析这些前缀以应用绿色/红色背景和语法高亮。
要获取特定文件的差异:
git diff main..HEAD -- 路径/到/文件.ts
仅包含相关的块,而不是整个文件的差异。去除 diff --git 和 ---/+++ 头部行——从 @@ 块头部开始。
对于 code 幻灯片,粘贴相关的源代码(一个函数、一个类、一个部分)。不需要差异前缀。
在每个内容段落之前插入一个 segment 幻灯片 来介绍它——除了在介绍和背景/概述段落之前。这包括代码讲解段落和总结/结论。每个段落幻灯片是 3 秒的静音,段落标题居中显示在屏幕上。
{
"type": "segment",
"title": "缩放状态机",
"durationInSeconds": 3
}
这些提供了部分之间清晰的视觉中断,并在每个新主题开始前给观看者一个定向的时刻。
向 code 和 diff 幻灯片添加 title 字段,以在左上角显示一个小标签,标识观看者所在的段落。使用与前面 segment 幻灯片相同的标题。这有助于观看者定向,特别是当一个段落跨越多张幻灯片时。
{
"type": "diff",
"title": "缩放状态机",
"filename": "packages/editor/src/lib/ZoomTool.ts",
...
}
运行 render.sh 脚本:
.claude/skills/pr-walkthrough/video/render.sh \
.claude/skills/pr-walkthrough/tmp/pr-<编号>/manifest.json \
.claude/skills/pr-walkthrough/out/pr-<编号>-walkthrough.mp4
该脚本将清单 + 音频文件复制到 Remotion 项目的 public/ 目录中,如果需要则安装 npm 依赖项,并渲染视频。
依赖项: Node.js 18+,ffmpeg(用于最终编码)。第一次运行会安装 Remotion(约 50MB)。
最终输出位于 .claude/skills/pr-walkthrough/。所有中间文件都放在 .claude/skills/pr-walkthrough/tmp/(被 git 忽略):
.claude/skills/pr-walkthrough/
├── SKILL.md # 此文件
├── scripts/ # CLI 工具(已检入)
│ └── generate-audio.sh # narration.json → 每张幻灯片的 WAV + durations.json
├── video/ # Remotion 项目(已检入)
│ ├── package.json
│ ├── tsconfig.json
│ ├── remotion.config.ts
│ ├── render.sh # manifest.json → MP4
│ ├── public/ # 渲染时自动填充
│ └── src/ # 每种幻灯片类型的 React 组件
├── out/ # 最终输出(被 git 忽略)
│ └── pr-XXXX-walkthrough.mp4
└── tmp/ # 中间文件(被 git 忽略)
└── pr-XXXX/
├── SCRIPT.md # 旁白脚本
├── narration.json # generate-audio.sh 的输入
├── full-narration.wav # 分割前的完整 TTS 输出
├── durations.json # 音频文件名 → 持续时间(秒)
├── manifest.json # render.sh 的输入
└── audio-XX.wav # 每个段落的音频片段
GEMINI_API_KEY 存储在项目根目录的 .env 文件中。用于 TTS 和音频对齐。gemini-2.5-pro-ttsIapetus(始终)讲解遵循一致的叙事脉络。并非每个部分都需要自己的段落——根据 PR 的复杂性合并或跳过部分。目标是总共 8-12 个段落,其中绝大多数展示代码。
介绍卡:tldraw 徽标 + PR 标题 + 日期。旁白应该是一个单一的句子,从高层次上说明这个 PR 做了什么。暂时不要深入细节。
清单幻灯片类型:intro。
在深入代码之前进行简要定向。在这个 PR 之前的情况是什么?是什么问题或需求促使了这项工作?保持简短——只需足够的背景信息,使代码讲解有意义。
如果可以在展示第一段相关代码的同时解释背景,则跳过独立的背景段落,并将其融入第一个代码段落中。
清单幻灯片类型:text 或 diff(如果展示有问题的代码)。
视频的主体部分。逐步讲解实际的代码变更,在解释做了什么以及为什么的同时展示具体的差异和文件。
每个段落都应该展示代码。 对于变更使用 diff 幻灯片,对于未更改的参考代码使用 code 幻灯片。
指南:
git diff main..HEAD -- 路径/到/文件 获取差异,然后提取相关的块。index.ts 中还添加了一些类型导出——这些只是我们接下来将看到的新类型的重新导出。”简要回顾 PR 完成了什么。这是一个简短的总结——一两句话总结整体变更,如果相关,提及任何已知的限制或后续工作。
清单幻灯片类型:text。
tldraw 徽标,3 秒静音。始终将此作为最后一张幻灯片包含。
清单幻灯片类型:outro,带有 durationInSeconds: 3。
BindingUtil.ts 中,onAfterChange 处理程序现在检查群组祖先”——而不是“绑定系统已更新。” 命名文件和函数,以便观看者能将旁白与屏幕上的内容联系起来。每周安装次数
69
仓库
GitHub 星标数
46.0K
首次出现
Feb 16, 2026
安全审计
安装于
opencode69
gemini-cli68
amp68
github-copilot68
codex68
kimi-cli68
Create a narrated walkthrough video for a pull request. This is designed to be an internal artifact, providing the same benefit as would a loom video created by the pull request's author — walking through the code changes, explaining what was done and why, so that anyone watching can understand the PR quickly.
Input: A GitHub pull request URL (e.g., https://github.com/tldraw/tldraw/pull/7924). If given just a PR number or other description, assume that the PR is on the tldraw/tldraw repository.
Output: An MP4 video at 1600x900 with audio narration and standardized intro / outro slides, saved to .claude/skills/pr-walkthrough/out/pr-<number>-walkthrough.mp4.
All intermediate files (audio, manifest, scripts) go in .claude/skills/pr-walkthrough/tmp/pr-<number>/. This directory is gitignored. Only the final .mp4 lives at .claude/skills/pr-walkthrough/out/.
This is a walkthrough from the author's perspective. The goal is the same as if the PR author sat down with someone and walked them through the changes — showing specific code, explaining what changed and why, in an order that builds understanding. The viewer should come away understanding both what the code does and how to think about the changes.
This means:
Read the PR commits, diff, and description. Understand the narrative arc:
What problem does this solve?
What's the approach?
What are the key mechanisms?
gh pr view <number> --json title,body,commits git log main..HEAD --oneline git diff main..HEAD --stat
Write the narration as continuous text, broken into logical segments. Each segment is a beat of the walkthrough — a concept, a change, or a group of related changes. Save this as .claude/skills/pr-walkthrough/tmp/pr-<number>/SCRIPT.md.
The narration should read like the author explaining the PR to a colleague: "So here's what we're doing... The core problem was X... The approach I took was Y... If you look at this function here..."
Structure: intro → context/problem → code walkthrough → summary. See Script structure below.
If the commits are simple and organized well (often on a branch with -clean in its name), you can follow their commit messages and descriptions to guide your narration. Otherwise, examine the code and create your own narrative. Introduce concepts in an order that builds on previous ones.
Avoid redundancy, especially between intro and first content segment.
Generate all narration as a single audio file , then split it into per-segment clips. This produces consistent voice, volume, and pacing across the entire walkthrough.
Write a narration.json file, then run the generate-audio.sh CLI tool:
.claude/skills/pr-walkthrough/scripts/generate-audio.sh narration.json .claude/skills/pr-walkthrough/tmp/pr-<number>/
API key: Sourced automatically from the repo .env file (GEMINI_API_KEY).
{
"style": "Read the following walkthrough narration in a calm, steady, professional tone. Speak at a measured pace as if the author of a pull request were walking a colleague through the code changes. Between each numbered section, leave a brief pause — no more than one second of silence.",
"voice": "Iapetus",
"slides": [
"This pull request adds group-aware binding resolution to the arrow tool...",
"The core problem was that arrow bindings broke when the target shape...",
"If you look at the getBindingTarget method in ArrowBindingUtil.ts..."
]
}
style — Voice persona and pacing instructions. Keep it short and specific.voice — Gemini voice name (default: Iapetus).slides — Array of narration text, one entry per segment. The script adds [1], [2] section markers automatically.gemini-2.5-pro-tts generates the full narration as a single WAV. The 32k-token context window is plenty for 5-7 minutes.gemini-2.5-flash call listens to the audio alongside the segment texts and returns the start timestamp (in seconds) of each segment. The script splits at those boundaries.Output: Per-segment audio clips (audio-00.wav, ...) and a durations.json file mapping each audio filename to its duration in seconds.
Dependencies: ffmpeg / ffprobe. No Python packages required beyond the standard library.
Do NOT use [pause long] or [pause medium] markup tags in the narration text — the model may read them aloud literally.
TTS truncation: If generate-audio.sh fails because the TTS output was truncated (zero-length clips at the end), do not shorten the narration. Instead, reduce MAX_WORDS_PER_CHUNK in the script (e.g., from 600 to 400) so the narration is split across more TTS API calls. The script already supports multi-chunk generation — it generates each chunk separately and concatenates the results. The fix is always to split into more chunks, never to cut content from the script.
The manifest is a JSON file that describes every slide in the video. It bridges the narration/audio step and the Remotion renderer.
Read the durations.json from step 3 to get the duration (in seconds) for each audio clip. Then write a manifest.json alongside the audio files:
{
"pr": 7865,
"slides": [
{
"type": "intro",
"title": "Fix canvas-in-front z-index layering #7865",
"date": "February 14, 2026",
"audio": "audio-00.wav",
"durationInSeconds": 3.2
},
{
"type": "diff",
"filename": "packages/editor/editor.css",
"language": "css",
"diff": "@@ -12,7 +12,7 @@\n --tl-z-canvas: 100;\n- --tl-z-canvas-in-front: 600;\n+ --tl-z-canvas-in-front: 250;\n --tl-z-shapes: 300;",
"audio": "audio-01.wav",
"durationInSeconds": 25.8
},
{
"type": "code",
"filename": "packages/editor/src/lib/Editor.ts",
"language": "typescript",
"code": "function getZIndex() {\n return 250\n}",
"audio": "audio-02.wav",
"durationInSeconds": 13.5
},
{
"type": "text",
"title": "Summary",
"subtitle": "Moved canvas-in-front from z-index 600 to 250.",
"audio": "audio-07.wav",
"durationInSeconds": 7.4
},
{
"type": "list",
"title": "Key changes",
"items": ["Lowered z-index", "Updated tests", "Added migration"],
"audio": "audio-06.wav",
"durationInSeconds": 10.2
},
{
"type": "outro",
"durationInSeconds": 3
}
]
}
| Type | Required fields | Description |
|---|---|---|
intro | title, date, audio, durationInSeconds | Logo + title + date |
diff | filename, language, diff, , |
focusFor longer diffs or code (more than ~30 lines), the renderer keeps the font at a readable 16px and uses an animated viewport that scrolls between focus points. Add a focus array to diff or code slides:
{
"type": "diff",
"filename": "packages/editor/src/lib/Editor.ts",
"language": "typescript",
"diff": "... 60-line diff ...",
"focus": [
{ "line": 3, "at": 0 },
{ "line": 25, "at": 0.4 },
{ "line": 50, "at": 0.8 }
],
"audio": "audio-03.wav",
"durationInSeconds": 30
}
line — The line number (0-indexed into the parsed diff/code lines) to center on screen.at — When to arrive at this position, as a fraction of the slide's duration (0 = start, 1 = end).The viewport smoothly eases between focus points. Before the first point, it holds at the first position; after the last, it holds there.
When to use focus: Any diff or code slide with more than ~30 lines. Without focus, long content starts at the top and stays static — the viewer can't see the bottom. With focus, you guide the viewer's eye to the code being discussed at each moment.
When to omit focus: Short diffs (≤30 lines) fit on screen at 16px and don't need scrolling.
For diff slides, paste the unified diff for the relevant hunk(s). This is the output of git diff for that section of the file — including the @@ hunk header and +/-/ line prefixes. The renderer parses these prefixes to apply green/red backgrounds and syntax highlighting.
To get a diff for a specific file:
git diff main..HEAD -- path/to/file.ts
Include only the relevant hunks, not the entire file diff. Strip the diff --git and ---/+++ header lines — start from the @@ hunk header.
For code slides, paste the relevant source code (a function, a class, a section). No diff prefixes needed.
Insert a segment slide before each content segment to introduce it — except before the intro and context/overview segments. This includes code walkthrough segments and the summary/conclusion. Each segment slide is 3 seconds of silence with the segment title centered on screen.
{
"type": "segment",
"title": "Zoom state machine",
"durationInSeconds": 3
}
These provide clear visual breaks between sections and give the viewer a moment to orient before each new topic.
Add a title field to code and diff slides to show a small label in the top-left corner identifying which segment the viewer is in. Use the same title as the preceding segment slide. This helps orient viewers, especially when a segment spans multiple slides.
{
"type": "diff",
"title": "Zoom state machine",
"filename": "packages/editor/src/lib/ZoomTool.ts",
...
}
Run the render.sh script:
.claude/skills/pr-walkthrough/video/render.sh \
.claude/skills/pr-walkthrough/tmp/pr-<number>/manifest.json \
.claude/skills/pr-walkthrough/out/pr-<number>-walkthrough.mp4
The script copies manifest + audio files into the Remotion project's public/ directory, installs npm dependencies if needed, and renders the video.
Dependencies: Node.js 18+, ffmpeg (for final encoding). The first run installs Remotion (~50MB).
Final output lives in .claude/skills/pr-walkthrough/. All intermediate files go in .claude/skills/pr-walkthrough/tmp/ (gitignored):
.claude/skills/pr-walkthrough/
├── SKILL.md # This file
├── scripts/ # CLI tools (checked in)
│ └── generate-audio.sh # narration.json → per-slide WAVs + durations.json
├── video/ # Remotion project (checked in)
│ ├── package.json
│ ├── tsconfig.json
│ ├── remotion.config.ts
│ ├── render.sh # manifest.json → MP4
│ ├── public/ # Auto-populated at render time
│ └── src/ # React components for each slide type
├── out/ # Final outputs (gitignored)
│ └── pr-XXXX-walkthrough.mp4
└── tmp/ # Intermediate files (gitignored)
└── pr-XXXX/
├── SCRIPT.md # Narration script
├── narration.json # Input to generate-audio.sh
├── full-narration.wav # Full TTS output before splitting
├── durations.json # Audio filename → duration in seconds
├── manifest.json # Input to render.sh
└── audio-XX.wav # Per-segment audio clips
GEMINI_API_KEY in the project root .env file. Used for TTS and audio alignment.gemini-2.5-pro-ttsIapetus (always)The walkthrough follows a consistent narrative arc. Not every section needs its own segment — combine or skip sections based on the PR's complexity. The goal is 8-12 segments total, with the vast majority showing code.
The intro card: tldraw logo + PR title + date. The narration should be a single sentence that frames what this PR does at a high level. Don't go into detail yet.
Manifest slide type: intro.
Brief orientation before diving into code. What was the situation before this PR? What problem or need motivated the work? Keep this short — just enough framing that the code walkthrough makes sense.
If the context can be explained while showing the first piece of relevant code, skip the standalone context segment and fold it into the first code segment.
Manifest slide type: text or diff (if showing the problematic code).
The bulk of the video. Walk through the actual code changes, showing specific diffs and files while explaining what was done and why.
Every segment should show code. Use diff slides for changes and code slides for unchanged reference code.
Guidelines:
git diff main..HEAD -- path/to/file to get the diff, then extract the relevant hunks.index.ts — those are just re-exports of the new types we'll see next."Briefly recap what the PR accomplished. This is a short wrap-up — a sentence or two summarizing the overall change, mentioning any known limitations or follow-up work if relevant.
Manifest slide type: text.
The tldraw logo, 3 seconds of silence. Always include this as the final slide.
Manifest slide type: outro with durationInSeconds: 3.
BindingUtil.ts, the onAfterChange handler now checks for group ancestors" — not "The binding system was updated." Name files and functions so the viewer can connect the narration to what's on screen.Weekly Installs
69
Repository
GitHub Stars
46.0K
First Seen
Feb 16, 2026
Security Audits
Gen Agent Trust HubPassSocketPassSnykWarn
Installed on
opencode69
gemini-cli68
amp68
github-copilot68
codex68
kimi-cli68
agent-browser 浏览器自动化工具 - Vercel Labs 命令行网页操作与测试
166,500 周安装
RabbitMQ专家技能:消息队列最佳实践、测试驱动开发与性能优化指南
267 周安装
Tinybird CLI 指南:本地开发、部署与数据操作完整教程
272 周安装
OpenAI App迁移至MCP完整指南:SDK迁移、CSP配置与最佳实践
268 周安装
mgrep 代码语义搜索工具 - 智能探索大型代码库,支持自然语言查询代码/文本/PDF/图像
262 周安装
Go gRPC生产环境配置指南:版本化Protobuf、TLS、健康检查与错误处理
266 周安装
钉钉AI表格技能dingtalk-ai-table详解:Notable API操作指南与配置教程
266 周安装
audiodurationInSeconds| Syntax-highlighted unified diff |
code | filename, language, code, audio, durationInSeconds | Syntax-highlighted source code |
text | title, audio, durationInSeconds | Title + optional subtitle |
list | title, items, audio, durationInSeconds | Title + numbered items |
image | src, audio, durationInSeconds | Pre-rendered image (fallback) |
segment | title, durationInSeconds | Silent title card between segments |
outro | durationInSeconds | Logo only, no audio |