Michel CLI Demo Recorder

Recipe

1. Build the CLI first. This repo's CLI runs from dist/, so build it with npm run packmind-cli:build. It produces dist/apps/cli/main.cjs, which you then run with node dist/apps/cli/main.cjs. A demo of stale dist/ proves nothing about your change.
2. Set the edition. Resolve it from the git remote — export PACKMIND_EDITION="$(bash scripts/michel/resolve-edition.sh)" (oss for the OSS repo, proprietary for packmind-proprietary) — or the CLI may behave differently than expected.
3. Start anything the CLI talks to. Commands that hit the Packmind API (login, whoami, standards/commands/skills pulls, playbook) need the local stack up, or they only print the error/unauthenticated path. If you want populated, colorful output, bring the stack up and confirm it's serving before recording — see the michel-run-local-dev-stack skill (docker compose up -d). Local-only commands (--help, --version, lint, diff, config) need no server. If the point of the demo is the error message, skip the server deliberately.
4. Pick representative commands. Choose the invocations that show off the change. Good defaults: the headline command (populated output), --help, and any new/changed flag. One demo per invocation — small focused images beat one giant scroll.
5. Render each with the command above, writing into a stable folder (docs/cli-demos/ is a good home; create it). Each render produces both the .svg master and the .png you'll embed.
6. Verify (next section) before trusting the image.
7. Embed in the PR (section after).
8. Clean up any background stack you started (docker compose down — see the michel-run-local-dev-stack skill).

Verify before you commit

Verify by content first, then by eye:

• Read the --text-out sidecar (primary gate). It's the exact text that got captured, ANSI stripped. Confirm it shows what your change should produce — right rows, right counts, the new flag's effect, aligned columns. If the sidecar is empty or shows an error you didn't intend, the demo is wrong regardless of how the image looks.
• Read the .png (every host). The rasterizer that produces the PNG also makes it directly viewable — Read the .png to confirm colors, bold/dim, and alignment look right. This works on the Linux worker now (the image bakes in librsvg2-bin), not just macOS.

A demo that captured the wrong state (server down, stale build, not logged in, empty DB) is worse than no demo — it misleads the reviewer. Treat the sidecar as a required gate.

Embed in the PR

Commit the PNG (and the .svg master + optional .txt) into the repo on the PR's branch, then embed the PNG by absolute /raw/ URL in the PR body — never the SVG (it renders broken). Relative paths and /blob/ URLs do not render in a PR description either; use https://github.com/<org>/<repo>/raw/<branch-or-commit-sha>/<path> (pin to the commit sha for a stable image). Directly under the image, add a short What the demo shows: bullet list — the written scenario — so a reviewer who can't or won't open the image still understands what was run and what it proves:

## CLI demo

![packmind-cli standards list](https://github.com/PackmindHub/packmind/raw/<commit-sha>/docs/cli-demos/standards-list.png)

**What the demo shows:**

- Run `packmind-cli standards list` against a seeded org
- Output lists the 3 active standards with their rule counts, colored by status
- Confirms the new `--status active` flag narrows the list to active standards only

<details><summary>Plain text</summary>

```text
<paste docs/cli-demos/standards-list.txt here, or link it>
```

</details>
```

The What the demo shows: bullets follow the same rules as the UI demo scenario: synthetic, essentials only (what command runs → what the output proves), one line per bullet, readable without opening the image. The plain-text <details> block is a courtesy fallback for anyone whose viewer won't render the image, and it's searchable/diff-able in a way an image isn't.

What "good" looks like

• The output shown is the real output of your changed CLI, against a realistic state — verified via the text sidecar.
• Colors, bold, dim, and column alignment match a real terminal (the converter preserves SGR: 16-color, 256-color, truecolor, bold, dim, italic, underline).
• The prompt line shows the friendly packmind-cli … form (via --prompt-cmd) — that's how an installed user invokes it — while the command actually executed under the PTY is the repo's node dist/apps/cli/main.cjs ….
• One tight demo per invocation (SVG master + PNG); a few KB each.
• The PNG is embedded in the PR (renders on GitHub); the SVG is kept as the crisp source.
• For a multi-step change, a small set of demos (headline command + the new flag + an error/edge case) tells the whole story.

Bundled files

• scripts/render-cli-demo.mjs — the whole pipeline: PTY capture (OS-aware) → ANSI/SGR parse → terminal-styled SVG → PNG rasterization (rsvg-convert, with a macOS qlmanage fallback), plus an optional plain-text sidecar. No npm dependencies; PNG needs rsvg-convert (librsvg2-bin) on the host.