Screencast Studio
WarnAudited by ClawScan on May 10, 2026.
Overview
Screencast Studio mostly fits its demo-recording purpose, but its default cleanup step can recursively delete unrelated files in the chosen working directory.
Install only if you will run it in a fresh, dedicated screencast folder. Do not place the templates directly in an existing source repo or important project directory unless you first remove or rewrite `clean.js` and the `ship` cleanup step. Use a test account where possible, keep `storageState.json` and generated videos/screenshots private, and review mask coverage before sharing any output.
Findings (6)
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
If run in the wrong folder, the skill could wipe files that were not created by the screencast pipeline.
The cleanup script recursively removes every file or directory in its working directory except a narrow whitelist. Because the documented ship workflow runs cleanup, choosing an existing app/project directory could delete unrelated source files or data.
for (const name of fs.readdirSync(ROOT)) { ... if (isDir && KEEP_DIRS.has(name)) continue; if (!isDir && KEEP_FILES.has(name)) continue; ... rmRecurse(p); }Run this only in a fresh dedicated demo directory, remove cleanup from the default workflow, or change `clean.js` to delete only explicitly named generated artifacts after confirmation.
Anyone with access to the generated project folder may be able to reuse the saved session for the target web app.
The optional login flow stores authenticated browser cookies locally so later recordings can use the logged-in session.
`storageState.json` should exist (~1-5KB, contains cookies)
Use a test account where possible, keep `storageState.json` out of git and shared folders, and delete it when the demo is finished.
Private UI content, account names, customer data, or other sensitive information could remain in generated videos or review images.
The skill intentionally persists video and screenshot artifacts from the user's web UI. These artifacts may contain sensitive data if masks are incomplete.
`final.mp4` — h264, cursor overlay + click ripples + burned-in subtitles + persistent-mask blur
- `review/{flow,visual,coverage,sensitive}/*.png` — 4-pass screenshot set for visual + privacy QAInspect the review images before sharing, configure masks carefully, and keep generated outputs out of public repositories unless reviewed.
The skill runs local tooling as part of rendering and review.
The template executes ffmpeg to render the final video. This is expected for the stated purpose, but it is still local command execution.
const r = spawnSync(ffmpegPath, args, { stdio: 'inherit', cwd: __dirname });Install dependencies from trusted sources and run the pipeline in a dedicated directory rather than a sensitive project root.
A demo run may create or upload test data in the target application.
Example walkthroughs can create folders and upload files in the target web app. The example frames this as an isolated additive demo, which is purpose-aligned, but it can still mutate the user's account or app data.
Stage 13 : New isolated folder + enter Stage 14 : Upload 3 test files into folder
Use staging environments or test accounts, keep demo changes isolated, and avoid running mutation steps against production data unless the user explicitly approves.
First use downloads and runs third-party tooling on the user's machine.
The skill relies on npm-installed packages and a Playwright Chromium download, while the registry metadata has no install spec. This is expected for the workflow but is still external dependency setup.
`playwright` | Browser automation + headless recording | After install: `npx playwright install chromium` | `ffmpeg-static` | Bundled ffmpeg binary
Run setup in an isolated project, review the generated `package.json`, and use normal package-lock and dependency-review practices.