Menu
Use when editing rendered UI, dashboard, chart, or any visual artifact (Grafana, Terraform-generated panels, frontend components, plot output) - blocks declaring "done" without an external verification artifact.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | verify-ui-changes |
| description | Use when editing rendered UI, dashboard, chart, or any visual artifact (Grafana, Terraform-generated panels, frontend components, plot output) - blocks declaring "done" without an external verification artifact. |
In prior sessions the same pattern repeated 20+ times: agent edited a chart / dashboard / orderbook view, declared it fixed, the user came back with "still not displaying / now shows No Data / repeated columns / still wrong". The agent could not see the rendered output, so it kept guessing.
*.tsx, *.jsx, *.vue, *.svelte, dashboard*.tf,
panel*.tf, plot/chart code, index.html, or any file that produces a
visual artifact.Before declaring a visual change done, produce a verification artifact and attach or describe it. Pick the cheapest applicable option:
| Stack | Verification |
|---|---|
| Web frontend | npm run dev, hit the page, screenshot OR DOM snapshot (document.querySelector(...).outerHTML) |
| Rust plots (plotters/charming) | Run the example, list the output PNG, describe what it should contain |
| Terraform/Grafana | terraform plan then describe the resulting panel JSON or take a screenshot from the Grafana URL |
| TUI/CLI | Run with sample input, capture the rendered output |
| Tests pre-existing | Run the visual-regression / snapshot test |
If no artifact is achievable in the current environment, say so explicitly: "I edited X but cannot verify the render from here - please confirm the visual is correct before merging." Do not declare the task done.
If you are about to write "this should now display correctly" without having seen the actual output: stop, run the thing, capture the artifact, then report.
Use when reviewing a completed implementation holistically - a finished branch, a completed plan step, or a diff before PR. Reviews every changed line against the implementation plan (if one exists) and high engineering standards across seven dimensions, verifies tests by deliberately breaking crucial code, and emits severity-classified findings with a PASS/FAIL verdict.
Use when performing a holistic code review of an implementation - routes to codex:rescue or falls back to a direct subagent, both running the house-style:holistic-review skill
ALWAYS use before any implementation work, review, or planning: designing, writing, editing, refactoring, debugging, reviewing, or generating source code, tests, scripts, config-as-code, or behavior-affecting files. This is a baseline engineering skill and should be invoked even when a more specific language, framework, testing, or database skill also applies.
Use when asked to write, draft, file, or open a GitHub issue - mandates exploring the relevant code to understand the whole problem space, reasoning any proposed solution, and structuring the issue with summary, what/why, references, nuances, open questions, and acceptance criteria. Adds professionalism and no-sensitive-info discipline for public repos.
Use when creating, editing, triaging, or cleaning up GitHub issues - a mechanical pass that verifies the title is accurate and current, labels/assignees/milestone are correct, and the body is valid, well-formed markdown, all via the gh CLI. Does not judge content quality.
Use when running Python, installing Python packages, creating virtualenvs, or executing Python CLI tools - mandates uv/uvx over direct python/pip/pipx/venv calls when uv is installed, and gives the drop-in command mappings