A comparison would be useful. No published benchmark yet, but that's fair to ask for, and probably the next thing worth putting out.

I expect, in general, agents to be writing automation for non-programmers to approve which is another case for why not bash or python.

I think you're right on. I let the readme get out of hand. It became a README, changelog mash-up. Going to rewrite it, and the 80% metric is a good one. Is there an example of what you consider the perfect readme?

"new language is the wrong abstraction": I'd resist using "language" as it carries way too much weight here. Closer to your DAG than to a general purpose language.

I guess the way I look at it, if people are reading less and less code, what an agent hands me needs to be small and skimmable. The web tool helps by highlighting ops, and I even built a code to mermaid function (which honestly is there but unused right now) because the skillscripts are generally straightforward.

Skim the examples, I hope you'll see its not that different.

The problem I'm trying to solve for me is a step removed. The agent is the one writing the script, and I want it to run unattended against my systems every morning. I can't let it write and run bash. Even though my agent lives in a container (NanoClaw), I still need it to reach out to other systems. Github, my other servers, MCPs, etc.

Skillscript is how I let it reach out without holding the keys. It can invoke a skillscript that hits GitHub, but it never runs the raw command or holds the token itself. The runtime holds the credential and only lets it through the skillscript I approved.

It's fair to say a skillscript basically is your two bash scripts and an LLM call, but fenced in.

"How this better than just using any other script language?"

I wanted to make the language something built for a machine to write and a human to approve with a narrow scope and my control of what extends that. What shell commands, if any. What MCP and what tools in that MCP, and so on. If an agent generates a Python script to run unattended every morning, I feel I can't control it.

"Inventing a new language complicates large models ability to generate such scripts..."

I tried to keep it as small as possible and borrow a lot from what I knew models had seen in makefiles, YAML-ish, etc.

That was actually the question I began with. What would a make file look like if I were using it to make a classic markdown skill? Asking that question, sort of spawned the rest of it.

I tested the language against cold agents in both frontier model and local model camps to see where they had difficulty nad made changes as required. The lint approach as well as help topics from the MCP helped a lot.

"AI Showing..."

Yea there is a certain irony there. I freely admit product was written with Claude Code. I wrote the Product Requirements & Engineering Requirements and reviewed the code, so I can say I own it.

"Consider the recursive nature of the problem you’re solving..."

That framing is better than mine. When a frontier model writes a skillscript, there's not much chance of something slipping by. Over time, I've become cautiously open to the model adapting the skillscript to solve problems as they occur. Example, a skillscript runs every morning and checks github for PRs and issues. The agent when woken after the run 'noticed' an issue, fixed the script and it was ready for me to approve in the morning. Yes, that could have been done in Python, but I'd not be as confident about it.

I also really appreciate the link.

The itch started with something small. I wanted my NanoClaw agent to run my morning brief the same way every day. Check overnight tickets, summarize the deploy pipeline, flag anything urgent. Every session, it would re-figure out how to do this from scratch, drift a little, and cost tokens for what's basically a fixed procedure. I could put it in a system prompt or an MD skill file, but those are still instructions the model reads and reasons about every time. And I wanted it to run autonomously and then hand it to the model to reason over the data.

The second thing that pushed me: I wanted to use small local models for the cheap stuff. They're capable, but if you just hand them the wheel, they wander. What I wanted was a way for the frontier model (or me) to write a specific procedure and hand it to the local model to execute, not interpret. The skillscript is the program; the model is the runtime.

Skillscript is that. A skillscript is a text file with named steps, variables, conditions, and calls out to tools (MCP connectors, a local model, and shell commands from an operator allowlist). It's deliberately minimal — no eval, no arbitrary imports, no subprocess, no unbounded loops. Bounded language, limited potential for damage. Everything a skillscript can do is in the file. You read it and know.

Where it is: pre-1.0 (0.30), MCP-native, self-hosted. Rough edges I know about: first-run setup takes more steps than it should, some of the grammar is still moving, and the local model integration currently assumes Ollama. It works well enough that I use it every day, but I wouldn't necessarily call it production-ready.

- Repo: [https://github.com/sshwarts/skillscript](https://github.com/sshwarts/skillscript)

- Site: [https://skillscript.ai](https://skillscript.ai)

- Docs: [https://skillscript.mintlify.app/docs](https://skillscript.mintlify.app/docs)

- npm: `skillscript-runtime`

I'd welcome critique on two things especially: the language design (is it too small? too big? wrong shape?) and the trust model around agent-authored skills. What would you want to see before you trusted this on your own machine?

Comments URL: https://news.ycombinator.com/item?id=48881112

Points: 18

# Comments: 32