Dalo 1.0

September 2026. Dalo keeps your team's agent skills in Git and links one resolved, approved set into the folders your agents already read.

Dalo owns what is behind those folders: sources, priorities, approvals, conflicts, drift. It repairs them on the next dalo sync. Your agents learn nothing new; they keep reading ~/.claude/skills, ~/.agents/skills, or whatever folder you point them at.

What 1.x guarantees

1.0 is the release where the surface stops moving. Inside the 1.x line, every command and flag in the command reference keeps its documented meaning, the five exit codes keep theirs, --json gains fields but never removes or retypes one, and a file Dalo persists stays readable by every later 1.x.

Removals wait for a major release and are announced one minor ahead with a runtime warning. That is why no deprecated spelling entered 1.x at all: the pre-1.0 shims were removed before the line froze, so nothing is carried for the life of the major.

What is not promised is labelled as such: the draft portable-package specification, provider projections, human-readable output, the store-internal layout, and the Rust library API. The full contract is on Compatibility and stability.

Dalo runs on macOS and Linux, on x86_64 and aarch64, with both gnu and musl Linux builds. Windows is supported through WSL only; there is no native Windows build in 1.x. Security fixes land in the latest 1.x release, so the fix is always an upgrade; there is no long-term-support branch. When 2.0 ships, 1.x keeps receiving security fixes for six months.

What changed since 0.6

One approved skill set for a whole team

A team repository carries a committed dalo.toml naming the team's own skills and pinning the public catalogs everyone gets; dalo team init, dalo team catalog add, and dalo team show maintain it. A teammate runs dalo source add <id> <url> and dalo sync and has exactly what the manifest says, because URL, revision, priority, and selection stay owned by it. See the team guide.

Nothing reaches an agent folder unreviewed

A deterministic, local preflight reads every skill — it never executes one — and blocks a sync on high or critical findings until a person records a content-bound exception. Inspect with dalo audit <skill>, grant narrowly with dalo approve skill <source>:<skill>, review with dalo approve list, withdraw with dalo approve revoke. Approvals are source-qualified, so one can never apply to a same-named skill elsewhere. The security overview also states plainly what this does not protect against.

Machines stay current on their own

dalo autosync install --schedule hourly registers a recurring dalo sync --check with launchd, a systemd user timer, or cron; dalo autosync status reports the last attempt and the last success. Scheduled runs are fail-closed: dirty sources, pending approvals, security findings, and target conflicts stop the run and say why. See dalo autosync.

Shared instructions, not just skills

Instruction packs render into a Dalo-owned managed block inside an existing AGENTS.md or CLAUDE.md and leave what you wrote around it alone. dalo instructions enable <pack> --target claude, dalo instructions disable, and dalo instructions list control them, and every dalo sync refreshes the block. See instruction packs.

Portable plugins with tools and hooks

A PLUGIN.toml package ships skills, executable tools, and hook contracts as one description that compiles to each provider's native files. dalo plugin validate <path> checks it before anyone adds it, dalo plugin select picks one, dalo plugin review <source>:<plugin> shows the whole closure, and dalo tool list and dalo hook list show what would run. Tools and hooks are approved separately from skills, by exact contract hash. See the plugins guide.

You are told what to do next

dalo next prints the state of the store and one copyable command; dalo doctor reports every finding with the command that clears it; a mistyped source, skill, target, or pack gets a did you mean suggestion and the known names. See troubleshooting.

Two more things carried the release without being features. dalo target detect is read-only and names the default skill directory of every supported agent; Codex, Claude Code, OpenClaw, Hermes, OpenCode, and generic are all supported in 1.0, nothing built in is labelled experimental, and the matrix records the agent version each was checked against, with the date. And six install channels — the hosted installer, npm (getdalo), Homebrew, mise, Cargo, and signed release archives — each publish every 1.x release; retiring one would be a major-version change.

Breaking changes

Four CLI spellings and one target ID were removed before the 1.x surface froze. Each now fails loudly instead of quietly doing something else.

Nothing in your store changes: no persisted schema version changed between 0.15.1 and 1.0, and Cursor reads the same directory after the generic link.

Upgrading

Install the new binary and run dalo sync. There is no migration command, nothing is unlinked, and no approval has to be granted again. Any store written by 0.6.0 or later opens in 1.0, and that is a test rather than a claim: the suite restores stores written by the released 0.6.0, 0.9.2, 0.12.0, and 0.15.1 binaries, runs what you run after upgrading, and asserts the resolved skill set is unchanged, no owned link moves, and the second sync is a no-op. Upgrading to 1.0 shows the real first-run output, the removed spellings, and how to recover.

Where to ask

Questions, rough edges, and "is this the right tool for us" belong in Discussions; the Q&A category is the fastest place to get an answer, and bugs go to Issues. 1.0 is a promise about what stays put; what comes next is decided in the open, issue by issue. Thank you to everyone who filed an issue, reported a rough edge, tested a pre-release, or said plainly what was confusing.

Release notes: GitHub releases · CHANGELOG.md