Use when a Codewhale change needs proving in the real product, or when asked to build/install/dogfood the local binaries: stamped release build, atomic install, fresh-shell verification, and the manual QA that gates cannot cover.
73
91%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Green gates prove the code compiles and asserts. They do not prove the product works. Freezes, route contamination, focus theft, streaming cadence, and approval-flow regressions all live in the runtime, where no unit test looks. This stage puts the actual binary on your PATH and makes you use it.
Stage 4 of the loop: cw-orient → cw-slice → cw-gates → dogfood → cw-land → cw-handoff.
Gate first. Run cw-gates to the rung the change deserves. Never install an ungated build.
Build stamped. Local builds are unstamped ((dev)) since #5245, and the
installer refuses an unstamped binary on purpose — the stamp is what proves
the thing on your PATH is the thing you just built:
CODEWHALE_BUILD_SHA=$(git rev-parse HEAD) \
cargo build --release --locked -p codewhale-cli -p codewhale-tuiInstall atomically. Use the script; do not hand-copy:
scripts/release/install-dogfood.sh # defaults to target/releaseIt refuses a dirty source tree (override deliberately with
CODEWHALE_ALLOW_DIRTY_DOGFOOD=1, and then say so wherever you report the
install), verifies the binary embeds current HEAD, installs codewhale and
codew into ~/.cargo/bin and ~/.local/bin (override with
CODEWHALE_INSTALL_DIRS), re-signs ad-hoc on macOS, and verifies resolution
from a fresh login shell.
Never cp over a running binary. On Apple Silicon that poisons the
kernel's code-signature cache for the inode, and later execs hang until
reboot. The installer does tmp-copy plus atomic mv for exactly this reason.
Verify from a fresh shell, not this one. A correct target/release
binary and a stale codew on PATH is the classic false pass:
zsh -lc 'type -a codew codewhale; codew --version'The version string must contain the short HEAD SHA you just built.
Use the product. Run it in a real terminal and exercise what you changed.
crates/tui/AGENTS.md is the authority on what to look at; pick the terminal
sizes relevant to the change from 40x12, 60x16, 80x24, 100x32,
140x40. Judge motion from repeated frames, never a single screenshot, and
check it against docs/MOTION_CONTRACT.md. Remove inherited NO_COLOR,
TERM=dumb, and tmux motion overrides when they would invalidate what you
are looking at.
Scenarios worth exercising when they are in scope:
Headless surfaces, when the change touches them. codewhale exec is the
one-shot worker path; codewhale app-server is the local control/API surface.
They must agree about routing, permissions, and event states — a disagreement
is a runtime bug, not a QA note.
scripts/release/app-server-smoke.sh
codewhale exec --auto --output-format stream-json --model <model> "Reply PONG"Provider calls spend tokens. Ask before running the paid ones.
Record what you saw. Dimensions, inputs, visible state, side effects. A screenshot proves layout and color; only live observation or a recording proves motion and continuity.
cp a binary over a running one. Use install-dogfood.sh.target/dogfood/* bundles if the lane keeps them: they are
release evidence.CODEWHALE_BUILD_SHA stamp.codew --version from a fresh login shell, with the SHA visible.21282f1
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.