Tessl Academy Agent Enablement Curriculum
Reference

Skill modes — teach, lab, build, coach

Skills don't all do the same job. The four modes — Teaching, Lab, Build, Coaching — name the shapes and what each one is good for.

Not every skill is the same kind of thing. The skill that drives a lesson and the commit-conventions skill it teaches are both valid SKILL.md files, and they do completely different jobs. One teaches you something; one does work for you.

Naming the shapes helps you write the right kind of skill for the job in front of you, and it gives reviewers something to push back against when a skill is doing two things at once.

The four modes

Mode Learning phase What the user does What the skill provides
Teaching Discover Forms a mental model: meets the concept Pedagogy: reveals, withholds, narrates, role-plays
Lab Practice Rehearses and explores repeatedly in a safe space Environment: messy repo, history, fixtures to re-run
Build Apply / create Does real coding work to produce real output Tool: makes the agent effective at building
Coaching Reflect Gauges how well the work is going Behavior watcher: observes and feeds back continuously

A given plugin can contain skills from more than one mode. The Tessl Learn lesson plugins are mostly Teaching skills; the commit-conventions skill they introduce is a Build skill. The two are designed to be read by an agent at different points in the user's journey.

Teaching skills

A teaching skill drives a lesson. Its job is to pace the user: show them one thing at a time, wait for confirmation, ask comprehension questions, narrate what's happening underneath.

When to write one:

  • You want to onboard people to a tool, a convention, or a concept.
  • The "right" way to do the task involves several steps that would be confusing all at once.
  • You can describe what good understanding looks like, not just what good output looks like.

What goes in the body:

  • Numbered steps the agent should walk the user through.
  • Instructions to wait between steps ("Ask the user to confirm before moving on").
  • Prompts that check understanding rather than just dispense information.
  • Optional: a wrap-up summary the agent reads back at the end.

Example shape:

You are running a lesson. Walk the user through each step
conversationally. Wait for confirmation before moving on.

1. Ask them to do X. Wait.
2. Once they've done X, point them at Y. Explain why Y matters.
3. ...

The lesson walkthrough skills in this curriculum are Teaching skills. So is anything you'd write for "walk a new hire through this codebase" or "explain the deploy process when asked".

Lab skills

A lab skill provides an environment for hands-on practice: usually fixtures, a messy starting state, or a scripted scenario the user can run repeatedly without burning real-world stakes.

When to write one:

  • The thing you want to teach needs a realistic example to bite into.
  • The user doesn't have suitable example material of their own.
  • Replayability matters: they should be able to start over and try again.

What goes in the body:

  • Instructions to set up a working directory or fixture state.
  • References to bundled example files (in the plugin's examples/ or fixtures/).
  • A defined "starting line" and "finish line" so the user knows what they're aiming at.
  • Often: explicit guidance to the agent on not doing the work for the user.

Lab skills frequently ship with a fixture repo or pre-generated trace logs. A "find optimizations" exercise, for instance, would be backed by a Lab skill that includes synthetic agent session logs for the learner to analyze.

Build skills

The bread and butter. A build skill is what most people mean when they say "skill". The agent loads it when relevant and uses it to do real work on the user's actual code.

When to write one:

  • There's a task your team does often, and the agent doesn't currently do it the way the team would.
  • You can describe what "right" output looks like: format, content, edge cases.
  • You have a handful of real examples that show the desired shape.

What goes in the body:

  • A description that names the trigger condition precisely.
  • Numbered steps the agent should follow when triggered.
  • Constraints (formatting rules, what not to include).
  • A reference to bundled examples/ for the trickier cases.

Examples: commit-conventions, pr-description, release-notes, anything codebase-specific your team would normally write a wiki page about.

Coaching skills

A coaching skill watches behavior and feeds back. Unlike the other three, it isn't triggered by a user asking for something. It's triggered by the user finishing something and wanting to know how it went, or by running on a schedule against accumulated work.

When to write one:

  • The value of the skill comes from comparing many sessions or PRs, not one.
  • You want feedback that arrives after the work, not during it.
  • The output is an audit or recommendation, not a finished artifact.

What goes in the body:

  • Instructions to read recent agent logs / PRs / commits.
  • A scoring or categorizing rubric the agent applies to what it finds.
  • An output format the user (or another tool) can act on.

A "find optimizations" or "find automations" skill, one your coding agent runs across accumulated work rather than during a single task, is a coaching skill in this sense. It sits across the curriculum rather than inside any one lesson, and it converts past work into recommended future improvements.

How to pick the right mode

If you want to… Write a…
Onboard someone to a concept Teaching skill
Give someone a safe place to practice a technique Lab skill
Improve the agent at a recurring task Build skill
Surface patterns across many sessions Coaching skill

A skill that's trying to be two of these at once is usually a sign it should be split into a plugin of two skills with related descriptions but different triggers.

Where to go next