Kasetto
Reproduce and synchronize AI coding-agent environments from one version-controlled configuration.
- Source repo
- pivoshenko/kasetto
- Stars
- ★ 203
- Last updated
- 4d ago
- License
- NOASSERTION
- Primary language
- Rust
- FA score
- 70/100 · Some gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A platform team commits kasetto.yaml and kasetto.lock so new engineers reproduce the same Claude Code, Codex, and Cursor environment.
- Not a fit if
- Teams that require a graphical environment-management interface
- Users wanting only a one-off skill install without configuration or lockfiles
- Users who need native MCP support in Pi
- Source review
- 70/100 · Some gaps
What does this agent do, and when should you use it?
Kasetto is a Rust command-line environment manager that distributes skills, commands, MCP configurations, and instruction files across AI coding agents. Users declare sources, versions, target agents, and named assets in kasetto.yaml; kst sync then fetches the content and transforms it into each agent's native directories and formats. It records the exact installation in kasetto.lock, with normal syncs honoring the lock, --update advancing versions, and --locked enforcing it in CI. Sources can reside on public or private GitHub, GitLab, Bitbucket, Codeberg, Gitea, and self-hosted instances, while configuration can be local, global, or remote. Its deployment boundary is a static CLI binary on macOS, Linux, or Windows: it is neither a hosted service nor a model runtime.
Kasetto searches for configuration through $KASETTO_CONFIG, ./kasetto.yaml, the source key in the global config.yaml, and the global kasetto.yaml, in that order. kst init scaffolds configuration; kst add and kst remove modify sources and synchronize or prune assets; kst lock resolves sources into kasetto.lock; and kst sync installs skills, commands, mcps, and instructions into target-agent directories. During synchronization it hashes content, compares the lockfile, touches only changed assets, and inserts managed blocks when instruction files must be aggregated. Configurations can compose through extends and target agents including Claude Code, Cursor, Codex, Windsurf, Copilot, and Gemini CLI in one run. For ${kst_...} placeholders, it resolves values from environment variables, credentials.yaml, or a selected external secret manager and injects them into agent settings without storing resolved secrets in the lockfile. kst list reports installed assets, kst doctor checks versions, paths, recent sync status, and broken skills, while kst clean removes tracked assets for a selected scope.
- A platform team commits kasetto.yaml and kasetto.lock so new engineers reproduce the same Claude Code, Codex, and Cursor environment.
- A developer using several coding agents distributes one set of skills, commands, and instructions with a single kst sync.
- An enterprise team publishes internal skill packs from private GitHub, GitLab, or self-hosted repositories using existing access tokens.
- A CI maintainer runs kst sync --locked to verify that the environment exactly follows the committed lockfile.
- A team sharing MCP configurations injects credentials from Vault, 1Password, or cloud secret stores through ${kst_...} placeholders.
- An organization composes organization, team, and project configurations through extends while retaining project-specific scope.
How do you install or deploy this agent?
On macOS or Linux, use the standalone installer:
curl -fsSL kasetto.dev/install | shOn Windows, run:
powershell -ExecutionPolicy Bypass -c "irm kasetto.dev/install.ps1 | iex"Homebrew is also supported:
brew tap pivoshenko/tap
brew trust pivoshenko/tap
brew install kasettoFor Scoop on Windows:
scoop bucket add kasetto https://github.com/pivoshenko/scoop-bucket
scoop install kasettoUsers with a Rust/Cargo environment can install the crate:
cargo install kasettoThe documented public-repository path requires no additional credentials. Private repositories require the appropriate host token in an environment variable, such as GITHUB_TOKEN, GITLAB_TOKEN, BITBUCKET_TOKEN, or GITEA_TOKEN.
How do you use this agent?
Scaffold a project configuration in the current directory:
kst initAdd a source and immediately synchronize all of its skills:
kst add https://github.com/anthropics/skillsYou can instead select named asset types:
kst add https://github.com/example/repo --skill find --mcp github --command reviewRun synchronization and inspect the result:
kst sync
kst list
kst doctorA team configuration can also be synchronized directly over HTTPS:
kst sync --config https://example.com/team-skills.yamlCommit kasetto.yaml and kasetto.lock together. To advance moving references, run:
kst sync --updateEnforce the existing lockfile in CI with:
kst sync --lockedWhat are this agent's strengths and limitations?
- One YAML file declares skills, commands, MCPs, and instructions and converts them into native formats and locations for multiple agents.
- kasetto.lock separates reproducible synchronization, explicit upgrades, and locked CI enforcement.
- It supports multiple Git hosting providers, private repositories, and self-hosted instances instead of binding distribution to one agent ecosystem.
- Secrets can come from environment variables, a credentials file, or existing secret managers without being recorded in kasetto.lock.
- Static binaries cover macOS, Linux, and Windows, with JSON output and meaningful exit codes for automation.
- The documented workflow is entirely CLI- and YAML-based; no graphical configuration or review interface is described.
- Adoption requires maintaining both kasetto.yaml and kasetto.lock and understanding local, global, remote, and extends-based configuration precedence.
- Pi has no native MCP support, so Kasetto skips MCP sources for that target.
- A normal sync does not propagate a rotated secret into an existing live entry; kst sync --update is required.
- Repository metadata reports NOASSERTION for the license even though the README badge links MIT and Apache-2.0; adopters should verify the actual license files.
How does this agent compare with similar options?
The project contrasts itself with Vercel Skills and Claude Plugins. Its README characterizes Vercel Skills as installing from a curated catalog and Claude Plugins as supplying runtime integrations, while positioning Kasetto around version-controlled declarative configuration, lockfiles, and reproducible synchronization across projects, machines, and agents. This is the project's own positioning; the supplied source contains no independent benchmark.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Kasetto This agent | 70 · Some gaps | CLIFree | ★ 203 | 4d ago | Rust | Codex · Claude Code |
| Mantishack (Mantis AI) | 62 · Some gaps | CLIFree + model costs | ★ 504 | 2mo ago | Rust | Codex |
| Agent Desktop | 85 · Good | CLIFree | ★ 1.7k | 2d ago | Rust | — |
| Browser4 Agentic Browser | 47 · Major gaps | CLIFree + model costs | ★ 1.1k | today | Kotlin | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
CI explicitly limits contents permission to read, Rust forbids unsafe code, and release artifacts receive SHA-256 checksums. The README also explains remote configuration, credential sources, secret injection destinations, lockfiles, and directories affected by synchronization or cleanup. Deductions apply because runtime source is absent, so path confinement, download validation, and secret redaction cannot be verified; add synchronizes immediately, while confirmation, backups, and recovery for clean, remove, and self uninstall are unclear. Dependencies use broad version ranges, and GitHub Actions are pinned to tags rather than commit hashes. The author, repository, and security contact are identified, although enterprise-registry publisher identity remains unknown.
The README, Cargo metadata, and CI/release workflows are strongly consistent about the product name, version, binaries, platforms, and purpose. CI declares formatting, lint, test, and build stages, and the multi-platform release path is substantial. Deductions apply because test sources, Cargo.lock, installers, and external secret-manager detection logic are not supplied, preventing static confirmation of dependency availability. Nonzero exits, JSON output, doctor diagnostics, and missing-secret failure are documented, but evidence for specific diagnostic messages and recovery guidance is thin.
Documentation addresses individual, project, team, enterprise, CI, private-repository, and multi-agent scenarios, with numerous agent presets, manual destinations, local/global configuration, extends, platform installers, and secret backends. Configuration precedence, command triggers, and lock/update behavior are precise. The capability-boundary deduction reflects that only selected limits—such as Pi lacking native MCP support and missing-secret behavior—are stated; the supplied files lack a complete compatibility and conflict matrix for commands, instructions, MCPs, and transformations across agents.
The README has clear sections and practical installation, onboarding, command, configuration, secret, agent, and enterprise examples. Cargo metadata, dual-license documentation, and a private security-reporting route are present. Release automation updates the version, lockfile, changelog, artifacts, and package-manager manifests. Deductions apply because the actual changelog, an FAQ, a comprehensive limitations section, and governance documentation are not supplied. The kasetto/kst dual naming and deprecated plain alias are explained but enlarge the naming surface. An author and security email indicate responsibility, but backup maintainers, escalation, and long-term governance are unspecified.
Tables, YAML and JSON examples, machine-readable output, lockfile workflows, diagnostics, and agent-path mappings make the expected outputs readily actionable. A single declarative configuration, multi-agent synchronization, and secret placeholders offer plausible value over manual per-tool setup. Deductions apply because claims about speed, zero drift, comprehensive transformation, and superiority to alternatives are primarily README assertions without supplied implementation or benchmarks; curl-to-shell installation, external CLIs, and numerous integrations also introduce unquantified supply-chain and operational costs.
Version, license, author, dependencies, CI permissions, and release procedures are directly traceable to Cargo metadata, license material, and workflows, with generally good agreement across files. Deductions apply because the implementation and test bodies for synchronization, merging, content hashing, secret handling, path safety, and errors are absent, leaving many core claims traceable only to the README. Comparative, performance, and compatibility claims are presented as product statements but are not systematically separated into demonstrated facts, measurements, and inference.
- This assessment uses only the supplied static files; no binary, installer, test, or network operation was executed.
- Before adoption, inspect the implementation, Cargo.lock, and installer scripts, and verify that remote content is pinned by commit or checksum and protected against path traversal.
- In an isolated environment, confirm the exact write scope, confirmation behavior, backups, and recovery semantics of add, sync, remove, clean, self update, and self uninstall.
- Verify that secrets cannot enter logs, JSON output, temporary files, or error messages, and review command invocation and permission boundaries for every external secret manager.
- Treat curl-to-shell installation, remote PowerShell execution, and CI Actions not pinned by commit hash as supply-chain review items.