stdin

diff --git a/docs/sources/reference/builder.md b/docs/sources/reference/builder.md
index 4bb02e3..8a25c97 100644
--- a/docs/sources/reference/builder.md
+++ b/docs/sources/reference/builder.md
@@ -166,6 +166,110 @@ used tag does not exist, an error will be returned.
 The `MAINTAINER` instruction allows you to set the *Author* field of the
 generated images.
 
+## START
+
+`START` accepts a single argument -- any program path -- which is used to
+configure the image. Instructions may follow after this one and will execute
+after the program has successfully executed and terminated. A single layer is
+committed after `START` similarly to other `Dockerfile` instructions.
+
+`Program` refers to any binary, script, etc that exists in the build context
+that can be executed by a running container. A special container will be
+created for building, and the toolkit below, or the API, can be used to perform
+operations on the image.
+
+This instruction is complicated to use, but very powerful as it allows you to
+use any program or tool of your choice to configure images. Dockerfiles can be
+somewhat limiting for complicated build procedures, so this instruction exists
+to provide more power. If you are not sure you need this, stick with
+Dockerfiles.
+
+The program can leverage a toolkit that is injected into the container's
+filesystem at `{workdir}/docker-toolkit`, which will be at the head of the `PATH`
+environment variable for easy location. This toolkit is composed of several
+binaries which communicate with the Docker daemon and perform actions.
+
+The commands (each has a --help option):
+
+* `build`: process a Docker build repository (git, tar, directory) which will
+  also populate the image. This is called a "nested" or "recursive" build.
+* `envset`: tell the Docker engine to populate environment variables on `docker
+  run`.
+* `onbuild`: tell the Docker engine to perform an instruction when built on top
+  via a `FROM` instruction.
+* `download`: Download a file over http(s).
+* `cmd`: Equivalent to the `CMD` instruction.
+* `entrypoint`: Equivalent to the `ENTRYPOINT` instruction.
+* `expose`: Equivalent to the `EXPOSE` instruction.
+* `volume`: Equivalent to the `VOLUME` instruction.
+* `user`: Equivalent to the `USER` instruction.
+* `copy`: Equivalent to the `COPY` instruction. Allows populating the image
+  with files.
+* `mount`: mount a directory within the image container.
+* `run`: run a command on the image container.
+
+Likewise, the build context will be uploaded to `{workdir}/docker-context`,
+allowing you to perform standard operating system commands with it such as `rm`
+or `cp`.
+
+Both the context and the toolkit are removed after the build has finished.
+
+### Build Context
+
+The build context will live at `{workdir}/docker-build` and contain all the
+files from the host filesystem. You can manipulate these files just like you
+would with normal Unix tools such as `sed`, `awk`, or `perl`. What is available
+depends on the image you use to build with.
+
+### Build and Image Containers
+
+The outermost build process (in the event builds are nested) will create two
+containers: a "build" container containing the build context and the build
+toolkit, and an "image" container which represents the final image result. You
+can use the toolkit to program settings for the image as well as copy files
+from the build container to the image container or run statements there. The
+separation of concerns allows you to do preparatory work before shipping the
+files to the image.
+
+### WORKDIR
+
+As hinted at above, all context and toolkit files will be installed under
+`WORKDIR` if it is provided **before** the `START` instruction is executed.
+
+### Caching
+
+Cache keys are generated from the SHA-512 sum of the referenced script's
+contents. `START` generates one layer, just like most `Dockerfile`
+instructions.
+
+If you wish to leverage caching with multiple layers, consider dividing your
+program into multiple programs invoked by multiple `START` lines.
+
+###
+
+### Examples
+
+Let's imagine a build context that looks like this:
+
+    /myfile
+    /build.sh
+
+`build.sh` looks like this:
+
+    #!/bin/sh
+    copy myfile /
+
+Which uses the `copy` tool provided in the docker toolkit. This will already
+exist in the `PATH` environment variable so there is no need to fully qualify it.
+
+With this Dockerfile:
+
+    FROM busybox
+    START build.sh
+
+This copies the file `myfile` from the build container to `/` in the image
+container.
+
 ## RUN
 
 RUN has 2 forms:

• We should mount the toolkit and context dirs instead of copying them in - it'll be easier/faster
• The toolkit/build-context should be placed outside of the working dir so we don't run the risk of overlaying a user's file/dir - granted the odds are slim they would name something docker-toolkit, but ya never know.
• Not sure why we would mount them local to {workdir} instead of someplace static - like "/". As people "cd" around in their script it would be nice if they didn't have to think too hard about where to find things - in particular, if they want to copy stuff from the build context.
• "Build Context" says "all files from the host filesystem" - I think you mean all files from the build context, right?
• when you talk about using things like "rm" and "cp", are you suggesting they can use those to manipulate files in the target container? This is running in the build container, right?
• I think you may need to explain why this is needed - IOW, what you can do with this that you can't do with the existing features. In particular, what if we mounted the build-context and toolkit dirs into the target container - what would be missing if they did used "RUN" ? Is it just the need to have the script's dependencies like ruby, python?

• We should mount the toolkit and context dirs instead of copying them in - it'll be easier/faster
• The toolkit/build-context should be placed outside of the working dir so we don't run the risk of overlaying a user's file/dir - granted the odds are slim they would name something docker-toolkit, but ya never know.
• Not sure why we would mount them local to {workdir} instead of someplace static - like "/". As people "cd" around in their script it would be nice if they didn't have to think too hard about where to find things - in particular, if they want to copy stuff from the build context.
• "Build Context" says "all files from the host filesystem" - I think you mean all files from the build context, right?
• when you talk about using things like "rm" and "cp", are you suggesting they can use those to manipulate files in the target container? This is running in the build container, right?
• I think you may need to explain why this is needed - IOW, what you can do with this that you can't do with the existing features. In particular, what if we mounted the build-context and toolkit dirs into the target container - what would be missing if they did used "RUN" ? Is it just the need to have the script's dependencies like ruby, python?

Ok I will refactor. No disagreements.

Ok I will refactor. No disagreements.