>Turing completeness becomes a liability. An agent-authored script can do anything including things the agent didn't realize were dangerous. subprocess.run, arbitrary network calls, file writes. None of these are gated. The blast radius of a buggy agent-authored script is the whole host.
This always turns out to be a terribe idea. And it couldn't be a worse appoach for LLMs. Hamstringing them isn't going to help.
PHP was a templating language, and for all its flaws none of its weakness had to do with being bad at templating. But then people got it in their heads that they wanted to separate programmers from designers, so it takes twice the amount of people to do anything plus all the coordination overhead, so they invented hamstrung templating languages like Smarty embedded within a poorly designed programming language like PHP that was still ok for templating, ending up with a terrible hacky poorly defined incoherent templating language that was useless to programmers. And then the designers needed variables, macros, conditionals, loops, functions, and they hacked back in half assed even worse designed programming language features. Greenspun's Tenth Rule on steroids struck like a swarm of locusts sent by God to smite the sinners.
That should be pretty obvious. How about new programming languages for human beings to use? No reason not to make more of those. But this discussion is about a programming language designed for LLMs to use, not humans. The world doesn't need any more of those.
Design programming languages for humans first. If they're good enough to catch on, and people write lots of code in them, ask and answer lots of questions about them, write tutorial and have hacker news discussions about them, then they will naturally and eventually end up in the training data, and the models will know about them. Problem solved.
It's ridiculous and costly to design a language for LLMs but not humans to use, and then necessarily and repeatedly insert the entire language definition and examples into every single prompt, instead of building it into the model. It's a tragic waste of electricity and money, and has a huge carbon footprint. Why isn't this obvious?
Edit: sure, but there are so many other good reasons not to participate in shitcoin scams. Take some of your shitcoins and pay an open source developer to fix it in upstream Chrome, so everybody benefits.
1. How a this better than just using any other script language?
2. Inventing a new language complicates large models ability to generate such scrips compared to a well-known language. Did you find it to be a problem? How did you mitigate?
3. The AI is showing. :) I had the similar discussion with ChapGPT and some phrasing is near the same. Not a dig, just a funny observation.
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.
It’s not clear from you answer if we’re on the same page. Your options are allow the worker agent run wild or constrain it with a rigid guidance. Skillscript can serve dual purpose - constrain the workflow to make it more observable and constrain elemental parts to make them more directional. Apologies if that makes no sense - the AI red shift (expanding universe) makes it very hard to communicate.
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.
It seems like you’re dramatically overcomplicating what could be a 2 bash scripts and a single LLM call. Natural language and LLMs are great for searching the problem space to find a solution, once you find the solution, shrink the stochastic parts (the MD saying “check GitHub” or whatever) and grow the deterministic parts (a bash script) as much as possible.
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.
> The runtime holds the credential and only lets it through the skillscript I approved.
What about skillscript is unique that couldn't be done with bash or python as a permissioned tool? (Trying to understand where you see the difference.)
---
My original impression from the repo was that the language/toolkit is overengineered, but then I saw on the website that the intention is for the agents to write their own tools. That helps explain some of the complexity.
I think the rest of the perceived complexity is the over-explaining in the README.
I don't think anyone's going to really engage with all of that so you might have better luck chopping it down 80% to only highlight the stuff that matters.
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?
Re: difference -- Ok, I think I understand. Ultimately, we need a "permissions" layer and you've built a solve for that.
Re: README -- I can't recall a specific repo with one off the top of my head so took a stab at editing yours[1] instead of hunting around. It's not perfect -- I'd want to trim the bullet lists further, for example -- but is much more scannable in my opinion.
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.
I'm biased since I built a dbt[1] inspired utility[2] that turns markdown into a runnable DAG, but I think a new language is the wrong abstraction.
In a time where people are reading less and less code, introducing a new surface area -- that you don't have a good feel for -- to handle orchestration feels risky.
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.
So the real benefit is succinctness and readability... would be nice to have a comparison against other scripting languages or plain text, to prove better performance or accuracy.
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.
34 comments
[ 3.5 ms ] story [ 51.5 ms ] threadThis always turns out to be a terribe idea. And it couldn't be a worse appoach for LLMs. Hamstringing them isn't going to help.
PHP was a templating language, and for all its flaws none of its weakness had to do with being bad at templating. But then people got it in their heads that they wanted to separate programmers from designers, so it takes twice the amount of people to do anything plus all the coordination overhead, so they invented hamstrung templating languages like Smarty embedded within a poorly designed programming language like PHP that was still ok for templating, ending up with a terrible hacky poorly defined incoherent templating language that was useless to programmers. And then the designers needed variables, macros, conditionals, loops, functions, and they hacked back in half assed even worse designed programming language features. Greenspun's Tenth Rule on steroids struck like a swarm of locusts sent by God to smite the sinners.
https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
>Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
Do you propose just ask AI to generate orchestration in Python?
Design programming languages for humans first. If they're good enough to catch on, and people write lots of code in them, ask and answer lots of questions about them, write tutorial and have hacker news discussions about them, then they will naturally and eventually end up in the training data, and the models will know about them. Problem solved.
It's ridiculous and costly to design a language for LLMs but not humans to use, and then necessarily and repeatedly insert the entire language definition and examples into every single prompt, instead of building it into the model. It's a tragic waste of electricity and money, and has a huge carbon footprint. Why isn't this obvious?
Edit: sure, but there are so many other good reasons not to participate in shitcoin scams. Take some of your shitcoins and pay an open source developer to fix it in upstream Chrome, so everybody benefits.
2. Inventing a new language complicates large models ability to generate such scrips compared to a well-known language. Did you find it to be a problem? How did you mitigate?
3. The AI is showing. :) I had the similar discussion with ChapGPT and some phrasing is near the same. Not a dig, just a funny observation.
"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.
I was procrastinating on that, thanks!
> the recursive nature
It’s not clear from you answer if we’re on the same page. Your options are allow the worker agent run wild or constrain it with a rigid guidance. Skillscript can serve dual purpose - constrain the workflow to make it more observable and constrain elemental parts to make them more directional. Apologies if that makes no sense - the AI red shift (expanding universe) makes it very hard to communicate.
I expect, in general, agents to be writing automation for non-programmers to approve which is another case for why not bash or python.
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.
What about skillscript is unique that couldn't be done with bash or python as a permissioned tool? (Trying to understand where you see the difference.)
---
My original impression from the repo was that the language/toolkit is overengineered, but then I saw on the website that the intention is for the agents to write their own tools. That helps explain some of the complexity.
I think the rest of the perceived complexity is the over-explaining in the README.
I don't think anyone's going to really engage with all of that so you might have better luck chopping it down 80% to only highlight the stuff that matters.
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?
Re: README -- I can't recall a specific repo with one off the top of my head so took a stab at editing yours[1] instead of hunting around. It's not perfect -- I'd want to trim the bullet lists further, for example -- but is much more scannable in my opinion.
---
[1] https://gist.github.com/thedatadavis/fbbe556348eb43731659456...
In a time where people are reading less and less code, introducing a new surface area -- that you don't have a good feel for -- to handle orchestration feels risky.
---
[1] https://github.com/dbt-labs/dbt-core
[2] https://github.com/pdthq/pdt
"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.
A comparison would be useful. No published benchmark yet, but that's fair to ask for, and probably the next thing worth putting out.
https://en.wikipedia.org/wiki/Cadence_SKILL
I thought I see Cadence Skill here on HN.