Skip to content
Tuff
Blog

When to Use Tuff

Tuff is for teams that want agent capabilities to be managed like normal engineering assets: visible in a project, reviewable in pull requests, and reproducible across machines.

Team capability pack

Section titled “Team capability pack”

A platform or developer-experience team can test capabilities in an initialized agent project and package the tracked set directly:

Terminal window
tuff pack build --name company-agent-pack --version 1.0.0
tuff pack verify tuff-dist/company-agent-pack-1.0.0.tuffpack

When the team needs a reusable subset, tuff pack init company-agent-pack --from-project creates a small definition under tuff-packs/ that refers to tracked capability IDs without copying their files. A dedicated release repository can instead use the advanced standalone layout:

company-agent-pack/
  tuff-pack.toml
  capabilities/
    rust-testing/
    security-review/
    release-prep/

The platform team validates and builds the standalone source into the same artifact format:

Terminal window
tuff pack check company-agent-pack
tuff pack build company-agent-pack --output tuff-dist/company-agent-pack-1.0.0.tuffpack
tuff pack verify tuff-dist/company-agent-pack-1.0.0.tuffpack

Product teams install the complete pack atomically, while runtime infrastructure can extract a verified target tree without project state:

Terminal window
tuff init
tuff add pack tuff-dist/company-agent-pack-1.0.0.tuffpack -a open-agents
tuff pack extract tuff-dist/company-agent-pack-1.0.0.tuffpack -a open-agents --output runtime/

The project owns installed output. If a team customizes a member, Tuff shows that drift instead of hiding it. See Capability Packs for the complete authoring and delivery contract.

Project-specific capabilities

Section titled “Project-specific capabilities”

Some agent behavior belongs to a single project. For example:

  • how to run that service locally
  • how to test a migration
  • how to review domain-specific code
  • how to prepare a release

Those capabilities can live inside the project and still use Tuff for validation, install state, drift detection, and pack releases.

Personal or global setup

Section titled “Personal or global setup”

An engineer may also keep personal capabilities in a global location and load them into a harness. Project packs intentionally select project-scoped capabilities because the strongest team workflow is project-owned state that can be reviewed and shared.

Global capabilities are useful for personal preferences. Project capabilities are better for team conventions.

Adopting external skills

Section titled “Adopting external skills”

Teams can adopt useful skills from ecosystems such as skills.sh or GitHub repositories, then bring them under Tuff lifecycle tracking.

The intended flow is:

Terminal window
tuff add skill https://github.com/owner/repo rust-implement -a open-agents
tuff list
tuff diff rust-implement

Use tuff add -a open-agents .agents/skills/<id> for local agent assets that already exist in a project. Use tuff add skill <git-url> <id> for capabilities hosted in a git repository.

Harness compilation

Section titled “Harness compilation”

Different coding agents expect different file layouts. Tuff should keep a single managed source model and compile or emit agent-specific output:

Terminal window
tuff harness add open-agents
tuff harness add claude

Harness adapters make agent output explicit and reproducible. The same managed capability can be emitted into .agents/ for Open Agents-compatible harnesses or .claude/ for Claude Code.