sshwarts

I would say you're right in that with succinctness comes constraint. And the constraint is really the point, not the brevity. It's small because it can't do arbitrary things, which is exactly what lets you read one and approve it (and for hopefully anyone to understand), and what makes it run the same way every time.

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

It makes sense. I think my response skewed things a bit. The worker can not run wild for exactly the reasons you state. Constraints of the language and the workflow are easy for a human to understand (especially a non-programmer human).

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

yea, I let it get out of control. A new leaner readme is on its way thanks in big part to christoff12.

Oh wow. Talking about going above and beyond! Thanks for this. I'll use it as a template for sure. You might have guessed, first time building in public per se. Everything else I do is pretty much for clients and C/C++ work.

What's the difference? if you're the one writing the Python and approving each script, probably little. The difference shows up when the agent writes it unattended, over and over. Skillscript can only reach the binaries and tools I allowlisted, where I allowlisted them. An agent can't escalate by writing something clever that get by me.

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?

Honestly, not far from where I started. The origin of this was "what would a Makefile look like if it built markdown skills?" You'll notice the syntax is very much makefile like.

"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.

That's a fair comment. I sorta feel you're describing my thesis, "shrink the stochastic, grow the deterministic" is the point. Where we differ, maybe, is what the deterministic part is made of.

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.

I really appreciate the comments and the encouragement.

"How <is> 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.

Is what you are seeing is the topics sidebar overlapping the text?

Thanks. I'm guessing since the docs are mintlify hosted, the CDN assets might be being blocked. I'll look and see if adding a domain sidesteps it.

I think part of the point here is that agents need to be managed. People need to learn how to manage them and be given the tools to do so. Those tools and knowledge should not come from nor be gate kept by the 'clergy' to use the writer's term.