runx

runx

The governed runtime for agent skills

Quickstart · Workflows · Write a skill · Receipts · Build on Runx

---

A skill is a URL.

A graph is what unfolds. Authority narrows. It does not pass through. Every act produces a receipt.

A skill is expertise published as a portable SKILL.md: an operating manual that a human can understand and an agent can act from. It carries the method, the evidence to look for, the decisions to make, and the tools the work needs. Skills can call other skills, passing their results forward into a larger job.

Runx makes that work executable. A research brief can become an outreach draft. A product launch can connect release work, documentation, and customer updates. Search and product analytics can inform the next change to your site. Across those handoffs, Runx admits calls under explicit authority, delivers credentials at the tool boundary, supervises execution, and seals a verifiable record.

Your agent supplies the judgment. Runx owns the execution boundary. Use the CLI, MCP, or a language client with the agent or orchestration framework you already use. Execution, state, and receipt signing run locally; hosted registry, credential custody, and notary services are optional. The runtime is written in Rust and licensed under Apache-2.0.

Quickstart

With your agent

Give your agent the Runx operating manual:

Set up Runx: https://runx.ai/SKILL.md

Then give it a bounded job. For example:

Use Runx to investigate where our organic visitors stop becoming active users.

Use Search Console, GA4, and our saved PostHog activation funnel. Compare the last two complete 28-day periods. Bring back the evidence, three priorities, and a proposed content or product change. Stop before publishing or sending.

The agent can discover skills, inspect their inputs, bind the tools you choose, and work through the run's open turns. Missing accounts, evidence, or decisions remain explicit requests. Native skill exports are also available for Claude Code and Codex.

From your terminal

Install the native CLI through npm:

npm install --global @runxhq/cli

Or use the standalone installer on macOS or Linux:

curl -fsSL https://runx.ai/install | sh

Run the smallest complete example. This needs Git and Node.js 20 or newer; it needs no Runx account, model, or provider key.

git clone --depth 1 https://github.com/runxhq/runx.git

cd runx

runx skill ./examples/hello-world --run-id first-run \ -i message="Hello, Runx." --json

Selected fields from the result:

{

"status": "sealed", "outcome": "completed", "run_id": "first-run", "result": { "message": "Hello, Runx." }, "receipt_id": "sha256:…" }

Read the run, then verify the full receipt ID returned by the command:

runx history first-run --json

runx verify --json

The example executes a checked-in Node.js command. It exercises the same admission, execution, and signing path used by larger skills. The npm package distributes the native runtime; Node.js is needed here for the example script. See Getting started for the full walkthrough and installation options for platform packages.

Skills can come from a local directory, a URL, or the registry. Published skills keep their publisher/name identity; verified publishers' skills can also hold a short root name. Local packages take precedence when resolving a bare name. Use an exact version and digest when you need to reproduce someone else's run.

Skills working together

Skills pass useful work forward: matched facts, a source-backed brief, a validated draft, an exact action to approve, or a receipt from the last run. The next skill can use that result directly.

These are compositions you can give an agent: Runx skills working with your repositories, provider skills, and connected accounts. Your agent or a project-owned graph makes the handoffs, carrying the actual outputs into the next skill's inputs.

Business ops: get the next release into customers' hands

We're launching team workspaces in Northstar. Use Runx to prepare the release,

choose the customer audience, update the setup guide, draft the announcement, and coordinate the rollout with the team. Establish the activation baseline from workspace creation to the first teammate invited so we can measure adoption. Bring back the launch kit, blockers, and receipts. Ask before sending, publishing, or deploying.

operations-review reviews the release state and proposes the next launch actions. lead-enrichment organizes supplied customer facts to inform the audience choice; the operator supplies the actual audience and contact policy.

release#prepare checks the project's release profile and produces the version-bound brief. The full release runner owns approval, publication, and verification through the project's commands. content-package combines release facts and product documentation with research and ghostwrite to prepare the setup guide and announcement, then packages them for publication.

message-send#plan binds the principal, audience, accepted content, and approval requirements. The calling agent can hand that plan to Nitrosend or another email provider's skill for its review, approval, and delivery workflow. For a team update, message-send#send owns the Slack post and independent readback itself. product-analytics establishes the workspace-to-invitation baseline from supplied reports and compares later results under the same measurement definition.

What comes back: a launch kit with release notes, a setup guide, the customer announcement, a team update, and an activation baseline—plus the blockers, decisions, and receipts needed to take it live and follow adoption afterward.

Outreach: facts → fit → a useful first contact

lead-enrichment normalizes supplied facts about a confidently matched subject. lead-qualify checks those facts against your ICP and keeps commercial fit separate from contact eligibility. cold-outreach takes that context, supported research, and the exact recipient's suppression state to prepare one email.

The draft can use brand-voice and taste-profile without allowing either to invent product claims. Inside cold-outreach, ghostwrite#admit validates the evidence and writing context before drafting; ghostwrite#verify checks the result's source bindings afterward. Missing eligibility, suppression, or an unsupported claim produces a hold.

What comes back: the exact sender, recipient, subject, body, and a source binding for review. message-send#plan can take that accepted draft into a provider handoff. The selected email skill—Nitrosend or another provider—checks its own audience and sender requirements, obtains approval for the exact send, and reports the provider result. Choose a provider and delivery mode that permit the intended contact; commercial fit alone never grants that permission.

Enrichment uses the evidence you supply; a provider lookup is a separate connector operation. The calling application retains outcomes for follow-up. A reply, opt-out, or changed eligibility changes what the next run may do.

Try it with your agent: *“Use the supplied prospect research, our ICP, brand voice, and contact-policy decision to prepare one useful first-contact email. Show the facts behind it and hold any recipient with unresolved eligibility.”*

Organic growth: connect discovery to activation

Each source answers a different question. Search Console shows how people find you. GA4 shows acquisition and behavior under the property's measurement model. Product analytics shows where a defined journey loses people or accounts after signup.

google-search-console and google-analytics return normalized evidence with source digests and measurement caveats. The PostHog connector reads saved insights from your selected Cloud project and region; it preserves their query definitions and cached-result freshness. product-analytics consumes the supplied aggregate reports, calculates funnel and retention rates, and checks whether the comparison is meaningful.

organic-growth combines search, analytics, site, and market evidence into priorities and a measurement plan. Product findings can join that evidence with their source reference and digest. For example, a page getting more clicks while its visitors fail to activate may need a clearer promise, a better onboarding path, or an instrumentation fix.

What comes back: observations, hypotheses, ranked actions, source bindings, and a measurement plan. Content work can continue through content-package; code and instrumentation work can go through code-plan and github-issue-to-pr in the owning repository. The next analysis reuses comparable windows and definitions. Missing or stale reports remain measurement gaps.

Run the local workflow proofs

From this checkout:

# Research → draft → channel package → publication handoff

runx harness skills/content-package/fixtures/composes-in-graph.yaml

A specific outreach draft with supplied evidence and w