pluginはビルド定義内において、外部のコードを使用するための根本的な手法である。pluginはタスクを実装するために用いられるライブラリとも言える。例えば、タスクを処理するmarkdownを記述するためのKnockoffを(pluginとして)使用することができる。pluginはsbt Settingsの1行を定義することができ、それらのsettingsは自動的にすべてのプロジェクト、もしくは明確に定義されていれば指定したprojectに追加される。例としては、'proguard'タスクや関連する(overrideされた)settingsをpluginは(あるプロジェクトに)追加する。Commandsはcommands settingによって追加される。そして、(sbt) 0.7.xにおいてはpluginはcommandsを追加することもできる。
共通のシチュエーションではレポジトリに公開されているバイナリのpluginsを使用する。project/pluginsを作る。そしてこれに、使いたいsbt plugins, 依存しているもの, 必要なレポジトリを記述する。
addSbtPlugin("org.example" % "plugin" % "1.0")
addSbtPlugin("org.example" % "another-plugin" % "2.0")
// plain library (not an sbt plugin) for use in the build definition
libraryDependencies += "org.example" % "utilities" % "1.3"
resolvers += "Example Plugin Repository" at "http://example.org/repo/"
pluginsを作るため・使うための更なる情報はページの残りを見て欲しい。
plugin定義は/project/ の中のひとつのprojectとなる。このプロジェクトのクラスパスは/project/ とプロジェクトのベースディレクトリ内のいくつかの.sbtファイルにあるビルド定義のために用いられるクラスパスとなる。また、このクラスパスは eval と set commands のためにも使用される。
特別なこととして、
1.project/ projectに記述した管理される依存性は（sbtに）引き出され、ビルド定義におけるクラスパス（例えば通常のプロジェクト）において利用することができる。
2.project/lib 内の管理されない依存性はビルド定義（通常のプロジェクト）に対して有効である。
3.project/ project 内のソースはビルド定義ファイルであり、管理される・されない依存性からビルドされたクラスパスを用いてコンパイルされる。
4.プロジェクトの依存性はproject/project/Build.scala に定義され、ビルド定義のソースに対して有効である。project/project はビルド定義のためのビルド定義として捉えて欲しい。
Plugin実装の名前を含む記述ファイルであるsbt/sbt.pluginsファイルはビルド定義のクラスパスを検索する。Pluginはモジュールであり、プロジェクトに自動的に追加されるsettingsを定義する。さらに、すべてのPluginモジュールにはevalがワイルドカードインポートされ、commandsや.sbtファイルがセットされる。Plugin実装はpluginをつくるために必ずしも必要ではない。しかしながら、Plugin実装はプラグイン利用者には便利であり、自動的という性質からいつも適切であるとは限らない。
リロードされたplugins commandsは/project/に対して現在のビルドに変化をもたらす。これにより、通常のプロジェクトのようなビルド定義プロジェクトを扱うことが可能になる。リロードはオリジナルのビルドに戻るような変化を返す。（←ここ訳わからん）plugin定義のプロジェクトに対するあらゆるセッションのsettingsは保存されず、削除される。
Note:ランタイムでは、すべてのビルドのためのすべてのpluginsはビルドのクラスローダーの親クラスロードとは分けてロードされる。（←ここ訳あやしい）