Tuff

Tuff is a Rust-based command-line tool for managing a project's own coding agent capabilities, including skills, tools, hooks, MCP servers, and policies. Its core goal is to make these capabilities usable across different harnesses, ship alongside the agent, and be governed everywhere.

Purpose

Tuff is aimed at development teams that need to manage coding agent capabilities. The core problem it solves is that agent capabilities (such as skills, tools, MCP servers, etc.) are scattered across different projects, in varying formats, making it difficult to track their origin, versions, and changes. Tuff manages these capabilities in a unified way, records installation status, origin, and whether they have changed, and generates the format required by each harness.

Main capabilities

• Harness-agnostic: Tuff writes each capability in a format readable by each coding agent, and records it once in tuff.lock.
• Capability lifecycle management: Skills, tools, MCP servers, hooks, and policies are all files in the project. Tuff records what is installed, where it came from, and whether it has changed. You can create new capabilities, or bring existing agent files under management without rewriting their contents.
• State recording: Records origin, version, scope, harness, output paths, and a clean-install baseline in the project state.
• Drift detection: Compares current files against the baseline, so intentional edits are visible and accidental drift is not silently ignored.
• Change handling: Accepts intentional local changes, merges upstream updates where possible, and fails the build in CI when tracked capabilities are not in the expected state.
• Package-manager-style workflow: Tuff works like a package manager, maintaining a lock file in the repository. Once committed, the whole team gets the same setup, with no hosting service required.
• Origin support: Capabilities can come from local directories, Git repositories, OCI registries, or a built-in MCP catalog, and their origins are all recorded.
• Scope: Capabilities can be project-level or global-level. When both define the same capability, the version checked into the repository takes precedence.
• Packaging and publishing: Packages the skills, tools, hooks, and MCP servers behind an integration into a deterministic artifact. Publishes via OCI, pins by digest, and deploys the same reviewed bundle to every agent runtime.
• Harness-native files: Extracts harness-native files from the exact reviewed artifact, for exampleSuch as .agents/skills/.
• Write once, output per harness: Write a capability once in tuff.toml, and Tuff converts it into the file each agent reads, using that agent's own format.
• CI integration: Run checks in CI and fail the build on drift, rather than discovering it only after release.
• Self-bootstrapping skill: Tuff itself is released as a skill. Agents learn the CLI and hook specifications upon installation, so they can write manifests and run commands for you.
• Report generation: Generate a complete report of all installed capabilities, sources, and policy status directly from the CLI, with no hosted service required.
• Tuff Console: Teams can run Tuff Console on their own servers, showing each agent's skills, tools, MCP servers, hooks, and policies, which harness runs them, what changed, and in which commit. GitHub Actions can publish without a secret; other CI uses an API key.

Usage

Tuff is used as a CLI. The basic workflow includes: defining capabilities in tuff.toml, running Tuff commands to convert them into each harness format and record them in tuff.lock. It supports installing capabilities from multiple sources and can check for drift via CI. Tuff itself is released as a skill, and after agents install it they can learn the CLI and hook specifications, helping to write manifests and run commands.

Applicable scenarios

• Teams need to uniformly manage capability configurations for multiple coding agents.
• Need to track the source, version, and changes of capabilities to avoid configuration drift.
• Need to package capabilities as versioned artifacts, publish them via OCI, and deploy them to different runtimes.
• Need to verify capability status in CI to ensure consistency.
• Need to view each agent's capability status and change history across organizations.

Limitations

The materials do not provide detailed information about fees, pricing, platform support scope, specific performance metrics, or usage steps. Some features (such as Tuff Console) require teams to run them on their own servers. Other CI uses an API key to publish reports.