Refly: an open source agent skills builder that compiles workflows into portable skills

The problem Refly targets: prompts do not survive a team

The README states the premise directly: "Skills are not prompts. They are durable infrastructure." That framing is aimed at a specific failure mode. A workflow that works in one engineer's chat session is not a workflow an organization can depend on, because it has no version, no audit trail and no way to run on a schedule without someone present. Refly's answer is to treat the workflow itself as the artifact. You describe the logic, the platform compiles it into what the README calls a skill, and that skill can then be invoked by an API call, a chat webhook or an agent runtime. The intended user is not an individual experimenting with an LLM. It is a team that has an internal process, wants it to run the same way every time, and wants to hand it to whatever agent framework the team is already using. The README names Claude Code, Cursor, Codex, Lovable, Slack and Lark/Feishu as delivery targets, which tells you the project is positioning itself as a layer between business logic and agent runtimes rather than as an agent itself.

How the builder, runtime and registry fit together

Three pieces are visible from the repository and README. The first is a copilot-led builder: you describe business logic in natural language and a "Model-Native DSL" compiles that intent into an executable skill. The README claims this DSL is optimized for LLMs and reduces token cost, but it does not publish the DSL grammar, so you cannot evaluate that claim from the repository alone. The second is a stateful runtime that the README calls an "Intervenable Runtime", meaning a run can be paused and re-steered mid-execution. That is a real architectural decision, not a slogan: it implies the runtime persists execution state rather than treating a skill as a single function call. The third is a skill registry, where skills are versioned and shared. The repository layout supports this reading. It is a pnpm and Turbo monorepo with apps/, packages/, deploy/, docs/ and specs/ at the top level, which is consistent with a web front end, an API service and shared packages built together. There is a separate repository, refly-ai/refly-skills, described as the official executable skill registry, so the registry is not only a feature inside this codebase.

Installing Refly from the monorepo

The README does not walk through a from-source install. It points to a self-deployment guide at docs.refly.ai/community-version/self-deploy/ and says that guide covers deploying Refly on your own server using Docker, and it recommends that path for developers. That is the documented route. If you want to build the monorepo yourself, the root package.json is the only install information in the repository, and it constrains the toolchain before you run anything. The engines field requires pnpm 10 or later and Node 24 or later. Check both before cloning, because a mismatch here fails early and unhelpfully.

pnpm install
pnpm build:api
pnpm build:web

Those three are root scripts: install resolves the workspace through pnpm-lock.yaml and pnpm-workspace.yaml, and the two build scripts are Turbo tasks filtered to the @refly/api and @refly/web packages respectively. For a development loop, the root dev script runs Turbo across the workspace, and environment files are handled by a dedicated script rather than committed.

pnpm copy-env
pnpm dev

What you should see after a successful build is the API and web packages compiled under the workspace; the README does not document the ports the services bind to, so read the deploy configuration in deploy/ before assuming anything is reachable. For a first real use, the README's own table is the honest starting point: it lists creating a workflow as a five-minute task, calling it over the API as ten minutes, and connecting Lark/Feishu as fifteen.

The licence is the first thing to check, not the last

The repository's LICENSE file is present, but GitHub reports the licence as NOASSERTION, and the README badge reads "ReflyAI License" rather than naming a standard identifier. Those two facts together mean the terms are custom and were not matched to a recognised template. This is not a formality. If you are evaluating Refly for a company, the difference between an Apache-2.0 grant and a bespoke licence can decide whether you may embed the runtime in a product, whether you must contribute changes back, and whether a hosted offering is permitted. The README does not summarise the terms and does not link to a plain-language explanation. Read the LICENSE file itself, and if the answer matters commercially, have someone qualified read it too. Nothing in the repository substitutes for that step, and the NOASSERTION label is a signal that automated licence scanners will not classify it for you.

Where Refly is the wrong tool

The README's own framing narrows the audience more than the feature list suggests. Refly is built for workflows that repeat and that more than one person needs to run. If your task is a one-off script, you are paying the cost of a monorepo, a runtime and a registry to avoid writing a cron job. The second limitation is documentation depth. The README is long on capability claims and short on mechanics: it does not publish the Model-Native DSL, does not document the HTTP ports the services listen on, does not describe how to roll back a skill version, and does not describe the upgrade path between releases. The release history is also uneven. v1.1.0 was published on 2026-02-02, roughly five months after v0.10.0 on 2025-08-27, with v0.9.1 before that on 2025-08-14. The most recent push to the default branch was on 2026-07-29, so work is ongoing, but the gap between the two most recent releases means you should not assume frequent tagged versions. If your organisation needs a documented support contract or a stable release cadence to plan around, that cadence is not visible here.

How Refly differs from a general workflow automation tool

n8n is the obvious comparison, and the repository's own topics list n8n-alternative, so the project invites it. The difference in approach is where the output lives. A general automation tool typically runs the workflow inside itself and exposes a trigger; the workflow is the product. Refly's stated goal is to export the compiled skill outward, as an API, a webhook, an MCP server or a native tool for Claude Code and Cursor. That is a different bet. It means Refly is competing less on the number of integrations and more on whether the compiled skill is portable enough to be worth compiling in the first place. The trade-off is real: a portable skill has to be expressed in a form other runtimes can consume, which constrains what the builder can express. If your workflow only ever needs to run inside one automation platform, the export layer is overhead. If your workflows are increasingly invoked by coding agents that you do not control, the export layer is the point.

FAQ

Answers below are limited to what the repository and README state. Where the documentation is silent, that is noted rather than filled in.

Editorial conclusion

Adopt Refly if you already have repeatable internal workflows and want them versioned and exportable to Claude Code, Cursor, Slack or Lark/Feishu rather than living as prompts in someone's chat history. Do not adopt it if you need a documented licence before procurement sign-off, or if you only need a single scheduled script. Before committing, verify three things: the actual terms in the LICENSE file, which Node and pnpm versions your environment can satisfy against the engines field, and whether the self-deploy guide at docs.refly.ai covers the upgrade path you need, because the README does not.

Frequently asked questions

Official sources

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