home / skills / 0xbigboss / claude-code / tiltup

tiltup skill

/.claude/skills/tiltup

This skill helps start Tilt in tmux, monitor bootstrap, and fix Tiltfile issues by addressing root config rather than symptoms.

npx playbooks add skill 0xbigboss/claude-code --skill tiltup

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
4.2 KB
---
name: tiltup
description: Start Tilt dev environment in tmux, monitor bootstrap to healthy state, fix Tiltfile bugs without hard-coding or fallbacks. Use when starting tilt, debugging Tiltfile errors, or bootstrapping a dev environment.
---

# Tilt Up

## Principles (Always Active)

These apply whenever working with Tiltfiles, Tilt errors, or dev environment bootstrap:

### Fix the Tiltfile, Not the Symptoms

- **Fix the source config directly** - Tiltfile, Dockerfile, k8s manifest, or helm values
- **Never add shell workarounds** - no wrapper scripts, no `|| true`, no `try/except pass`
- **Never hard-code** ports, paths, hostnames, image tags, or container names that should be dynamic
- **Never add fallbacks** that mask the real error - if a resource fails, the failure must be visible
- **Never add sleep/retry loops** for flaky dependencies - fix dependency ordering via `resource_deps()` or `k8s_resource(deps=)`
- **Never add polling** for readiness that Tilt already handles - use `k8s_resource(readiness_probe=)` or probe configs

### Express Dependencies Declaratively

- Port conflicts: fix the port allocation source, don't pick a different port
- Resource ordering: use `resource_deps()`, not sequential startup scripts
- Env vars: use `silo.toml` or gen-env output, not inline defaults
- Image availability: use `image_deps` or `deps`, not sleep-until-ready

### Tilt Live-Reloads

After editing a Tiltfile, Tilt picks up changes automatically. **Never restart `tilt up`** for:
- Tiltfile edits
- Source code changes
- Kubernetes manifest updates

Restart only for: Tilt version upgrades, port/host config changes, crashes, cluster context switches.

## Workflow (When Explicitly Starting Tilt)

### Step 1: Assess Current State

1. Check if tilt is already running:
   ```bash
   SESSION=$(basename $(git rev-parse --show-toplevel 2>/dev/null) || basename $PWD)
   tmux list-windows -t "$SESSION" -F '#{window_name}' 2>/dev/null | grep -q "^tilt$"
   ```
   If running, check health via `tilt get uiresources -o json` and skip to Step 3.

2. Check for required env files (`.localnet.env`, `.env.local`, `silo.toml`):
   - If `silo.toml` exists, use `silo up` path
   - If gen-env script exists, run it first
   - If neither, check project README for bootstrap instructions

3. Check for k3d cluster or Docker prerequisites.

### Step 2: Start Tilt in tmux

Follow the `tmux` skill patterns:
```bash
SESSION=$(basename $(git rev-parse --show-toplevel 2>/dev/null) || basename $PWD)

if ! tmux has-session -t "$SESSION" 2>/dev/null; then
  tmux new-session -d -s "$SESSION" -n tilt
  tmux send-keys -t "$SESSION:tilt" 'tilt up' Enter
elif ! tmux list-windows -t "$SESSION" -F '#{window_name}' | grep -q "^tilt$"; then
  tmux new-window -t "$SESSION" -n tilt
  tmux send-keys -t "$SESSION:tilt" 'tilt up' Enter
else
  echo "Tilt window already exists in session: $SESSION"
fi
```

For silo projects: `silo up` instead of `tilt up`.

### Step 3: Monitor Bootstrap

Poll for convergence:
1. Wait 10s for initial resource registration
2. Poll every 15s, up to 20 iterations:
   ```bash
   tilt get uiresources -o json | jq -r '.items[] | select(.status.runtimeStatus == "error" or .status.updateStatus == "error" or .status.updateStatus == "pending") | "\(.metadata.name): runtime=\(.status.runtimeStatus) update=\(.status.updateStatus)"'
   ```
3. Track resources: `pending` -> `in_progress` -> `ok`
4. Success: all resources reach `runtime=ok, update=ok` (or `not_applicable`)
5. If resources stabilize in `error`, proceed to Step 4

### Step 4: Diagnose and Fix Errors

For each resource in error state:
1. Read logs: `tilt logs <resource> --since 2m`
2. Read the Tiltfile and relevant k8s manifests
3. Identify root cause in the config (not the running process)
4. Apply fix following the Principles above
5. Tilt live-reloads - re-poll status to verify

After 3 fix iterations on the same resource without progress:
- Report the error with full logs
- Identify whether it's a Tiltfile bug, upstream dependency, or infrastructure problem
- Do not silently skip or disable the resource

### Step 5: Report

```
## Tilt Status: <healthy|degraded|errored>

**Resources**: X/Y ok
**Session**: tmux $SESSION:tilt

### Errors (if any)
- <resource>: <root cause> — <what was fixed or what remains>
```

Overview

This skill starts a Tilt development environment inside a tmux session, monitors bootstrap until the system is healthy, and guides iterative fixes to Tiltfile and related config errors without masking root causes. It enforces principles that avoid hard-coded fallbacks, sleep loops, or wrapper workarounds so failures remain visible and are fixed at the source.

How this skill works

The skill checks for an existing tmux session and required env/bootstrap files, then launches tilt (or silo up for silo projects) in a dedicated tmux window. It polls Tilt UI resources for convergence, classifying resource states and watching for runtime or update errors. When an error is detected, it collects recent logs, inspects Tiltfile and manifests, and recommends config-level fixes. After edits, Tilt live-reloads and the skill re-polls to verify progress.

When to use it

  • Starting a project dev environment with Tilt and ensuring clean bootstrap
  • Debugging Tiltfile errors or resource startup failures
  • Enforcing config-first fixes instead of adding runtime workarounds
  • Automating Tilt startup inside tmux for consistent developer workflows
  • Monitoring resource convergence to detect faulty manifests or configs

Best practices

  • Fix the source config (Tiltfile, Dockerfile, k8s manifests, helm values) instead of adding shell workarounds
  • Avoid hard-coding ports, image tags, paths, hostnames, or adding silent fallbacks
  • Express ordering and dependencies declaratively with resource_deps() and image_deps
  • Use Tilt readiness settings and probes rather than custom polling or sleep loops
  • Edit Tiltfile in-place and rely on Tilt live-reload; restart tilt only for version or cluster changes

Example use cases

  • Open a project and launch tilt in tmux so the team has a reproducible dev window
  • Detect a stuck resource that reports pending or error and trace it to a missing env var in silo.toml
  • Resolve a port conflict by fixing the service port source rather than picking a different port
  • Iteratively fix a Tiltfile binding or manifest bug and confirm resource convergence without restarting tilt
  • Run tilt up in CI-like developer setups where tmux keeps the process attached and logs accessible

FAQ

What if tilt is already running?

The skill detects an existing tmux tilt window, checks resource health via tilt get uiresources, and skips relaunch if healthy.

When should I restart tilt manually?

Restart only for Tilt version upgrades, port/host configuration changes, crashes, or cluster context switches—never for normal Tiltfile or code edits.