菜单
Use this skill when working on terminal UI rendering, interactive CLI prompts, ANSI color output, terminal screenshots, Bubble Tea/Lip Gloss/Huh/Glamour, curses-style apps, or CLI tests that depend on TTY behavior.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when starting feature work that needs isolation from current workspace, before executing implementation plans, or when reviewing an existing branch (e.g. a PR) without switching away from the current branch. It creates isolated git worktrees under `.worktrees/`.
Use this skill when you're working with golang code.
Use whenever asked to create GitHub Pull Request.
Use when writing, rewriting, or updating a pull request description. Use this skill's explicit PR template unless the user provides a different template for the current task, keep the result concise and human-readable, explain why the change exists, and ask the user for motivation before updating the PR when the user has not explicitly provided it.
Use this skill whenever writing, editing, reviewing, or deciding whether to add code comments, docstrings, inline comments, or internal function documentation in any programming language. Use it even when the task only mentions "comments", "docs in code", "docstrings", "document this function", or "explain this helper".
Use this skill whenever you need to write or rewrite technical documentation: README sections, runbooks, design notes, API docs, onboarding docs, troubleshooting guides, or other prose documentation outside source code. Use it when the documentation must be both technically correct and easy to read, especially if the draft is becoming vague, academic, or hard to scan.
| name | tui-development |
| description | Use this skill when working on terminal UI rendering, interactive CLI prompts, ANSI color output, terminal screenshots, Bubble Tea/Lip Gloss/Huh/Glamour, curses-style apps, or CLI tests that depend on TTY behavior. |
Work from the rendered terminal, not from assumptions. ANSI output, wrapping, contrast, focus, and prompt behavior must be checked in a real TTY when they matter to the task.
Keep preview and screenshot terminals on the same Hyprland workspace as the agent terminal. Record the workspace before any command that can change focus.
Use hyprctl activewindow -j or hyprctl activeworkspace -j to identify the
current workspace.
Launch the test terminal with a Hyprland exec rule:
hyprctl dispatch exec "[workspace ${workspace_id} silent] wezterm ..."
Use a unique class or title for the test terminal.
Prefer the existing WezTerm screenshot flow over grim:
if the environment exposes a WezTerm terminal screenshot command or helper, use
that first because it captures terminal content and theme directly.
Use grim -g only when the compositor window, geometry, or non-terminal pixels
are part of what needs review, or when no terminal screenshot helper is
available.
If the workspace cannot be determined, stop and report the exact hyprctl
error.
Do not silently open test terminals on another workspace.
Check only the states relevant to the change. Common states:
For readability, verify:
Avoid Faint unless screenshots prove it works in both dark and light themes.
Use semantic tests for behavior:
Use screenshots for human review of contrast and layout. Do not make image comparison the default automated assertion unless the terminal, font, palette, size, renderer, and OS are pinned.
For interactive CLI tests, use a PTY when TTY detection changes behavior.
Set fixed TERM, width, and color mode.
Drive keys explicitly.
Before handing work back, report: