> For AI agents: the complete documentation index is available at /llms.txt, the full documentation bundle is available at /llms-full.txt.

# Using plugins directly from your repo

Instead of publishing plugins to the Tessl Registry, you can also check them directly into your repository. This is a simpler way to distribute plugins together with your code.

## When to check plugins into your repo vs using the registry

**Check plugins into your repo when:**

- You want a simple distribution method - plugins travel automatically with your code
- Context is tightly coupled to this specific codebase
- You don't need version management across multiple projects

**Use the Tessl Registry when:**

- You need centralized management and updates
- You want evaluation and review workflows
- You need automated distribution across multiple repositories
- You want to keep plugins up to date independently from code changes

## How it works

Repository-specific plugins are committed to your codebase and referenced in `tessl.json` with a `file:` source. Team members automatically get the plugin when they clone the repo and run `tessl install`.

## Setup

### 1. Create the plugin in your repository

<pre class="language-bash"><code class="lang-bash">cd my-repo
<strong>tessl plugin new --name myworkspace/my-plugin --path ./plugins/my-plugin
</strong></code></pre>

This creates the plugin structure for skills or rules:

```
my-repo/
├── plugins/my-plugin/
│   ├── .tessl-plugin/plugin.json
│   └── skills
│       └── my-plugin/
│          └── SKILL.md
│   └── rules/                 # This repo's conventions
│       └── standards.md
└── tessl.json
```

### 2. Install it locally

Add the plugin to your project by referencing it in `tessl.json` with a `file:` source:

```bash
tessl install file:./plugins/my-plugin
```

This updates your `tessl.json`:

```json
{
  "name": "my-project",
  "dependencies": {
    "myworkspace/my-plugin": {
      "version": "1.0.0",
      "source": "file:./plugins/my-plugin"
    }
  }
}
```

### 3. Commit both to version control

```bash
git add plugins/my-plugin/ tessl.json
git commit -m "Add repository-specific context plugin"
```

## Team workflow

When team members clone the repository:

```bash
git clone <repo>
cd <repo>
tessl install
```

The plugin installs automatically from the `file:` source in `tessl.json`. Everyone gets the same codebase-specific context.

## Updating the plugin

Changes to the plugin go through your normal code review process:

1. Edit plugin content (rules, skills)
2. Commit changes: `git commit -m "Update architecture docs"`
3. Create pull request
4. Team reviews context changes like code changes
5. Merge to main

Team members get updates when they pull and run `tessl install`.

## Benefits

- **Versioned with code** - plugin evolves alongside the codebase
- **Automatic distribution** - Team gets context when they clone
- **Code review** - Changes to patterns/architecture reviewed via PR
- **Private** - Context stays internal, no publishing needed
- **Self-documenting** - Codebase carries its own context

## Example: Monorepo workspaces

In monorepos, create workspace-specific plugins:

```
my-monorepo/
├── frontend/
│   ├── plugins/my-plugin/           # Frontend patterns
│   │   ├── .tessl-plugin/plugin.json
│   │   ├── skills/            # Frontend Testing methodology
│   │   └── rules/             # UI standards
│   └── tessl.json             # References frontend plugin
├── backend/
│   ├── plugins/my-plugin/           # Backend patterns
│   │   ├── .tessl-plugin/plugin.json
│   │   ├── skills/            # Database migration process
│   │   └── rules/             # Backend standards
│   └── tessl.json             # References backend plugin
└── shared/
    └── plugins/my-plugin/           # Cross-cutting concerns
        └── skills/            # Unified Code Review
```

Each workspace's `tessl.json` references its local plugin and any shared plugins:

```json
{
  "dependencies": {
    "myworkspace/frontend-context": {
      "source": "file:./plugins/my-plugin"
    },
    "myworkspace/shared-context": {
      "source": "file:../shared/plugins/my-plugin"
    }
  }
}
```

## Related

- [Developing plugins locally](/creating-skills-and-plugins/develop-and-test-locally.md) - Create and test plugins with local development workflow before checking them into your repo
- [Configuration files](/reference/configuration.md#plugin-configuration) - Complete plugin.json reference