From rvst
Discipline for confirming an RVST rendering / layout / event change actually works. Use before marking any RVST task complete or before committing a render-affecting change.
How this skill is triggered — by the user, by Claude, or both
Slash command
/rvst:rvst-validationThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**You cannot see the window. Every claim about visual or layout behavior
You cannot see the window. Every claim about visual or layout behavior has to be backed by a tool output. No eyeball, no vibe check, no "looks good."
This document exists because the failure mode is real and repeats: agent makes a change, launches the app, sees "something," declares victory, moves on. Meanwhile the user sees a white screen, or text overflowing, or a button that doesn't actually click. The discipline below prevents that.
Every RVST change should clear as many of these as apply:
Does the logic compile and its pure behavior round-trip? For parsers,
converters, op handlers — this is where drift gets caught cheapest.
Run: cargo test --release
--snapshot / --dump)Does the resolved DOM + layout look right? For layout-sized changes,
this is the strongest non-interactive signal.
Run: target/blitz/release/<bin> --snapshot app.js app.css | jq ...
--test + assertions)Does the interaction produce the expected state change? Click a button,
dispatch an event, verify the DOM or a JS global updated.
Run: command pipeline into --test
User launches the app and confirms it looks right. This is NOT sufficient on its own — the user doesn't see what you think you changed; they see whatever happened after. Use it to confirm after 1–3 pass, not to skip them.
Every non-trivial RVST change follows these five steps. Skip any and you are guessing.
Step 1 — HYPOTHESIS
Write down, in words, what measurable thing will be different after the
change. Example: "Node #95 will have height >= 300px (currently 0)."
Step 2 — BASELINE
Run the tool that measures the thing. Save output.
Example: `--dump | grep 'node-95'` → "420x0"
Step 3 — CHANGE
Make the smallest possible code change. One file ideally.
Step 4 — REMEASURE
Rerun the same tool on the rebuilt binary. Compare to baseline.
Example: "420x362" — hypothesis confirmed.
Step 5 — COMMIT or ITERATE
If confirmed: commit with the hypothesis/measurement in the message.
If not: the hypothesis was wrong — update your understanding, don't
keep fiddling.
When the fix concerns layout or computed styles, the windowed app is
the least informative surface. You can't inspect computed boxes. You
can't compare to the prior state. Use --dump or --snapshot.
"Seems" is not a measurement. If the baseline was "canvas is 0px tall" and you can't produce a tool output showing "canvas is 362px tall," you haven't confirmed the change.
Gating off a code path is a workaround, not a fix. If you have to do it (pre-existing bug, out of scope), file a beads issue, leave a comment that says "gated off because , tracked in ," and don't describe it as "fixed."
An eprintln! firing means the Rust code ran. It does not mean the
Svelte handler got called, the DOM mutated, the paint surface updated,
or the user would see the change. Confirm downstream via --test + diff.
It almost certainly does, or can be extended in 10 lines. Check
rvst-cli/SKILL.md first; test_harness.rs is ~500 lines and easy to add to.
Some cases only make sense in a real window:
For those: ask the user to launch and report back. Do not guess.
If an RVST change produces unexpected behavior:
--dump and --snapshot both — layout
(This is a real bug we hit during HMR work. Shipped as the fix pattern.)
<canvas> elements with no intrinsic size inside a
flex column should resolve to parent height via height:100%.--dump showed node #103 as <div> 420×0 — not canvas,
and zero height.<canvas> was being mapped to
NodeType::View → rendered as <div> by the bridge. Fix: add
NodeType::Canvas.<canvas> now. Still 420×0.replaced_measure_function was doing
aspect_ratio = 0 / 0 = NaN and propagating it into the declared
size, zeroing the height.--dump and --ascii.None of those steps involved opening a window. Every hypothesis was confirmed or disproven against a tool output.
rvst-cli/SKILL.md — every --test command, every flag, every canonical
workflow.
Guides creation, editing, and verification of skills for AI coding agents using test-driven development with subagent scenarios. Use when authoring or debugging skills.
npx claudepluginhub shinyobjectz-sh/rvst --plugin rvst