Install any skill in seconds. Free to start, no credit card required.
Get Started Free →Use when checking deployment health, investigating errors, reading logs, or working with Tiltfiles. Queries Tilt resource status, logs, and manages dev environments.
.claude/skills/aiskillstore-tilt/SKILL.md| Test case | Without → With | Effect | Δ tokens | Δ turns |
|---|---|---|---|---|
| case-01 | ✗→✓ | ▲ Improved | 8% | 0% |
| case-02 | ✗→✓ | ▲ Improved | 20% | 0% |
| case-03 | ✗→✓ | ▲ Improved | 6% | 0% |
| case-12 | ✗→✓ | ▲ Improved | -44% | 0% |
| case-07 | ✗→✓ | ▲ Improved | -1% | 0% |
Before investigating issues or verifying deployments, check resource health. Run errors first, separately from pending/in-progress — otherwise real failures get buried in 20+ pending lines:
bash# 1. Errors only — surface the buildHistory[0].error so you see WHY, not just THAT tilt get uiresources -o json | jq -r '.items[] | select(.status.runtimeStatus == "error" or .status.updateStatus == "error") | "\(.metadata.name): runtime=\(.status.runtimeStatus) update=\(.status.updateStatus)\n reason: \((.status.buildHistory[0].error // "(no buildHistory error; check tilt logs)") | gsub("\n"; " ") | .[0:240])"' # 2. In-progress and pending — informational; an in-progress build may flip to error any moment tilt get uiresources -o json | jq -r '.items[] | select(.status.updateStatus == "in_progress" or .status.updateStatus == "pending" or .status.runtimeStatus == "pending") | "\(.metadata.name): runtime=\(.status.runtimeStatus) update=\(.status.updateStatus)"' # 3. Docker-compose container health — MISSED by the error filter above. # An `Up (unhealthy)` compose container keeps runtimeStatus=ok/update=ok, so # queries 1-2 never flag it; the red UI badge comes from healthStatus here. tilt get uiresources -o json | jq -r '.items[] | select(.status.composeResourceInfo.healthStatus == "unhealthy") | "\(.metadata.name): compose healthStatus=unhealthy (HEALTHCHECK failing — service may still be up)"' # 4. Quick status overview tilt get uiresources -o json | jq '[.items[].status.updateStatus] | group_by(.) | map({status: .[0], count: length})'
If a resource is in_progress when you check, re-poll before declaring it healthy — it can transition straight to error with a populated buildHistory[0].error. The updateStatus field reflects only the current build attempt; the last error always lives in buildHistory[0].error even when updateStatus is none or not_applicable.
Docker-compose resources are a blind spot. Their runtimeStatus/updateStatus reflect only build/up state, NOT the container's docker HEALTHCHECK — so a probe-failing container (docker ps → Up (unhealthy)) reads runtimeStatus=ok and slips past queries 1-2, while the Tilt UI still reddens it. The authoritative signal is .status.composeResourceInfo.healthStatus (healthy / unhealthy / absent when the service has no healthcheck), which query 3 catches. These resources also have k8sResourceInfo: null (spec.type == "docker-compose"); to find why a probe fails, drop to docker: docker inspect <compose-project>-<svc> --format '{{json .State.Health}}' reads the probe's last exit code + output. A common cause is the healthcheck script invoking a CLI the image doesn't ship (e.g. curl/grpcurl removed in slimmed images) — the service is fine, the probe is broken.
When Tilt runs on a non-default port, add --port:
bashtilt get uiresources --port 37035 tilt logs <resource> --port 37035
bash# All resources with status tilt get uiresources -o json | jq '.items[] | {name: .metadata.name, runtime: .status.runtimeStatus, update: .status.updateStatus}' # Single resource detail tilt get uiresource/<name> -o json # Wait for ready tilt wait --for=condition=Ready uiresource/<name> --timeout=120s
Status values:
ok, error, pending, none, not_applicableok, error, pending, in_progress, none, not_applicablebashtilt logs <resource> tilt logs <resource> --since 5m tilt logs <resource> --tail 100 tilt logs --json # JSON Lines output
bashtilt trigger <resource> # Force update tilt up # Start tilt down # Stop and clean up
Follow zmx skill patterns — check for existing sessions, derive name from git root, use zmx run (not attach):
bashPROJECT=$(basename "$(git rev-parse --show-toplevel 2>/dev/null)" || basename "$PWD") SESSION="${PROJECT}-tilt" if zmx list --short 2>/dev/null | grep -q "^${SESSION}$"; then echo "Tilt session already exists: $SESSION" else zmx run "$SESSION" 'tilt up' echo "Started tilt in zmx session: $SESSION" fi
Tilt live-reloads automatically. Never suggest restarting tilt up for:
Restart only for: Tilt version upgrades, port/host changes, crashes, cluster context switches.
| Case | Status | Duration (ms) | Turns | Tokens | Tool calls | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Without | With | Δ | Without | With | Δ | Without | With | Δ | Without | With | Δ | ||
case-01 | fail→pass | 13,724 | 6,874 | -50% | 1 | 1 | 0% | 2,343 | 2,524 | +8% | 0 | 0 | — |
case-02 | fail→pass | 12,190 | 5,330 | -56% | 1 | 1 | 0% | 1,920 | 2,301 | +20% | 0 | 0 | — |
case-03 | fail→pass | 14,088 | 6,252 | -56% | 1 | 1 | 0% | 2,369 | 2,512 | +6% | 0 | 0 | — |
case-04 | pass→pass | 13,043 | 8,452 | -35% | 1 | 1 | 0% | 2,371 | 2,798 | +18% | 0 | 0 | — |
case-05 | pass→pass | 9,878 | 5,682 | -42% | 1 | 1 | 0% | 1,802 | 2,224 | +23% | 0 | 0 | — |
case-06 | pass→pass | 10,663 | 6,512 | -39% | 1 | 1 | 0% | 2,017 | 2,473 | +23% | 0 | 0 | — |
case-12 | fail→pass | 18,330 | 2,450 | -87% | 1 | 1 | 0% | 3,042 | 1,692 | -44% | 0 | 0 | — |
case-07 | fail→pass | 10,678 | 2,620 | -75% | 1 | 1 | 0% | 1,747 | 1,731 | -1% | 0 | 0 | — |
case-08 | fail→pass | 12,976 | 8,613 | -34% | 1 | 1 | 0% | 1,966 | 2,304 | +17% | 0 | 0 | — |
case-09 | pass→pass | 12,362 | 3,201 | -74% | 1 | 1 | 0% | 1,960 | 1,805 | -8% | 0 | 0 | — |
case-10 | pass→pass | 6,269 | 2,150 | -66% | 1 | 1 | 0% | 1,057 | 1,584 | +50% | 0 | 0 | — |
case-11 | pass→pass | 7,698 | 3,094 | -60% | 1 | 1 | 0% | 1,316 | 1,770 | +34% | 0 | 0 | — |
case-13 | fail→pass | 17,871 | 2,845 | -84% | 1 | 1 | 0% | 2,752 | 1,762 | -36% | 0 | 0 | — |
case-14 | pass→pass | 10,028 | 3,931 | -61% | 1 | 1 | 0% | 1,508 | 1,931 | +28% | 0 | 0 | — |
case-15 | pass→pass | 16,490 | 7,946 | -52% | 1 | 1 | 0% | 2,328 | 2,424 | +4% | 0 | 0 | — |
case-16 | pass→pass | 4,639 | 1,606 | -65% | 1 | 1 | 0% | 720 | 1,501 | +108% | 0 | 0 | — |
case-17 | fail→pass | 11,720 | 3,978 | -66% | 1 | 1 | 0% | 2,001 | 1,965 | -2% | 0 | 0 | — |
case-18 | pass→fail | 8,248 | 1,695 | -79% | 1 | 1 | 0% | 1,387 | 1,511 | +9% | 0 | 0 | — |
case-19 | fail→pass | 8,566 | 3,260 | -62% | 1 | 1 | 0% | 1,502 | 1,864 | +24% | 0 | 0 | — |
case-20 | fail→pass | 7,843 | 3,044 | -61% | 1 | 1 | 0% | 1,429 | 1,744 | +22% | 0 | 0 | — |
case-21 | pass→pass | 7,970 | 2,401 | -70% | 1 | 1 | 0% | 1,447 | 1,700 | +17% | 0 | 0 | — |
case-22 | fail→pass | 4,543 | 2,493 | -45% | 1 | 1 | 0% | 690 | 1,646 | +139% | 0 | 0 | — |
case-23 | fail→pass | 9,413 | 2,402 | -74% | 1 | 1 | 0% | 1,003 | 1,660 | +66% | 0 | 0 | — |
DecimalAI ran this skill against gemini-3.6-flash twice over the same eval suite — once with the skill loaded and once without — and compared the two runs case by case. 23 cases were attempted. The headline lift of +48 percentage points is the difference between those two pass rates over the 23 comparable cases. 1 case got worse with the skill loaded, and it is included in that figure.
Without the skill loaded, the model failed this case. With it loaded, the same prompt on the same model passed. This is one improved case from the latest verified run; every case, including any that regressed, is in the table above.
Other measured skills in the registry, with their headline benchmark lift.