Skillscript - Declarative sandboxed language for agent workflow orchestration

Show HN: Skillscript – A declarative, sandboxed language for tool orchestration

Skillscript - Declarative sandboxed language for agent workflow orchestration

Skillscript is a specialized, declarative language designed for AI agents to author their own persistent workflows. Unlike transient reasoning or unbounded Python scripts, Skillscript provides a sandboxed, auditable environment where agents can crystallize learned procedures into safe, executable artifacts. It features a runtime, compiler, and CLI that enable the creation of composable, typed operation DAGs, ensuring that routine tasks are executed efficiently without burning expensive frontier inference. By moving the safety boundary to curated connectors and enforcing static validation, Skillscript solves the critical issues of cost, latency, and drift in autonomous agent systems.

Agents are code, and skillscript is the language they write themselves in.
  1. DenisM

    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.

    4. Consider the recursive nature of the problem you’re solving - large model updates workflow which you review each time, worker models generate plans and tool calls which you don’t review. A constrained language is useful in both cases to guide the model.

    5. This Earlier discussion can provide useful background for why this is needed. You have probably seen it, but the readers will likely appreciate. https://news.ycombinator.com/item?id=48051562

    The problem is real, Thank you for taking a stab and sharing your findings.

  2. christoff12

    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.

    ---

    [1] https://github.com/dbt-labs/dbt-core

    [2] https://github.com/pdthq/pdt

  3. twalla

    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.

  4. rffn

    There is already a tool automation language called Skill. It is used in Cadence Virtuoso (EDA tool).

    https://en.wikipedia.org/wiki/Cadence_SKILL

    I thought I see Cadence Skill here on HN.

  5. sxiong

    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.

More from this day

2026-07-12