Agent Skills

Agent Skills

Agent Skills allow you to extend Tabnine CLI with specialized expertise, procedural workflows, and task-specific resources. A "skill" is a self-contained directory that packages instructions and assets into a discoverable capability.

Skills

What are skills?

A skill is a reusable capability that the Tabnine Agent or a subagent can call when solving a task.

Examples of skills include summarization, testing, validation, and prompt composition or command composition:

Summarization:

Summarize this file for a code review.

Testing:

Generate unit tests for this function.

Validation:

Extract configuration values and validate them against a schema.

Command Composition:

Convert a natural language description into a CLI command.

Skills can be combined: a subagent might chain several skills together to complete a higher-level workflow.

How skills are invoked

In typical usage, skills are invoked implicitly:

• You describe what you want done in natural language.

• The agent selects one or more skills that match the request.

• The skills operate on your project files, external content, or prior conversation.

Extensions can register new skills, and those skills become available wherever the agent runs: in your terminal, inside supported IDEs, or as part of automated workflows.

Overview

Unlike general context files (such as TABNINE.md), which provide persistent workspace-wide background, skills represent on-demand expertise for specific types of tasks. This lets Tabnine CLI keep a large library of specialized capabilities – like security auditing, cloud deployments, or codebase migrations – without loading all of that detail all the time.

When your request matches a skill's description, Tabnine CLI can choose to use that skill, load its instructions, and apply them to your task.

Key Benefits

• Shared Expertise: Package complex workflows (like a specific team's PR review process) into a folder that anyone can use.

• Repeatable Workflows: Ensure complex multi-step tasks are performed consistently by providing a procedural framework.

• Resource Bundling: Include scripts, templates, or example data alongside instructions so Tabnine has everything it needs.

• Progressive Disclosure: Only skill metadata (name and description) is loaded initially. Detailed instructions and resources are only disclosed when Tabnine explicitly activates the skill, saving context tokens.

Skill Discovery Tiers

Tabnine CLI discovers skills from three primary locations:

1. Workspace Skills -- Located in .tabnine/skills. Workspace skills are typically committed to version control and shared with the team.

2. User Skills -- Located in ~/.tabnine/skills. These are personal skills available across all your workspaces.

3. Extension Skills -- Skills bundled within installed extensions.

Precedence: If multiple skills share the same name, higher-precedence locations override lower ones: Workspace > User > Extension.

Managing Skills

In an Interactive Session

Use the /skills slash command to view and manage available expertise:

• /skills list (default): Shows all discovered skills and their status.

• /skills link <path>: Links agent skills from a local directory via symlink.

• /skills disable <name>: Prevents a specific skill from being used.

• /skills enable <name>: Re-enables a disabled skill.

• /skills reload: Refreshes the list of discovered skills from all tiers.

From the Terminal

The tabnine skills command provides management utilities:

# List all discovered skills
tabnine skills list

# Link agent skills from a local directory via symlink
# Discovers skills (SKILL.md or */SKILL.md) and creates symlinks in ~/.tabnine/skills
# (or ~/.agents/skills)
tabnine skills link /path/to/my-skills-repo

# Link to the workspace scope (.tabnine/skills or .agents/skills)
tabnine skills link /path/to/my-skills-repo --scope workspace

# Install a skill from a Git repository, local directory, or zipped skill file (.skill)
# Uses the user scope by default (~/.tabnine/skills or ~/.agents/skills)
tabnine skills install https://github.com/user/repo.git
tabnine skills install /path/to/local/skill
tabnine skills install /path/to/local/my-expertise.skill

# Install a specific skill from a monorepo or subdirectory using --path
tabnine skills install https://github.com/my-org/my-skills.git --path skills/frontend-design

# Install to the workspace scope (.tabnine/skills or .agents/skills)
tabnine skills install /path/to/skill --scope workspace

# Uninstall a skill by name
tabnine skills uninstall my-expertise --scope workspace

# Enable a skill (globally)
tabnine skills enable my-expertise

# Disable a skill. Can use --scope to specify workspace or user (defaults to workspace)
tabnine skills disable my-expertise --scope workspace

Creating Skills

You can define skills either with Tabnine's help or manually, depending on how much control you want.

Option 1: Use a helper skill (recommended)

If your Tabnine CLI environment includes a helper skill such as skill-creator, you can ask Tabnine to scaffold a new skill for you:

1. Start an interactive Tabnine CLI session.

2. Describe the skill you want. For example:

   Create a new skill called "code-reviewer" that reviews pull requests and local changes.

3. Tabnine will:

   1. Create a new folder for the skill (for example, code-reviewer/).

   2. Add a SKILL.md file with the required metadata (name, description) and starter instructions.

   3. Optionally add common subfolders like scripts/, references/, and assets/.

You can then edit SKILL.md and add any supporting files you want Tabnine to use when this skill is active.

If you don't have a helper skill available yet, you can still create skills manually as described below.

Option 2: Create a skill manually

To define a skill by hand:

1. Create a folder for your skill, for example:

   my-new-skill/

2. Add a SKILL.md file inside that folder. At minimum it should include:

   --- name: my-new-skill description: > Short description of what this skill does and when Tabnine should use it. --- # My New Skill Explain how Tabnine should approach this kind of task. Include any steps, checklists, or rules that matter.

3. (Optional) Add subfolders for supporting resources:

   my-new-skill/ ├── SKILL.md ├── scripts/ # shell scripts, helpers, etc. ├── references/ # docs, guides, specs └── assets/ # templates, sample files

4. Place the skill folder in one of the discovery locations:

   • Workspace scope: .tabnine/skills/ in your project.

   • User scope: ~/.tabnine/skills/ in your home directory.

5. Reload skills:

   • In an interactive session: /skills reload

   • Or from the terminal: tabnine skills list (which will trigger discovery)

Once discovered, the new skill will appear in /skills list and can be enabled or disabled like any other skill.

Example: code-reviewer skill

Here is a concrete example of a SKILL.md for a code-reviewer skill that works both with local changes and remote pull requests:

---
name: code-reviewer
description: >
  Use this skill to perform a structured code review on either local changes
  or a remote pull request in this repository. Prefer it when the user asks
  for a code review, feedback on a PR, or an assessment of a set of changes.
---

# Code Reviewer Skill

This skill tells Tabnine how to review code in a way that is useful and
actionable for developers working in this repository.

When this skill is active, follow these guidelines.

## 1. Identify the review target

First, figure out what you should review:

- **Remote pull request**
  - If the user gives you a PR number, branch name, or URL, treat that as
    the primary review target.
  - Ask for clarification if the repository or provider (e.g., GitHub,
    GitLab, Bitbucket) is ambiguous.

- **Local changes**
  - If the user mentions “local changes”, “my current branch”, or similar,
    review the diff between the current branch and its main/base branch.
  - If the user specifies a subset of files or paths, limit the review to
    those.

Be explicit in your response about *what* you ended up reviewing.

## 2. What to look for

Prioritize:

1. Correctness and bugs.
2. Security and reliability.
3. Design and maintainability.
4. Readability and style.

For each significant issue, explain why it matters and suggest a concrete
improvement.

## 3. How to structure your review

Include:

1. A short summary.
2. High-level feedback.
3. File-by-file or topic-based comments.
4. An actionable checklist with must-fix vs. nice-to-have items.

## 4. Tone and communication

Be constructive, specific, and concise. Assume good intent from the author
and avoid restating the diff; focus on insight and guidance.

## 5. When information is missing

If you lack context, say what you’re missing, ask a small number of focused
questions, and avoid inventing files or changes you cannot see.