Refly: an agent skills builder that compiles SOPs into versioned, exportable skills

The problem Refly targets: skills that outlive the prompt

The README opens with a position rather than a feature list: skills are not prompts, they are durable infrastructure. The failure it describes is specific. Teams write vibe-coded scripts and black-box logic, those scripts work in a demo, and then they break in production because nothing about them is versioned, reviewable or reusable. The README frames the bottleneck as the absence of standardised actions rather than the quality of the underlying model, and points at Claude Code, AutoGen and MCP as the runtimes that need those actions.

Who this is for is stated fairly directly. The use-case table lists four entry points: calling workflows via an API, connecting to Lark/Feishu by webhook, exporting skills for Claude Code, and building a Clawdbot. The API section names Lovable, and the delivery section names Slack, Cursor and managed scheduling. That is a builder audience, not an end-user audience. If you are an individual developer writing one-off prompts, the versioning and registry machinery here is overhead. If you are maintaining the same business rule across three agent runtimes, the pitch lands.

How the Model-Native DSL and the intervenable runtime fit together

Refly describes two layers. The first is construction. You describe business logic in natural language and a copilot-led builder compiles that intent through what the README calls a Model-Native DSL into a skill. The README claims this DSL is optimised for LLMs, which it says lowers token cost, and that the transition from a static enterprise SOP to a production-ready skill takes under 3 minutes. Those are vendor claims from the README, not measured results, and no benchmark or example output is given in the supplied material.

The second layer is execution. Refly calls it an intervenable runtime: you can pause, audit and re-steer agent logic mid-run, and the README says strict business rules are enforced to minimise hallucination and handle failure recovery. Read that carefully. Determinism here appears to come from the runtime holding state and letting a human intervene, not from the model producing identical output every time. The README also states that any agent can invoke these skills with 100% reliability, which is a marketing figure rather than a documented guarantee. The architecture that is actually visible is a unified execution layer that pulls together MCP integrations, tools, models and reusable skills, then exposes them through different delivery channels. What is not visible in the supplied material is the DSL syntax itself, the shape of a compiled skill, or how state is persisted between a pause and a resume.

Getting it running: what the README does and does not give you

This is where the repository is thinner than the pitch. The Quick Start section offers two paths. The first is self-deployment, linked to docs.refly.ai/community-version/self-deploy/, which the README recommends for developers and describes as a step-by-step guide to deploying Refly on your own server using Docker. The second is the API reference, linked to the docs/en/guide/api directory inside the repository. The only alternative offered is the hosted workspace at refly.ai/workspace.

There are no install commands, no compose file contents, no environment variable names and no configuration keys anywhere in the supplied README. The table of contents gives time estimates for each path (5 minutes for a first workflow, 10 for API integration, 15 for the Lark/Feishu webhook, 15 for exporting to Claude Code, 20 for a Clawdbot) but not the steps. So the honest instruction is: read the self-deploy guide before you plan anything, because that page, not this repository, holds the deployment procedure. Treat the minute estimates as the author's estimate of reading time, not as a tested install duration.

The skill registry and the export surface are the real product

The most concrete part of the project is the split between the platform and the registry. Refly Skills is described as the official executable skill registry, hosted in a separate repository at refly-ai/refly-skills, and its stated properties are the ones that matter operationally: skills run in Refly with one click, they are versioned rather than one-off, they can be exported to Claude Code or deployed as APIs, and the community can import, fork and publish skills.

That registry is what turns the platform from a workflow tool into shared infrastructure. The governance section makes the same point from the enterprise side: a central skill registry for managing, versioning and sharing capabilities, plus team workspaces with version control and audit logs. If you strip away the framing, the value proposition is a versioned artefact with a name, a history and an owner, which is exactly what a prompt pasted into three different tools is not. The export surface is where that artefact pays off: the same skill becomes an API for a frontend builder, a webhook for a chat platform, or a native tool for an editor agent. The README does not describe how the export formats differ or what is lost in translation between them, and that gap is worth probing before you standardise on it.

Where Refly is the wrong tool, and what to use instead

Two limitations are visible from the material alone. The first is licensing. The badge and the repository metadata both point at a ReflyAI License, and the repository metadata classifies it as NOASSERTION, meaning the licence could not be mapped to a standard identifier. The README does not summarise the terms. If your organisation has a policy against non-standard licences, or if you intend to redistribute a modified version, you need to read the LICENSE file yourself before you build anything on top of it. This is a factual gap, not a judgement about the terms.

The second is scope. Refly is a builder and a registry for skills that are meant to be reused across runtimes. If your problem is a single scheduled job that calls an API and posts a message, a general workflow automation tool such as n8n is a reasonable alternative, and the repository's own topics list n8n-alternative as a positioning claim. The difference in approach is where the artefact lives. n8n centres on a workflow graph you own and run; Refly centres on a named, versioned skill that can be exported into someone else's agent runtime. That distinction only matters if you actually have multiple runtimes to feed. If you have one, the registry and the intervenable runtime are weight you are carrying for no reason.

Maintenance, versioning and upgrade cost

The release history in the supplied material shows v0.9.1 and v0.10.0 in August 2025, then v1.1.0 in February 2026, with the repository last pushed in July 2026. That is a long quiet stretch followed by a major version bump, which tells you the project is active but does not tell you how stable the interfaces are. For a platform whose selling point is versioned skills, the stability of the skill format across major versions is the thing to check first, because a v1.1.0 that changes the compiled skill shape invalidates everything in your registry.

The README claims native version control and audit logs in team workspaces, and the registry is described as versioned, but the supplied material does not describe a migration path between skill versions or a deprecation policy. Self-hosting adds its own cost: you are running the deployment described in the self-deploy guide, which the README says uses Docker, and you own the upgrades. The hosted workspace at refly.ai/workspace removes that burden but moves the question to the licence and the terms of the hosted service, which the README does not cover. On licensing specifically, the NOASSERTION classification means you should treat the terms as unknown until you read the LICENSE file, and that is a question for your own legal review rather than for this article.

What to check before you commit a team to Refly

Start with the two documents the README actually points at, because they carry the operational detail the repository does not: the self-deployment guide at docs.refly.ai/community-version/self-deploy/ and the API reference under docs/en/guide/api. Confirm that the self-deploy path covers your environment and that you can reach a running instance before you evaluate anything else.

Then test the claim that matters most to your use case. If you are exporting to Claude Code, build one skill and export it, and inspect what the export actually contains. If you are wiring a Lark/Feishu webhook, do that instead, since the README budgets 15 minutes for it. The registry at refly-ai/refly-skills is the other thing to look at early, because it shows you the shape of a finished skill rather than the pitch for one. Until you have seen a compiled skill and read the LICENSE file, you are evaluating a description, not a platform.

Editorial conclusion

Adopt Refly if you already have written SOPs that different agents keep re-implementing badly, and you want one versioned artefact to export to Claude Code, Cursor, Slack or Lark/Feishu. Do not adopt it if you need a fully permissive licence, or if you expect the repository to hand you a working docker compose up on the first read: the Quick Start links to a self-deployment guide on docs.refly.ai and the API reference under docs/en/guide/api, not to commands in the README. Verify three things before committing: the actual terms of the ReflyAI License, whether the self-deploy guide covers your target environment, and whether the Model-Native DSL output is inspectable enough that you can review it before it reaches production.

Official sources

1. Issues
2. Project website
3. README
4. refly-ai/refly on GitHub
5. Releases