scripts/michel/michel-create-pr-with-screenshots/SKILL.md
Best practices for creating GitHub pull requests that include inline images — CLI terminal screenshots (from cli-demo-recorder), UI screenshots/videos (from ui-demo-recorder), or any other visual artifact. Use this skill whenever opening or updating a PR that has visual artifacts to embed, or when images aren't rendering in a PR description. Also use it when asked "how do I add screenshots to a PR", "why isn't my image showing", or "embed a demo in the PR".
npx skillsauth add PackmindHub/packmind michel-create-pr-with-screenshotsInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
GitHub PR descriptions behave differently from README files: relative paths don't resolve and SVG files don't render (sanitized for XSS). This skill codifies the two-step fix every time: convert to PNG, reference with an absolute raw URL.
| Artifact | Renders in PR? | Fix | | ------------------------ | -------------------------- | -------------------- | | PNG via absolute raw URL | ✅ always | nothing | | PNG via relative path | ❌ | use absolute URL | | SVG via raw URL | ❌ (blocked by GitHub CSP) | convert to PNG first | | WebM video | ❌ inline | link, don't embed |
From cli-demo-recorder (SVG output)
The recorder writes SVG. Convert it to PNG before committing:
# macOS
qlmanage -t -s 1400 -o docs/cli-demos/ docs/cli-demos/my-demo.svg
# produces docs/cli-demos/my-demo.svg.png — rename for clarity:
mv docs/cli-demos/my-demo.svg.png docs/cli-demos/my-demo.png
# Linux (install once: apt install librsvg2-bin)
rsvg-convert -w 1400 docs/cli-demos/my-demo.svg -o docs/cli-demos/my-demo.png
Keep the SVG in the repo (crisp at any zoom in README/docs). Commit both — SVG for docs, PNG for PR.
From ui-demo-recorder (PNG screenshots)
The recorder already produces PNGs — no conversion needed. They land in screenshots/ or .agent/artifacts/.
git add docs/cli-demos/my-demo.png
git commit -m "..."
git push
The file must be pushed before the URL resolves. GitHub serves uncommitted files as 404.
https://github.com/<owner>/<repo>/raw/<branch>/<path-to-file>
Example:
https://github.com/PackmindHub/packmind/raw/feat/my-branch/docs/cli-demos/my-demo.png
Get owner/repo/branch from:
git remote get-url origin # → https://github.com/PackmindHub/packmind
git branch --show-current # → feat/my-branch
## CLI demo

<details><summary>Plain text</summary>
```text
<paste .txt sidecar content here>
```
</details>
```
For multiple images, group them logically — one caption per image, collapsed plain-text fallback for each:
**Populated board:**

**Empty board:**

For WebM videos (from ui-demo-recorder): GitHub doesn't play video inline in PR descriptions. Link it instead:
[▶ demo.webm](https://github.com/<owner>/<repo>/raw/<branch>/videos/demo.webm) (click to play/download)
Before opening/updating the PR:
https://github.com/<owner>/<repo>/raw/<branch>/... (absolute, not relative)| Source | Recommended path |
| ---------------------------- | ------------------------------------------------------------------- |
| cli-demo-recorder | docs/cli-demos/<name>.png |
| ui-demo-recorder (manual PR) | docs/screenshots/<name>.png |
| Michel agent artifacts | .agent/artifacts/issue-<N>/<name>.png (agent writes here already) |
Pick a stable path — the URL in old PR descriptions will keep pointing there forever.
tools
Record polished UI demo videos and screenshots of a running web app using Playwright MCP — for client deliverables, release notes, feature walkthroughs, or bug repros. Produces an HD WebM video with chapter markers, a mandatory animated cursor overlay, and a mandatory subtitle bar that narrates each step (positioned deliberately so it never masks the UI being demonstrated), plus full-page screenshots at each step. Use this whenever the user asks to "record a demo", "create a screencast", "make a UI walkthrough video", "document this feature with video", "show the client how X works", "capture screenshots of the app", or anything similar — even when the user only says "make a video" or "take screenshots" in the context of a running frontend. Also use it when the user wants to demonstrate a workflow, generate marketing-quality footage of an app, or produce repeatable visual documentation.
tools
The canonical recipe for starting, checking, and stopping the Packmind local dev stack with Docker Compose — the single source of truth other skills and the Michel agent defer to. Covers bringing the full stack (PostgreSQL, Redis, NestJS API, React/Vite frontend on :4200, MCP server, nginx) up in the background, the init services (dependency install + TypeORM migrations) you must wait on, the critical host-port trap that the API on container port 3000 is NOT exposed to the host and must be reached via the frontend Vite proxy at localhost:4200/api/v0, confirming the API and frontend are actually serving before you depend on them, the persistent-volume gotcha that leaves stale Postgres schema and node_modules behind between runs, building the CLI, and tearing everything down so no container is left blocking the run. Use this whenever you need Packmind running locally — to verify a change, record a UI or CLI demo, hit the API, seed data, or reproduce a bug — and whenever you are about to start or stop `docker compose`. If you are an autonomous agent (e.g. Michel) that started the stack, you MUST use the teardown half before finishing. Prefer this over running `nx serve` on the host for anything that needs the real, containerized stack.
tools
--- name: michel-create-packmind-dataset description: Seed a local Packmind instance with a realistic dataset — one organization populated with standards, commands, and skills — so an autonomous agent can exercise its own changes against lifelike data instead of an empty app. Use this whenever you need populated Packmind data to verify a change end-to-end: reproducing a bug that only shows with existing artifacts, recording a UI/CLI demo that needs content on screen, smoke-testing a new endpoint
tools
--- name: michel-cli-demo-recorder description: Produce proof-of-execution demos of the Packmind CLI (`packmind-cli`) as static terminal-styled SVG images (colors and formatting preserved exactly), for embedding in a GitHub PR. Use this whenever a dev task touches the CLI — new command, changed output, new flag, bug fix in terminal rendering — and the PR would benefit from showing the tool actually running. Trigger it when the user says "record a CLI demo", "show the command output", "add a term