terminal-screenshot
- Repo stars 1,187
- Forks 185
- Author updated Jun 14, 2026, 10:01 AM
- Author repo claude-code-skills
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @daymade · no license declared
- Token usage
- Lean
- Setup complexity
- Guided setup
- External API key
- Not required
- Operating systems
- macOS
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Shell exec
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools，默认拥有全部工具权限。
---
name: terminal-screenshot
description: > Render the colored output of a terminal command into a PNG image, then read that image to judg…
category: other
runtime: no special runtime
---
# terminal-screenshot output preview
## PART A: Task fit
- Use case: > Render the colored output of a terminal command into a PNG image, then read that image to judge the result visually. When a command's output arrives as a tool result, Claude sees plain text plus raw escape codes like \x1b[48;2;92;30;34m — not the rendered colors. That makes it runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Why this exists / The method: capture, then render / Step 1 — Capture full-fidelity ANSI to a file” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “> Render the colored output of a terminal command into a PNG image, then read that image to judge the result visually. When a command's output arrives as a tool result, Claude sees plain text plus raw escape codes like \x1b[48;2;92;30;34m — not the rendered colors. That makes it runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Why this exists / The method: capture, then render / Step 1 — Capture full-fidelity ANSI to a file” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, run shell commands, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, run shell commands, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options.The source mentions slash commands such as `/tmp`, `/dev`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, run shell commands, write/modify files.
Start with a small task and check whether the result follows “Why this exists / The method: capture, then render / Step 1 — Capture full-fidelity ANSI to a file”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: terminal-screenshot
description: > Render the colored output of a terminal command into a PNG image, then read that image to judg…
category: other
source: daymade/claude-code-skills
---
# terminal-screenshot
## When to use
- > Render the colored output of a terminal command into a PNG image, then read that image to judge the result visually.…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Why this exists / The method: capture, then render / Step 1 — Capture full-fidelity ANSI to a file” and keep inference separate from source facts.
- read files, run shell commands, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies.The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "terminal-screenshot" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Why this exists / The method: capture, then render / Step 1 — Capture full-fidelity ANSI to a file
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, run shell commands, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
}Terminal Screenshot
Render the colored output of a terminal command into a PNG image, then read that image to judge the result visually.
Why this exists
When a command's output arrives as a tool result, Claude sees plain text plus raw
escape codes like \x1b[48;2;92;30;34m — not the rendered colors. That makes it
impossible to honestly answer "is the diff's add/remove contrast strong enough?"
or "did this theme come out too dark?". Reading hex values is guessing. This skill
turns the output into an image so the judgement is based on what a human would
actually see on screen.
The method: capture, then render
Two separate steps. Keep them separate — that separation is the whole trick.
Step 1 — Capture full-fidelity ANSI to a file
Most CLIs drop or downgrade colors when they detect they're not writing to a
real terminal (a pipe or a child process). Force full coloring and save to a
.ansi file. The exact flag depends on the tool — recipes below.
The single most important rule: never let the renderer run the command for you.
freeze --execute "git diff | delta" looks convenient but produces a degraded
result — delta (and lazygit, and anything that probes terminal capabilities) runs
inside freeze's child pty, detects a reduced environment, and silently drops its
background blocks, line-number column, and header box. Capture in a normal shell
first, render second.
Step 2 — Render the ANSI file to PNG, then read it
Use the bundled wrapper, which prefers freeze and falls back to a stdlib
renderer + headless Chrome:
scripts/render_ansi.sh <input.ansi> <output.png> [background_hex]Then read the PNG with the Read tool and judge the colors.
Background color must match the real terminal, or a dark theme verified on a white page looks wrong. On macOS with Ghostty:
ghostty +show-config --default | grep '^background' # e.g. 282c34 (the default)Pass it as #282c34. If unknown, a dark terminal is usually near #1d1f21–#282c34.
Capture recipes per tool
Pick a --width close to the real terminal (≈100–120) so wrapping matches.
| Tool | Capture command (writes full-color ANSI) |
|---|---|
| delta (git diff) | git --no-pager diff | delta --dark --line-numbers --width=110 > /tmp/x.ansi |
| git diff (native) | git -c color.ui=always --no-pager diff > /tmp/x.ansi |
| bat | bat --color=always --style=numbers <file> > /tmp/x.ansi |
| eza | eza -la --color=always --icons > /tmp/x.ansi |
| ls (GNU) | ls -la --color=always > /tmp/x.ansi |
| ls (macOS/BSD) | CLICOLOR_FORCE=1 ls -laG > /tmp/x.ansi |
| ripgrep | rg --color=always 'pattern' <path> > /tmp/x.ansi |
| anything else | CLICOLOR_FORCE=1 <cmd> > /tmp/x.ansi or <cmd> --color=always, or wrap in a real pty: script -q /dev/null <cmd> |
Note delta always emits its configured colors even to a file, so the only trap
for delta is Step 1's rule (don't render it via freeze --execute).
Full example: verify a delta color change
# after editing [delta] colors in gitconfig, in any repo with a diff:
git --no-pager diff | delta --dark --line-numbers --width=110 > /tmp/diff.ansi
scripts/render_ansi.sh /tmp/diff.ansi /tmp/diff.png "#282c34"
# then: Read /tmp/diff.png and judge whether add/remove contrast is clearTUI programs (lazygit, htop, top) — out of scope
Full-screen TUIs paint with cursor positioning, not a linear ANSI stream, so they
can't be captured this way. To check a TUI's colors, verify the underlying piece
in isolation — e.g. for lazygit's diff, render git diff | delta as above (lazygit
calls the same delta config). For a true TUI screenshot, run it in a real terminal
and capture the screen (a screencapture/computer-use task), not this skill.
Installing freeze (the preferred renderer)
freeze is charmbracelet/freeze — it
renders ANSI to PNG/SVG/WebP with faithful background blocks and nice chrome.
Do not run brew install freeze — that installs an unrelated GUI app of the
same name (a cask). The CLI lives in charmbracelet's tap or via go install:
# Option A — Homebrew tap (needs GitHub reachable)
brew install charmbracelet/tap/freeze
# Option B — go install (works behind a firewall via a Go module mirror)
GOPROXY=https://goproxy.cn,direct GOSUMDB=off \
go install github.com/charmbracelet/freeze@latest
# binary lands in "$(go env GOPATH)/bin/freeze"GOSUMDB=off is needed when the checksum database (sum.golang.org) is
unreachable and go install hangs on "verifying module ... 504".
If freeze can't be installed, the wrapper automatically falls back to the bundled
scripts/ansi2html.py (stdlib only) + headless Chrome — no extra dependency
beyond a Chrome install. The fallback uses a fixed window size; widen
--window-size in render_ansi.sh if output is clipped.
Bundled scripts
scripts/render_ansi.sh— render a captured.ansifile to PNG (freeze, else Chrome fallback). This is the entry point; call it after Step 1.scripts/ansi2html.py— stdlib ANSI→HTML converter used by the fallback path. Handles 24-bit truecolor, 256-color, bold, and resets, preserving background color blocks (the part naive renderers drop).
Common pitfalls
- Letting the renderer run the command (
freeze --execute "delta …") → degraded output. Capture in a normal shell first, render the file second. - Non-TTY strips color → force it (
--color=always/CLICOLOR_FORCE=1/script -q /dev/null). - Wrong background color → a dark CLI theme rendered on a white page misjudges contrast. Use the real terminal background.
- Light/dark mismatch → if the terminal is dark, the CLI's colors must be its
dark variant. Verifying a
light=trueconfig against a dark terminal shows inverted, hard-to-read colors (and is itself the bug, not the renderer's fault). brew install freezeinstalls the wrong (GUI cask) tool — use the tap orgo install.
Decide Fit First
Design Intent
How To Use It
Boundaries And Review