--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/04_content-model.md	Tue Mar 24 22:34:43 2015 -0700
@@ -0,0 +1,39 @@
+---
+title: Content Model
+---
+
+PieCrust is a CMS, _i.e._ a _Content Management System_. It looks, by default,
+like a simple blog engine, but it can really handle any arbitrary set of
+content. You need however to define what that content is. This is the _content
+model_.
+
+The [default content model][def] is what you get out of the box. It defines a
+simple blog site where you can have pages and posts.
+
+To create more complex or customized websites, you can define another content
+model by specifying [sources][], [routes][], and [taxonomies][] in the [site
+configuration][siteconf]:
+
+* [Sources][] are how you tell PieCrust where to find your content. It defines
+  in what sub-directories it will find what kind of pages, with what kind of
+  naming convention, and what kind of metadata. In theory, sources can also
+  provide pages from other places than the file-system -- like a network
+  connection or a ZIP file or a database or whatever.
+
+* [Routes][] define how the content returned by the sources is exposed to your
+  visitors. This defines both the URLs for that content, and the place on disk
+  where it will be baked to.
+
+* [Taxonomies][] define special types of metadata on which PieCrust will create
+  index pages. You can generally define any type of metadata on your pages in a
+  completely free-form way, without having to declare anything, but in some
+  situations -- like blog post categories -- you want PieCrust to create a page
+  that lists all pages assigned with each category.
+
+
+[def]: {{docurl('content-model/default-model')}}
+[sources]: {{docurl('content-model/sources')}}
+[routes]: {{docurl('content-model/routes')}}
+[taxonomies]: {{docurl('content-model/taxonomies')}}
+[siteconf]: {{docurl('general/website-configuration')}}
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/04_content-model/01_sources.md	Tue Mar 24 22:34:43 2015 -0700
@@ -0,0 +1,48 @@
+---
+title: Sources
+---
+
+_Sources_ are the part of a content model that specifies where PieCrust will
+find your content. This is done in the website configuration:
+
+    site:
+        sources:
+            foo:
+                type: posts/flat
+            bar:
+                type: default
+
+As shown above, the `site/sources` setting must contain a map of the sources you
+want: each source's name, followed by its settings.
+
+Usually, a source will be a directory in the website's root directory, in which
+you'll put text files often following some kind of naming convention.
+
+Source settings depend on the _type_ of the source, but all sources have some
+common settings. All settings are optional except for `type`.
+
+* `type`: This defines what kind of backend you want for a source. See the [list
+  of sources][refsrc] for the source types that ship with PieCrust. You can also
+  get more source types by installing plugins.
+
+* `fs_endpoint`: Most sources will read their data from the file-system. By
+  default, the file-system directory will be a sub-directory of the website's
+  root with the same name as the source's name. This can be customized with the
+  `fs_endpoint` setting, which is specified relative to the website root.
+
+* `data_endpoint`: Most sources will also want to expose all their pages to a
+  template data endpoint, so you can easily iterate on them -- for example to
+  show an archive or a site map. By default, this endpoint is the same as the
+  source's name, but it can be customized with the `data_endpoint` setting.
+
+* `data_type`: The data that's exposed through the `data_endpoint` is an
+  `iterator` by default, which means it's a simple flat list of pages. There are
+  other possible forms, like for example a blog archive, which is a bunch of
+  different iterators rolled into the endpoint, with easy ways to list pages by
+  year or by month.
+
+For an example of sources configuration, see the [default content model][def].
+
+[refsrc]: {{docurl('reference/sources')}}
+[def]: {{docurl('content-model/default-model')}}
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/04_content-model/02_routes.md	Tue Mar 24 22:34:43 2015 -0700
@@ -0,0 +1,53 @@
+---
+title: Routes
+---
+
+_Routes_ define how your content is exposed to your visitors. This affects the
+structure of your baked output, which affects the URLs of your pages.
+
+Routes are defined as a list of entries under `site/routes`:
+
+    site:
+        routes:
+            - url: /foo/%slug%
+              source: something
+            - url: /bar/%year%/%month%/%slug%
+              source: otherthing
+
+Each route must define the following settings:
+
+* `url`: That's the pattern to use to figure out where the baked page will go.
+  You obviously need to use _placeholders_ here (things of the form `%blah%`)
+  otherwise all your pages would be overwriting each other -- although PieCrust
+  would warn you about that. The available placeholders depend on the source
+  tied to this route. See the [list of available sources][refsrc] to see what
+  kind of routing information they expose.
+
+* `source`: This defines the source that this route is defined for. Only pages
+  coming from that source will have their bake output generated from this route.
+
+Optional settings include:
+
+* `taxonomy`: If this route is meant to match a taxonomy index page, you have to
+  define which taxonomy that is.
+
+* `page_suffix`: Pages that create _sub-pages_ (_e.g._ when using pagination)
+  will append this suffix to the route. By default, this is `/%num%`. You _must_
+  use the `%num%` placeholder somewhere in this setting.
+
+
+## Route ordering
+
+The order of the routes is important, because the first matching route for a
+given page will be the one that's used. This is especially important when
+running `chef serve`, or running PieCrust as a dynamic CMS.
+
+This is because the incoming URL requested by a visitor's browser will be
+matched against each route starting from the first one in the list. For each
+route that matches, an actual page will be looked for, and the first one to be
+found will be returned for that URL.
+
+
+
+[refsrc]: {{docurl('reference/sources')}}
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/04_content-model/03_taxonomies.md	Tue Mar 24 22:34:43 2015 -0700
@@ -0,0 +1,54 @@
+---
+title: Taxonomies
+---
+
+Taxonomies in PieCrust define pieces of page metadata for which you want to have
+_index pages_ created for you.
+
+## Taxonomy example
+
+A common example of taxonomies is the "_category_" of a blog post. If you have
+blog posts in categories "_recipes_", "_kitchen tips_" and "_restaurant
+reviews_", you want 3 pages to be created automatically for you so that someone
+can see a list of all recipes, kitchen tips, and restaurant reviews (and those
+pages may have _sub-pages_ if they're using pagination to only show 10 or so at
+a time).
+
+But if you write a new blog post and put it in category "_utensil reviews_", you
+want a new page listing all utensil reviews to also be created.
+
+You basically want PieCrust to "dynamically" generate those listing pages
+(called "_taxonomy index pages_") for each _value_ ever used in that given
+taxonomy.
+
+
+## Taxonomy configuration
+
+Taxonomies are defined under `site/taxonomies` in the website configuration:
+
+    site:
+        taxonomies:
+            categories:
+                multiple: true
+                page: pages:_cat.md
+            authors:
+                page: pages:_author.md
+
+These settings should be defined as a map. Each entry is the name of the
+taxonomy, and is associated with the settings for that taxonomy. Settings
+include:
+
+* `multiple`: Defines whether a page can have more than one value assigned for
+  this taxonomy. Defaults to `false` (_i.e._ only a single value can be
+  assigned).
+
+* `term`: Taxonomies are usually named using plural nouns. The `term` setting
+  lets you define the singular form, which is used to make some messages read
+  better.
+
+* `page`: Defines the page to use to generate the _index page_ for this
+  taxonomy. This is a [page reference][pageref].
+
+
+[pageref]: {{docurl('content-model/page-references')}}
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/04_content-model/04_page-references.md	Tue Mar 24 22:34:43 2015 -0700
@@ -0,0 +1,46 @@
+---
+title: Page References
+---
+
+There are a few places in PieCrust where you need to specify a reference to a
+page -- like for instance when defining taxonomies and specifying a custom index
+page.
+
+Page references are written using the following format:
+
+    source_name:path/to/page.ext
+
+This means:
+
+* `source_name`: The source in which to find the page.
+
+* `path/to/page`: A _source path_ to the page. This is usually just a
+  file-system relative path, starting from the file-system endpoint of the
+  source, but some sources may have slightly different ways to specify a
+  relative path. Refer to the source's documentation.
+
+* `.ext`: The extension to use. If you want to the user to have some freedom in
+  the matter -- like for example letting the user use either a `.md` or
+  `.textile` extension to use either Markdown or Textile syntax -- then you can
+  use `.%ext%`. This will match any extension registered in the
+  `site/auto_formats` settings (see the [formatters documentation][fmt]).
+
+
+### Multiple matches
+
+It's possible to define a reference that will match multiple possible pages --
+in this case, it would resolve to the first found page. Just write additional
+page references, using `;` as a separator.
+
+For instance:
+
+    foo:something/whatever.md;bar:someting.md
+
+...would match `something/whatever.md` in source `foo` if it exists, otherwise
+it would match `something.md` in source `bar` if it exists. Otherwise, the page
+isn't found.
+
+This is especially useful for falling back to a page defined in a theme.
+
+[fmt]: {{docurl('content/formatters')}}
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/04_content-model/05_default-model.md	Tue Mar 24 22:34:43 2015 -0700
@@ -0,0 +1,126 @@
+---
+title: Default Content Model
+---
+
+The default content model that you get with PieCrust out of the box is a generic
+"blog engine" model. It can be configured, to a degree, using some simple
+website configuration settings that operate at a higher level about the content
+model.
+
+Understanding how this all work can be useful to understand how the PieCrust
+content model can be tweaked to one's liking.
+
+## Sources
+
+The default sources define the strict minimum for a personal website:
+"free-form" pages (`pages`) and blog posts (`posts`).
+
+    sources:
+      pages:
+        data_endpoint: site.pages
+        item_name: page
+
+Here's a breakdown of those settings:
+
+* The `pages` source is anchored at the default location, which is a
+  sub-directory with the same name as the source (`/pages`).
+* It's using the default source backend (named `default`) which just returns any
+  file inside its sub-directory as a page.
+* It exposes all those pages as a simple iterator (the default) at `site.pages`.
+* It defines the `item_name` so that you can prepare a new page with `chef
+  prepare page`.
+
+The `posts` sources is a bit more complicated:
+
+    sources:
+      posts:
+        type: posts/flat
+        fs_endpoint: posts
+        data_endpoint: blog
+        data_type: blog
+        default_layout: post
+        taxonomy_pages:
+          categories: pages:_category.%ext%;theme_pages:_category.%ext%
+          tags: pages:_tag.%ext%;theme_pages:_tag.%ext%
+        item_name: post
+
+Here's what this does:
+
+* The `posts` source is also anchored at the default location (`/posts`). But if
+  the `site/blogs` setting lists more blogs, each blog will be listed under
+  `/posts/<blogname>`, effectively changing the `fs_endpoint` setting.
+* It's using the `posts/flat` backend, which means blog posts should be named
+  with the date at the beginning of the filename. The `site/posts_fs` changes
+  this to `posts/<fsname>`.
+* All blog posts are exposed through the `blog` data endpoint, with a `blog`
+  data provider -- which means you can also access blog archives in addition to
+  a flat list of all blog posts. If the `site/blogs` setting lists more blogs,
+  each blog will have its `data_endpoint` set to its name.
+* The default layout to use for all blog posts is set to `post` instead of
+  `default`.
+* Taxonomy index pages are defined for `categories` and `tags`. They're set to
+  `_category.*` and `_tag.*` respectively, where the extension can be any of the
+  auto-formats (which means `.md` and `.textile` by default). They can also fall
+  back to the same pages defined in the current theme (whose source name is
+  `theme_pages`), which is what makes the default (built-in) PieCrust theme
+  work.
+
+
+## Taxonomies
+
+The default content model defines 2 taxonomies: categories and tags. Categories
+are meant to be exclusive, _i.e._ a blog post can only have one category. Tags
+are meant to be used more freely, where a blog post can be tagged with multiple
+terms.
+
+This shows up more or less like this in the website configuration:
+
+    taxonomies:
+      categories:
+        term: category
+      tags:
+        multiple: true
+        term: tag
+
+
+## Routes
+
+The default content model defines routes for the site's pages and blog posts
+roughly like such:
+
+    - url: /%path:slug%
+      source: pages
+      func: pcurl(slug)
+    - url: /%year%/%month%/%day%/%slug%
+      source: posts
+      func: pcposturl(year,month,day,slug)
+    - url: /tag/%tag%
+      source: posts
+      func: pctagurl(tag)
+      taxonomy: tags
+    - url: /category/%category%
+      source: posts
+      func: pccaturl(category)
+      taxonomy: categories
+    - url: /%path:slug%
+      source: theme_pages
+      func: pcurl(slug)
+
+Let's go through it:
+
+* The `pages` source is exposed in the most simple way: just a single route,
+  rooted to `/`. Whatever `slug` gets returned for a page (which is pretty much
+  the relative path of the page's file) will be its URL.
+* Blog posts (from the `posts` source) are exposed with a `/year/month/day/slug`
+  URL, which matches the type of routing metadata the `posts/*` sources offer.
+  If the `post_url` is set, the route will be changed accordingly. If there's
+  more than one blog in `site/blogs`, there will be more than one route for
+  posts, and the route will be rooted with `/<blogname>`.
+* There are then 2 routes for the taxonomies defined in the default content
+  model (tags and categories).
+* All routes define some URL functions for use in your pages and templates
+  (`pcurl` for pages, `pcposturl` for posts, etc.).
+* The last route is meant to match any page defined in the theme. It happens
+  last so that a page with the same relative path in your website will properly
+  override it.
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/99_reference/03_sources.md	Tue Mar 24 22:34:43 2015 -0700
@@ -0,0 +1,155 @@
+---
+title: "Appendix 3: Sources Reference"
+short_title: Sources Reference
+---
+
+Here are the page sources that come with PieCrust by default.
+
+
+## Default source
+
+The `default` source makes a page out of any file found in its file-system
+endpoint.
+
+* Type: `default`
+
+* Configuration settings:
+    * `fs_endpoint`: The directory (relative to the website's root) in which the
+      source will find page files. Defaults to the name of the source.
+
+* Metadata provided:
+    * `slug`: The "_slug_" of the page, which is in this case the relative path
+      of the page file from the file-system endpoint. If the file's extension is
+      on of the `site/auto_formats` (`.md`, `.textile`), the extension is
+      stripped from the slug.
+
+
+## Auto-configuring source
+
+The `autoconfig` source sets a page configuration setting on every page that it
+produces based on the relative path of each page file. This is useful if you
+want, for example, pages to be tagged or categorized based on any sub-directory
+they're in.
+
+* Type: `autoconfig`
+
+* Configuration settings:
+    * `fs_endpoint`: Same as for the `default` source.
+    * `setting_name`: Specifies what page configuration setting will be set from
+      the page file's path.
+    * `capture_mode`: Either `path`, `dirname`, or `filename`. This defines how
+      the page file's path should be parsed:
+        * `path` means the whole relative path will be parsed.
+        * `dirname` means the relative directory will be parsed.
+        * `filename` means only the filename will be parsed.
+    * `only_single_values`: The source will raise an error if the page is placed
+      in more than one sub-directory.
+    * `collapse_single_values`: If the page is placed inside a single
+      sub-directory, don't set the `setting_name` configuration setting to a
+      list with one value in it -- instead, set the configuration setting to
+      that value directly.
+
+* Metadata provided:
+    * `slug`: Same as for the `default` source.
+    * `config`: A page configuration fragment containing the `setting_name` and
+      its value extracted from the page's relative path.
+
+
+## Ordered source
+
+This source orders pages and sub-directories according to a numerical prefix.
+All sub-directory and file names must start with `XX_`, where `XX` is a number.
+The prefix is then stripped from the page slug, along with all prefixes from
+parent sub-directories. The end result looks much like a `default` source, but
+with the added ability to order things easily using the file-system.
+
+* Type: `ordered`
+
+* Configuration settings:
+    * `fs_endpoint`: Same as for the `default` source.
+    * `setting_name`: The page configuration setting in which the order value
+      will be stored. Defaults to `order`.
+    * `default_value`: The value to assign to `setting_name` in case no prefix
+      was found on a particular directory or file name. Defaults to `0`.
+
+* Metadata provided:
+    * `slug`: Same as for the `default` source. The prefixes with the order
+      values are stripped away.
+    * `config`: A page configuration fragment containing the `setting_name` and
+      its value extracted from the page file's name prefix.
+
+* Notes:
+    * A setting called `<setting_name>_trail` will also be created in each
+      page's metadata, which contains a list of all the order values starting
+      from the first sub-directory, all the way to the page's file name.
+
+    * Ordering pages can already be achieved easily with the `default` source,
+      by just assigning order values in pages' configuration headers and sorting
+      iterators based on that. The advantages over the `ordered` source are that
+      it's less strict, allows for multiple sort parameters, and it doesn't
+      require renaming files to re-order things.  The disadvantages are that
+      it's hard to see the overall order at a glance.
+
+
+## Blog posts sources
+
+There are 3 blog posts sources offering slightly different file structures:
+
+* `posts/flat`: Files must all be in the same directory, and be named
+  `%year%-%month%-%day%_%slug%`.
+* `posts/shallow`: Files must be in a sub-directory named after the year. Each
+  file must be named `%month%-%day%_%slug%`.
+* `posts/hierarchy`: File must be in a sub-directory named after the year, and a
+  sub-directory named after the month's number. Each file must be named
+  `%day%_%slug%`.
+
+You probably want to choose the correct file structure based on your personal
+tastes and blogging frequency. Putting all files in the same folder is a lot
+easier to manage, but quickly gets annoying if you post updates once a day or
+more, and end up with a thousand files in there after a few years.
+
+* Type: `posts/flat`, `posts/shallow`, or `posts/hierarchy`
+
+* Configuration settings:
+    * `fs_endpoint`: The directory, relative to the website root, in which posts
+      will be searched for.
+
+* Metadata provided:
+    * `year`, `month`, and `day`: The date components extracted from the page
+      file's path.
+    * `date`: The timestamp extracted from the date components.
+    * `slug`: Just like for the `default` source. This here is the part that
+      comes after the date prefix.
+
+* Notes:
+    * To specify the time of day of a blog post, set the `time` setting in the
+      page's configuration header.
+
+    * You can already assign date/times to pages in the `default` source by
+      using the configuration header. It however prevents you from seeing all
+      your blog posts in order when listing your files, and prevents you from
+      being able to have 2 different blog posts sharing the same slug/title.
+
+
+## Prose source
+
+This source is like a `default` source, but is meant for page with no
+configuration header. This is useful if you want to keep your pages completely
+clean of any PieCrust-isms of any kind -- just pure Markdown or Textile or
+whatever.
+
+* Type: `prose`
+
+* Configuration settings:
+    * Same as for the `default` source.
+    * `config`: The "page configuration recipe" for pages created by this
+      source. Right now, the only "dynamic" aspect you can give this is to set
+      the `title` to `%first_line%`, which means the title will be extracted
+      from the first non-blank line in the page file.
+
+* Metadata provided:
+    * Same as for the `default` source.
+    * `config`: The page configuration recipe set in the source configuration,
+      with any dynamic settings resolved.
+
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/99_reference/04_templating-data.md	Tue Mar 24 22:34:43 2015 -0700
@@ -0,0 +1,119 @@
+---
+title: "Appendix 4: Templating Data Reference"
+short_title: Templating Data Reference
+---
+
+When a page or layout gets rendered, it goes through a templating phase. During
+that phase, PieCrust builds the _template data_ that gets passed to the template
+engine.
+
+This page shows a list of all the data that gets created for this occasion. Note
+that most of this data is in fact created "on-demand" (_i.e._ lazily evaluated)
+so that you only pay the price of whatever you use.
+
+Note that you can inspect this data yourself by using the debug window.
+
+
+* `piecrust`: Contains data specific to PieCrust itself.
+
+    * `version`: The version number of PieCrust.
+
+    * `url`: URL to the official PieCrust website.
+
+    * `branding`: A short message saying "_Baked with PieCrust_", along with a
+      link to the official website.
+
+    * `debug_info`: If enabled, the debug window.
+
+* `page`: Contains the page's metadata. This is basically the page's configuration header, as you wrote it, plus any default values for things you omitted, and any additional values set by sources (like the `ordered` or `autoconfig` sources) or plugins.
+
+  Notable additional data includes:
+
+    * `url`: The URL of the page.
+    * `slug`: The slug of the page.
+    * `timestamp`: The UNIX timestamp of the page.
+    * `date`: The formatted (user-friendly) version of the page's timestamp,
+      according to the `site/date_format` setting.
+
+* `assets`: The list of assets for this page.
+
+    * It can be iterated upon, to list all assets.
+    * It can be accessed by name, to access a specific asset.
+
+* `pagination`: Gives access to a paginating version of the default source's
+  list of pages. The default source will be the first blog in the website, if
+  any (as defined by `site/blogs`). It can be overriden by setting the `source`
+  or `blog` setting on the current page, in which case a source of that name
+  will be used.
+
+  Note that the object returned by `pagination`, called a paginator, can also be
+  returned by other things, like the `paginate()` template function, for
+  instance. As such, it does not assume that the items it is paginating are
+  posts or pages.
+
+    * `has_more`: Whether there are more items.
+
+    * `items` (or `posts`): The list of items.
+
+    * `has_items`: Whether there are any items.
+
+    * `items_per_page`: Returns how many maxiumum items there are for each
+      sub-page. Can be overriden locally with the `items_per_page` setting in
+      the page configuration.
+
+    * `items_this_page`: Returns the number of actual items on the current
+      sub-page. This will always be `items_per_page` except for the last page
+      (which can be the first page).
+    
+    * `prev_page_number`: The previous sub-page number, if any.
+
+    * `this_page_number`: The current sub-page number. The first page is number
+      `1`.
+    
+    * `next_page_number`: The next sub-page number, if any.
+
+    * `prev_page`: The URL to the previous sub-page, if any.
+
+    * `this_page`: The URL to the current sub-page.
+
+    * `next_page`: The URL to the next sub-page, if any.
+
+    * `total_item_count`: The total number of items across all sub-pages.
+
+    * `total_page_count`: The total number of sub-pages.
+
+    * `next_item`: The next item, if any.
+
+    * `prev_item`: The previous item, if any.
+
+    * `all_page_numbers(radius)`: A function that returns a list of page
+      numbers. With no argument, this returns a list of all page numbers, from 1
+      to the last number. With an argument, this returns a subset of this list,
+      with a "radius" equal to the argument "around" the current sub-page.
+
+    * `page(index)`: Returns the URL of a sub-page of the given number.
+
+* `family`: Returns a piece of data that lets you access parents, siblings, and
+  children of the current page. This is only possible for page sources that
+  support hierarchical navigation (but most of those shipping with PieCrust do).
+
+    * `siblings`: Returns a list of the current page's siblings, _i.e._ pages on
+      the same "level" as the current one.
+
+    * `children`: Returns a list of the current page's children, _i.e._ pages
+      that are "under" the current page. In most cases, this means pages that
+      are in a sub-directory with the same name as the current page's file name.
+
+    * `root`: Returns the root of the current page's source, so that you can
+      traverse all pages in a hierarchical manner.
+
+    * `forpath(path)`: Returns the family data starting at the given relative
+      path.
+
+* All the website configuration is merged with the data.
+
+* All source data providers are also included. For example, in the default
+  content model, the `pages` source is exposed to `site/pages`, so using
+  `site.pages` through the template engine would return a complete list of all
+  the pages in your website.
+

--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/docs/docs/99_reference/05_asset-processors.md	Tue Mar 24 22:34:43 2015 -0700
@@ -0,0 +1,159 @@
+---
+title: "Appendix 5: Asset Processors"
+short_title: "Asset Processors"
+---
+
+Here's a list of the PieCrust pipeline's asset processors that ship with
+PieCrust by default.
+
+Configuration settings for asset processors must be defined in the website
+configuration, unless noted otherwise.
+
+
+## CleanCSS
+
+Compresses CSS files using the `cleancss` utility.
+
+Name: `cleancss`
+
+Configuration settings (under `cleancss/`):
+
+* `bin`: The name or path of the `cleancss` executable. Defaults to `cleancss`,
+  which means it's expected you have it in your `PATH`.
+
+* `options`: A list of miscellaneous options to pass to `cleancss`. Defaults to
+  `--skip-rebase`.
+
+
+## Compass
+
+A processor that runs `compass` as part of the bake.
+
+Name: `compass`
+
+Configuration settings (under `compass/`):
+
+* `enable`: This processor is disabled by default. You need to set this
+  setting to `true`.
+
+* `bin`: The name or path of the `compass` executable. Defaults to `compass`,
+  which means it's expected you have it in your `PATH`.
+
+* `frameworks`: The list of frameworks to enable.
+
+* `options`: A list of miscellaneous options to pass to `compass`. You can use
+  the placeholders `%out_dir%` and `%tmp_dir%` to refer to the temporary and
+  output directories of the current bake.
+
+Notes:
+
+* It's expected that the Compass configuration file is called `config.rb` and is
+  located in your website's root directory.
+
+* To troubleshoot any problems, run `chef` with the `--debug` option to see the
+  full command-line invocation of `compass`.
+
+
+## Concat
+
+A simple processor that concatenates multiple other files.
+
+The input for this processor must be a `.concat` file whose file name without
+the `.concat` extension will be the output file name. The contents must be a
+YAML configuration that lists the files to concatenate.
+
+So for instance, a `foo.js.concat` file will generate an output file named
+`foo.js`. If the concents of the `.concat` file are the same as below, it will
+end up being the concatenation of files `something.js` and `lib/vendor/blah.js`:
+
+    files:
+        - foo.js
+        - lib/vendor/blah.js
+
+Other settings are possible in the YAML file:
+
+* `path_mode`: Either `relative` or `absolute`. If `relative`, the `files` list
+  specifies files relative to the `.concat` file. Otherwise, they're relative to
+  the asset root directory.
+
+* `delim`: The delimiter string to use between each concatenated file. Defaults
+  to a line feed (`\n`).
+
+
+## Copy
+
+A simple processor that copies the input file to the same place (relative to the
+asset directory, and to the output directory).
+
+Name: `copy`
+
+
+## LessCSS
+
+Converts LESS CSS files into normal CSS.
+
+Name: `less`
+
+Configuration settings (under `less/`):
+
+* `bin`: The name or path of the `lessc` executable. Defaults to `lessc`,
+  which means it's expected you have it in your `PATH`.
+
+* `options`: A list of miscellaneous options to pass to `lessc`. Defaults to
+  `--compress`.
+
+
+## Sass
+
+Converts Sass files (`.scss`, `.sass`) into normal CSS.
+
+Name: `sass`
+
+Configuration settings (under `sass/`):
+
+* `bin`: The name or path of the `scss` executable. Defaults to `scss`,
+  which means it's expected you have it in your `PATH`.
+
+* `style`: The output CSS style. Defaults to `nested`.
+
+* `load_paths`: A list of additional include paths. Defaults to an empty
+  list.
+
+* `options`: A list of miscellaneous options to pass to `lessc`. Defaults to
+  an empty list.
+
+
+## Sitemap
+
+Creates a Sitemap file by transforming a `.sitemap` file into a `.xml` file of
+the same name with contents that match the Sitemap specification.
+
+The `.sitemap` must be a YAML file (_i.e._ something a bit like the website
+configuration file) that can contain either:
+
+* `locations`: A list of locations to include in the Sitemap file. Each location
+  must have a `url` setting. Optionally, they can have a `lastmod`,
+  `changefreq`, and/or `priority` setting. This is basically boiling down to
+  writing the Sitemap in YAML instead of XML.
+
+* `autogen`: This should be a list of page source names for which to
+  auto-generate the Sitemap. Each source listed here will have all its pages
+  included in the Sitemap. The `url` and `lastmod` of each entry will be set
+  accordingly to their corresponding page. Each page can define a `sitemap`
+  configuration setting to override or add to the corresponding entry.
+  
+
+## UglifyJS
+
+Compresses Javascript files using the `uglifyjs` utility.
+
+Name: `uglifyjs`
+
+Configuration settings (under `uglifyjs/`):
+
+* `bin`: The name or path of the `uglifyjs` executable. Defaults to `uglifyjs`,
+  which means it's expected you have it in your `PATH`.
+
+* `options`: A list of miscellaneous options to pass to `uglifyjs`. Defaults to
+  `--compress`.
+