run

**Running means launching the actual app and interacting with it** - not the test suite, not an `import` of an internal function and a `console.log`. The app as a user (human or programmatic) would meet it: the CLI at its command, the server at its socket, the GUI at its window. ## First: does a project skill already cover this? A project skill that launches this app is the repo's verified path - its author already cold-started from a Linux container and committed what worked: the exact `apt-get` line, the env vars, the patches, the driver. Use it instead of rediscovering. ```bash d=$PWD; while :; do grep -Hm1 '^description:' "$d"/.claude/skills/*/SKILL.md 2>/dev/null [ -e "$d/.git" ] || [ "$d" = / ] && break d=$(dirname "$d") done ``` - **One describes launching/driving this app** -> read that SKILL.md and follow it verbatim. Don't paraphrase; don't skip the patches. - **Mega-repo, several plausible, no clear match** -> ask the user which unit to run. - **Stale** (fails on mechanics unrelated to your task) -> tell the user; offer to refresh it via `/run-skill-generator`. - **Nothing about running** -> fall back to the patterns below. ## Otherwise: match the shape, use the pattern Pick the row closest to your project. Each example walks through launch + first interaction; ignore any trailing "write the skill" section - you're using the recipe, not authoring one. | Project type | Handle | Example | |---|---|---| | CLI tool | direct invocation, exit code, std...