All articles
forge ai-agents agent-skills 4 min read

Teach your agents new skills — no vendor release required

This week half of Show HN is inventing a format for authorable agent skills — and the loudest open question is: how do you trust a skill an agent can author? Forge just shipped the governed answer. Any org can now write its own agent skills at runtime — org-scoped, role-gated, live to a real multi-agent fleet, with no conductor rebuild.

by Vitaly Nikitin

Open Hacker News this week and you’ll notice the whole AI-dev crowd is inventing the same thing at once. Zotfile packages “agent behavior, skills, requirements, and permissions into a portable .zot file.” Dex ships analytics capabilities as SKILL.md files you install with npx skills add and pull from a plugin marketplace. And Skillscript — a sandboxed language for agent tool orchestration — went up with the author openly asking the crowd the hard part out loud: what’s “the trust model around agent-authored skills?”

That question is the whole game. It’s easy to let an agent load a new capability from a file. It’s hard to do it without handing every agent in your org a new way to go off the rails. This week Forge shipped the answer that question is begging for: any organization can now author its own agent skills at runtime — and every one is org-scoped and role-gated by construction.

What actually shipped

Until now, the skill registry your Forge agents draw on — the skill_get runbooks that tell a character exactly how to perform an operation — was a fixed, platform-only set baked into the conductor at build time. Useful, but closed: if your team had a house way of doing something, you waited for us to ship it.

That’s gone. Over seven merged slices (forge-conductor PRs #109–#115 ), the registry became dynamic and org-owned. An organization writes its own skills as plain Claude-Code-style markdown with role hints, and its agents immediately see them in their system-prompt skill index and can skill_get them — with zero conductor rebuild and zero redeploy. You author it; your fleet has it a moment later.

And you can author from wherever you already work: a dedicated authoring page in the SPA (PR #115), or straight from chat with the create_skill control tool in Telegram (PR #114). Write a skill on your phone; your agents pick it up on their next turn.

The part the market is still asking about: trust

Here’s where the “trust model” question gets answered instead of asked. A custom skill isn’t a free-for-all — it’s governed on two axes at once:

  1. Strictly org-scoped. A skill your org authors is visible only to your org’s agents. A different organization on the same platform never sees it, never loads it, can’t skill_get it. This was verified live, not asserted: a different org’s agents came back empty.
  2. Role-gated inside the org. Skills carry role hints, so a runbook meant for a developer character doesn’t surface to a QA character who shouldn’t run it. Also verified live — a developer saw a custom skill in the same org where a qa_engineer did not.

That’s the difference between a portable file and a governed capability. Skillscript’s author is asking how to make agent-authored skills trustworthy; Forge’s answer is that authorship and authorization are separate concerns — you can write a skill freely, but who gets to run it is decided by org boundary and role, not by whoever wrote the markdown.

Bounded capability, bounded cost

Custom Skills didn’t ship into a vacuum — it plugs into the same guardrails Forge already runs agents inside. New skills execute under the per-workflow autonomy budget : the count-based dial (chained runs, auto-merged PRs, depth, optional spend) that stops an autonomous chain before it over-runs and hands the decision back to a human. That directly answers the other thing HN is worried about this month — the “token-rot” thread on agents burning context and cost with no ceiling. A new capability can’t quietly become a new way to run up the bill.

There’s a nice proof-point in how this feature was built, too: the whole seven-slice milestone was delivered by Forge’s own autonomous SDLC running against Forge itself — each slice a discrete run, each producing a merged, auto-deployed PR, each smoke-tested on an isolated stack. We didn’t just ship a way to author capabilities; we authored this capability the same governed way we’re asking you to.

The takeaway

The market spent this week prototyping formats for authorable agent skills and openly wondering how to trust them. Forge shipped the governed version: write your own agent skills at runtime, and have them reach a real multi-agent fleet that’s org-scoped, role-gated, and cost-bounded — no waiting on a vendor release, no new way for an agent to slip its leash.

If your agents keep needing you to teach them the same thing by hand, stop waiting for us to bake it in. Write the skill yourself.

Try it

See the Workflow Engine for what your skills plug into, revisit how autonomy budgets bound the loop , or reach out at [email protected] to author your first org skill.