diff --git a/src/main/g8/build.sbt b/src/main/g8/build.sbt
index 041288b..6a285ea 100644
--- a/src/main/g8/build.sbt
+++ b/src/main/g8/build.sbt
@@ -1,12 +1,81 @@
-val scala3Version = "3.4.1"
 
-lazy val root = project
-  .in(file("."))
-  .settings(
-    name := "$name$",
-    version := "0.1.0-SNAPSHOT",
+// The simplest possible sbt build file is just one line:
 
-    scalaVersion := scala3Version,
+scalaVersion := "3.4.1"
+// That is, to create a valid sbt build, all you've got to do is define the
+// version of Scala you'd like your project to use.
 
-    libraryDependencies += "org.scalameta" %% "munit" % "0.7.29" % Test
-  )
+// ============================================================================
+
+// Lines like the above defining `scalaVersion` are called "settings". Settings
+// are key/value pairs. In the case of `scalaVersion`, the key is "scalaVersion"
+// and the value is "3.4.1"
+
+// It's possible to define many kinds of settings, such as:
+
+name := "scala3"
+organization := "ch.epfl.scala"
+version := "0.1.0-SNAPSHOT"
+
+// Note, it's not required for you to define these three settings. These are
+// mostly only necessary if you intend to publish your library's binaries on a
+// place like Sonatype.
+
+
+// Want to use a published library in your project?
+// You can define other libraries as dependencies in your build like this:
+
+libraryDependencies += "org.scalameta" %% "munit" % "0.7.29" % Test
+
+// Here, `libraryDependencies` is a set of dependencies, and by using `+=`,
+// we're adding the scala-parser-combinators dependency to the set of dependencies
+// that sbt will go and fetch when it starts up.
+// Now, in any Scala file, you can import classes, objects, etc., from
+// scala-parser-combinators with a regular import.
+
+// TIP: To find the "dependency" that you need to add to the
+// `libraryDependencies` set, which in the above example looks like this:
+
+// "org.scala-lang.modules" %% "scala-parser-combinators" % "2.3.0"
+
+// You can use Scaladex, an index of all known published Scala libraries. There,
+// after you find the library you want, you can just copy/paste the dependency
+// information that you need into your build file. For example, on the
+// scala/scala-parser-combinators Scaladex page,
+// https://index.scala-lang.org/scala/scala-parser-combinators, you can copy/paste
+// the sbt dependency from the sbt box on the right-hand side of the screen.
+
+// IMPORTANT NOTE: while build files look _kind of_ like regular Scala, it's
+// important to note that syntax in *.sbt files doesn't always behave like
+// regular Scala. For example, notice in this build file that it's not required
+// to put our settings into an enclosing object or class. Always remember that
+// sbt is a bit different, semantically, than vanilla Scala.
+
+// ============================================================================
+
+// Most moderately interesting Scala projects don't make use of the very simple
+// build file style (called "bare style") used in this build.sbt file. Most
+// intermediate Scala projects make use of so-called "multi-project" builds. A
+// multi-project build makes it possible to have different folders which sbt can
+// be configured differently for. That is, you may wish to have different
+// dependencies or different testing frameworks defined for different parts of
+// your codebase. Multi-project builds make this possible.
+
+// Here's a quick glimpse of what a multi-project build looks like for this
+// build, with only one "subproject" defined, called `root`:
+
+// val scala3Version = "3.4.1"
+// 
+// lazy val root = project
+//   .in(file("."))
+//   .settings(
+//     name := "scala3",
+//     version := "0.1.0-SNAPSHOT",
+// 
+//     scalaVersion := scala3Version,
+// 
+//     libraryDependencies += "org.scalameta" %% "munit" % "0.7.29" % Test,
+//   )
+
+// To learn more about multi-project builds, head over to the official sbt
+// documentation at http://www.scala-sbt.org/documentation.html