Two Claude Code skills that don’t get enough attention. /run-skill-generator and /run . The problem they solve is boring and constant. Your agent doesn’t know how to build and launch your app. So it works it out from the repo. Every session. That’s slow, it’s inconsistent, and you pay tokens for it every time. /run-skill-generator does that discovery ONCE. How to build, how to launch, how to drive the app. Writes all of it into a per-project skill. After that /run just reads the skill and goes. Write it down once. Stop rediscovering it. Ran it against a Spring Boot app today. It produced a curl smoke script. Builds with the Gradle wrapper, kills whatever is on the port, launches the jar, waits for startup, hits seven endpoints, clean exit. Optional --keep-running so /run can leave it up and keep working. It also wrote down the stuff that’s specific to this app and not obvious. Self-signed cert on 9000 so every curl needs -sk. Form login CSRF token has to ride the same session cookie. Silent bind failure if the port’s taken. A Gradle warning that looks like a failure and isn’t. None of that is guessable. The agent would burn turns rediscovering it, or get it wrong, on every run. Now it’s in the skill. Three reasons to set this up. Tokens. The big one. No skill means the agent rebuilds the launch steps from the repo every session. /run reading one focused skill kills that spend. Lean CLAUDE.md. Run mechanics don’t belong in the file that loads every turn. The skill loads when /run needs it. Not before. Testing. Once the agent can launch and drive the app reliably, it can actually exercise it. Functionality. Deps. Security testing against the live target. You can’t test a running app if you can’t get it running first. Anyone else running a per-project run skill? Curious how you’ve structured yours. submitted by /u/lolas_tounge
Originally posted by u/lolas_tounge on r/ClaudeCode
You must log in or # to comment.