Skillscript Open Source: A New Framework for AI Agent Tool Orchestration

Yesterday, a project called Skillscript popped up on Hacker News. Its author, sshwarts, positions it outright as “a declarative sandboxed language for tool orchestration.” Within 24 hours, it climbed near the top of the front page rankings, and the comments got heated. Supporters think someone is finally taking this problem seriously, while critics ask: another DSL — why?

After going through the repo and the discussions, I think this project is worth talking about on its own. It’s neither another Dify/Coze-style visual canvas nor a Python library like LangGraph. Instead, it treats the tool-calling layer of Agents as an independent small language paired with a runtime sandbox. At this point in 2026, that angle is actually pretty important.

Why We Need “Another Language” Right Now

Over the past year or so, mainstream Agent orchestration solutions have basically followed two paths: one is Python-centric libraries like LangChain/LangGraph, and the other is drag-and-drop canvases like Dify, n8n, and Coze. The former is flexible but fragile; the latter is easy to start with but falls apart once the logic gets complex.

What really exposed the problem was Anthropic’s Claude Skills launched in October, followed later by Google’s Antigravity Agent Skills spec. The core idea behind Skills is elegant in theory: package “a capability” into a reusable module. But when people actually tried implementing it, they discovered there was no consistency in how Skills should be written internally, how tools should be chained together, or how permissions should be isolated. Some used YAML, some embedded Python directly, and some simply let the model generate shell commands on the fly.

The Skillscript author puts it bluntly in the README: current Agent tool usage essentially boils down to letting the LLM improvise code at runtime and hoping the sandbox catches anything dangerous. That’s cool in demos, but a nightmare in production — you can’t statically analyze it, can’t audit it, and can’t know ahead of deployment what external resources the orchestration will touch.

His solution is to move orchestration logic from “runtime generation” to “pre-deployment declaration.”

What the Syntax Looks Like

Judging from the examples in the repository, Skillscript syntax looks a bit like HCL (the Terraform language) with an added type system layer. A typical Skill is structured something like this:

skill "fetch_and_summarize" {
  input {
    url: string @validate(url)
  }

  capabilities {
    network.outbound = ["*.example.com"]
    fs.read = false
    fs.write = false
  }

  step fetch {
    tool: http.get
    args: { url: input.url }
    timeout: 10s
  }

  step summarize {
    tool: llm.complete
    args: {
      model: "claude-sonnet",
      prompt: "Summarize: ${fetch.body}"
    }
    depends_on: [fetch]
  }

  output: summarize.text
}

Several design decisions are worth highlighting separately.

The capabilities block is mandatory and enforced. If you want the Skill to access the network, you must explicitly whitelist domains. If you want filesystem access, you must enable it directly. If the runtime attempts anything undeclared, execution is denied immediately. This follows the same philosophy as Deno’s permission model, but it fits Agent scenarios even better — after all, LLM-generated call chains are inherently unpredictable.

Dependencies between steps are explicit. There’s no implicit “output from the previous step” convention. You must use depends_on or variable references to chain execution together. This turns the entire Skill into a DAG, making it statically analyzable, parallelizable, and visualizable before execution.

The type system is optional but encouraged. Both input and output can have types, and decorators like @validate can enforce validation rules. This is especially useful in LLM interactions — you can strictly constrain model output formats at the Skill boundary instead of just hoping the prompt works.

How the Sandbox Works

The most frequently asked question on HN was: what actually powers the sandbox?

The author’s answer is layered.

The outermost layer is process-level isolation. Each Skill runs in its own subprocess, with Linux namespaces and seccomp restricting system calls. This largely borrows from gVisor and Firecracker — nothing groundbreaking, but practical.

The middle layer is a network proxy. All outbound requests go through a sidecar, which allows or blocks traffic based on the capability whitelist. This is almost identical to the “outbound network control and sidecar credential proxying” model described in Tencent Cloud’s Skills article, suggesting the industry is converging on similar patterns.

