Installing Across Agents Without Losing Control

A verified skill is still only a source directory until it reaches the host agent that will use it. Tech Leads Club's CLI addresses the practical variation at that boundary: different agents look in different directories, users may want project-local or global availability, and copying is not the same maintenance choice as linking. This chapter compares those choices and explains how path guards, lockfile state, and audit records keep a persistent installation understandable without pretending that local state is a signed security attestation.

The adapter catalog turns portability into an explicit interface

Host agents do not share one universal convention for where skills live. The core therefore maintains an adapter catalog that associates each supported agent with a display name, a project-local skills directory, a global skills directory, and a way to detect whether that agent is present. The exact paths are an implementation detail; the architectural point is that the CLI does not ask each skill author to understand every host layout. It resolves one agent choice into a destination contract.

That contract absorbs two kinds of variation. First, agents differ in where a project-specific skill should be placed and where a user-wide skill should live. Second, agents differ in how the CLI can recognize that they are installed. A catalog entry can describe both without changing the content package itself. The same skill can therefore be selected once and delivered to several agents, while the adapter layer handles the host-specific placement.

This is portability in the engineering sense, not a promise that every agent will interpret the instructions identically. The CLI can know that a directory is the expected place for an agent's skills; it cannot guarantee how that agent prioritizes a skill, how it combines it with its own system instructions, or whether every supported feature is understood. The adapter is an interface between the repository and the host, not a universal compatibility certificate. Its value is that the uncertainty is localized: the repository can update one adapter contract when a host layout changes instead of scattering that knowledge through every skill package.

Scope changes the meaning of that interface. A project-local installation travels with one repository and can be reviewed alongside the work it affects. It is a natural choice when a team wants a shared workflow for a particular codebase or when the skill depends on project conventions. A global installation is available across projects for that user, which is convenient for general practices but increases the number of contexts in which the skill may influence work. The broader scope also makes a stale or unsuitable skill more widely relevant.

The distinction is operational rather than moral. Global is not automatically unsafe, and local is not automatically correct.