Terminology
Every term used across the curriculum, defined in one place.
Terms are grouped by theme rather than alphabetically: the groupings reflect how the concepts relate, which is usually more useful than a straight A–Z lookup. Sections collapse so you can skim the themes and open the one you need — or hit Expand all and use your browser's find-in-page.
Skills and plugins
Skill
A small, named, versioned bundle of instructions and supporting context that a coding agent loads on demand to do one specific job well. A skill is not a plugin, a tool call, or a running service: it is a folder the agent reads when it recognizes that the file's description matches the work in front of it. Skills are agent-agnostic and load lazily, only when the agent judges them relevant.
SKILL.md
The single file that defines a skill. It has a YAML frontmatter block (at minimum, name and description) and a Markdown body that contains the agent's instructions. The frontmatter is for finding the skill; the body is for using it. A skill folder can also carry scripts and resources alongside its SKILL.md.
Plugin
The publishable and installable package unit in Tessl, also called a Tessl package. A plugin is a versioned bundle of reusable, agent-agnostic context: it can hold one or more skills, rules, and documentation. It has a name in the format workspace/plugin-name, a semver version, and a manifest at .tessl-plugin/plugin.json. Versioning, distribution, and quality signals sit on the plugin, not inside any individual skill. Like packages in npm or pip, plugins are versioned and dependency-managed, so they can be safely updated as systems evolve.
Note on naming. The CLI renamed tile to plugin in v0.81.0. Older material may still say "tile"; the current term is plugin.
Rules
Mandatory steering the agent should always follow. Unlike skills, which load lazily when relevant, rules are pushed eagerly into the agent's context on every turn. A plugin can ship rules alongside its skills.
Workspace
A named namespace on the Tessl registry: the container for a team's or organization's plugins. Workspaces carry role-based access control (member, publisher, manager, owner), scope what their members can publish and install, and are the unit of governance when a team adopts skills at scale.
Registry
The central store where plugins are published, versioned, and discovered. The Tessl registry hosts plugins at workspace/plugin-name@version and is what tessl install, tessl search, and tessl plugin info operate against. Plugins carry their eval scores in the registry, so consumers can judge quality before installing.
Skills library
A plugin that bundles multiple related skills. The criteria for putting skills together in one plugin: shared audience, shared problem space, and shared release cadence. If two skills would always be updated independently, they belong in separate plugins.
Projects and repositories
Tessl project
The stable home for Tessl in a Git repository. A Tessl project identifies that repository and acts as the anchor for the eval runs and other repository-connected data attached to it. tessl project create creates one.
Project link
The link stored in tessl.json that connects a repository to a Tessl project. tessl init writes this manifest and configures the agent's MCP integration.
Repository
A Git repository containing your code and history.
Codebase
The code inside a repository.
Agents and models
Agent / coding agent
Software that uses an LLM to help a developer work directly in a codebase: reading files, running commands, making edits, and producing output based on context and instructions. Claude Code, Cursor, Codex, and Gemini CLI are examples. Skills are agent-agnostic: Tessl installs the same plugin into whichever agent a developer uses.
LLM (large language model)
The underlying model that powers a coding agent's reasoning. The agent is the product; the LLM is the engine inside it. When a skill's SKILL.md is loaded, it becomes part of the LLM's context for that turn.
Model
A specific, versioned LLM release: for example, claude-sonnet-4-6. The same skill performs differently across models, which is part of why behavioral evals matter. Eval results are always relative to the model version the run used.
Frontier model
The most capable publicly available models at a given point in time, typically released by leading AI labs (Anthropic, OpenAI, Google DeepMind). Frontier models change frequently. Skills should be written to be robust to model variation rather than tuned for one specific release.
Context window
The maximum amount of text (measured in tokens) that an LLM can hold in working memory during a single turn. SKILL.md files are loaded into the agent's context window when triggered. Well-written skills are deliberately concise: a SKILL.md that grows to thousands of words is displacing other useful context and will be read less reliably.
Harness
The program that wraps the model: it handles context assembly, tool calls, output parsing, permissions, and the overall conversation loop. Claude Code and Cursor are harnesses. Two harnesses running the same model can behave very differently.
MCP (Model Context Protocol)
An open standard for how agents access external tools and context sources. Tessl's integration with Claude Code uses MCP: tessl init --agent claude-code registers the Tessl MCP server so that installed skills are discoverable by the agent's routing logic.
Evaluation
Eval / evaluation
A structured measurement of a skill's quality. Tessl supports two kinds, review evals and task evals, which answer different questions about the same skill.
Review eval
A fast, structural quality check. Review evals look at the shape of a SKILL.md: is the frontmatter correct? Is the description specific? Are the instructions clear? Is anything missing? They score out of 100 and run automatically on every plugin publish. Run one by hand with tessl review run (an async command: tessl review run queues it, tessl review view --last reads the report; previously tessl skill review). Cheap to run, but they cannot see whether the skill behaves correctly. Think of it as a linter with opinions.
Task eval (scenario eval)
A behavioral quality test. A task eval runs a skill against a set of scenarios (real-looking inputs) and grades the output against a rubric. Slower and deeper than a review eval. It measures whether the skill does the job, not whether it is well-formed. The two signals are complementary; you need both.
Scenario
A self-contained behavioral test case for a skill. Each scenario has three parts: a task.md (the prompt the agent receives), a criteria.json (the weighted rubric used to grade the output), and a scenario.json (the fixture: which repo, which commit, which files to expose). Scenarios can be generated from real commits or written by hand. Editing the rubric is the step that makes a generated scenario set yours.
Rubric
The set of weighted criteria used to grade a task eval run. Each item has an ID, a description, and a weight. Higher-weight items matter more to the overall score. The rubric is the part of a scenario you should always review by hand: a machine-generated rubric is a starting point, not a spec.
Baseline
In a task eval run, the variant that solves each scenario without the skill loaded. Baseline runs by default. When you supply the skill as context (by pointing tessl eval run at the plugin directory, or passing --context), Tessl also runs a with-context variant. The difference between baseline and with-context is the measurable value the skill adds. A skill that does not beat baseline on a scenario is not helping on that case.
Eval gate
A CI check that blocks a publish or merge if a skill's review eval score falls below a configured threshold (tessl review run --threshold 80). Eval gates are the quality enforcement mechanism for a governed workspace.
Governance and organization
AI Enablement Lead (AEL)
A role, not a job title, for the person or small team responsible for how an organization adopts, governs, and scales AI coding tools. AELs own the workspace, set quality thresholds, assess posture, and manage the long tail of skills across producers.
Posture
An organization's maturity and readiness around skill governance, assessed across dimensions such as visibility, quality, ownership, lifecycle, and distribution. Posture is not binary: it is a picture that improves over time.
Publisher
The workspace role that allows a member to publish plugins into the workspace. Limiting publisher access to a trusted few is a key governance lever: it keeps the registry curated rather than accumulating every experiment.
Engineering disciplines
Context engineering
The discipline of choosing what the model sees on each turn: skills, rules files, retrieved files, examples. It is the primary subject of this curriculum.
Harness engineering
The discipline of shaping the program around the model: tool definitions, permissions, output parsing, MCP servers.
Loop engineering
The discipline of getting multi-turn execution to converge: planning structure, self-correction, evals as feedback, iteration caps.
Conventions and standards
Conventional Commits
A widely-used specification for structured commit messages, of the form <type>(<optional scope>): <subject>. Types include feat, fix, refactor, docs, test, chore, and perf. The commit-conventions skill used throughout the curriculum produces messages in this format. Full spec at conventionalcommits.org.
Semver (semantic versioning)
The versioning scheme used for plugins: MAJOR.MINOR.PATCH. Increment PATCH for backwards-compatible bug fixes, MINOR for new skills or backwards-compatible additions, and MAJOR for breaking changes.