The innermost layer is restrictions within the interpreter itself — Skillscript is not Turing complete. There are no while loops, no arbitrary recursion; control flow only supports conditional branching and bounded map/reduce operations. This is a pretty aggressive design choice. The author was challenged on it in the issues, and his response was: “If you need Turing completeness, you’re using the wrong tool. Just write Python and call the Skill from there.”

Personally, I think that stance is correct. The Agent orchestration layer shouldn’t be responsible for general-purpose computation. Its job is to reliably translate LLM intent into a controlled sequence of tool calls. Turing completeness is a bug, not a feature.

Where It Fits Compared to Existing Solutions

A quick comparison makes the positioning clearer:

• LangGraph: a Python library with maximum flexibility, but every Agent becomes its own maintainable codebase, and cross-team reuse relies mostly on discipline.
• Dify / Coze: visual canvases with low onboarding barriers, but once workflows become complex, they turn into “spaghetti canvases,” and version management becomes painful.
• Claude Skills / Antigravity Skills: standardized capability packaging, but implementation languages vary internally, making cross-vendor migration expensive.
• Skillscript: text-based, declarative, with built-in sandboxing and naturally Git-friendly, but requires learning a new syntax and currently has almost no ecosystem.

Skillscript feels more like “Terraform for the Agent world.” It’s not trying to replace Python or visual canvases, but rather fill a gap in scenarios where you need strict control over what an Agent is allowed to do. Finance, healthcare, and enterprise intranets — environments sensitive to permissions — are probably where it will land first.

Several Problems Still Unsolved

A bit of cold water here. After reading through the code and issues, I have several real concerns.

First, the ecosystem is nonexistent. The repository currently includes only a few built-in tools (basic wrappers for http, fs, and llm). To integrate Slack, Notion, databases, or other common systems, you have to write adapters yourself. The author says there are plans for an npm-like registry, but that’s still just an idea.

Second, the relationship with MCP remains unclear. Anthropic’s MCP protocol has effectively become the de facto standard for tool calling this year — Claude Code, Codex CLI, Figma, and others are already using it. Skillscript currently has its own separate tool interface and no direct MCP compatibility. The author mentioned in issue #12 that the next version will include an MCP adapter, but there’s nothing concrete yet.

Third, the debugging experience is mediocre. The upside of declarative systems is static analyzability; the downside is difficulty debugging. Right now there’s only a CLI dry-run mode that prints execution plans but doesn’t support true step-through debugging. That’s a serious limitation in production environments.

Fourth, the syntax itself is subjective. Some people on HN complained that it “looks like HCL but uglier,” while others think it’s far better than YAML. I lean toward the latter, but syntax aesthetics are always debatable.

Worth Watching, but Don’t Go All-In Yet

To put it plainly: Skillscript is still basically a weekend-project-scale effort. It has just over a thousand GitHub stars, and a single author maintaining it. What makes it interesting isn’t the code itself, but the question it raises: what should the Agent tool orchestration layer actually look like?

Over the past two years, everyone has been racing toward “let the LLM write code itself.” Anthropic Skills, Google Antigravity, and various DeepAgent+Sandbox combinations are all essentially attempts to put guardrails around that improvisational process. Skillscript goes in the opposite direction: build the guardrails first, then let the LLM operate only within their boundaries.

Which path will ultimately win is still far too early to say. But at the very least, this project brings the discussion back to a fundamental point: auditable, reusable, statically analyzable Agents are far more valuable in production than improvisationally generated ones.

If you’re building an internal enterprise Agent platform or evaluating options for a Skills ecosystem, Skillscript is worth trying out just to get a feel for declarative orchestration. If you’re only building personal demo projects, LangGraph or Dify will still be the easier choice.

One more side note: OpenAI Hub currently integrates mainstream models including GPT, Claude, Gemini, and DeepSeek. A single API key works across all of them, with direct domestic connectivity and OpenAI-compatible formatting. If you want the llm.complete tool in Skillscript to quickly test against multiple model providers, using an aggregation gateway like this can save a lot of hassle.

References

• Show HN: Skillscript – A declarative, sandboxed language for tool orchestration — Main project repository, including syntax documentation, examples, and issue discussions