Mysite PDF on Plone, Zope and the CMF has a useful description on page 14 of the role of layers and skins:

This is a concept to extend name/method look up that the CMF adds to Zope. I like to think of this as having multiple
different search paths to choose from. Suppose you have a number of folders (or layers as they are called in the
context of skinning) f1, f2, ..., fn holding different versions of the same set of methods (but there is no need to
have each method in each folder). Now you define a skin by saying: for skin A first look in f1 , then look in f2 , then
in f3 whereas skin B might be defined as: first look in f2 , then in f3 , then in f1 and so on. That way you can
provide, e.g., different designs to choose from (for example by having different style sheets in the different folders).
But the concept is more powerful than to just provide different designs. In principle you can use it to provide multiple
object behaviour , meaning that you can make objects behave differently in response to particular method calls if the
method is implemented to do different things in the different skin folders.
Under the hood, the skins tool works by extending the acquisition context of all objects within a CMF site. But you
cannot tell this from looking at the URL in your browser, because this is done "silently" when traversing a so-called
SkinnableObjectManager , a class that the PloneSite class itself inherits from.

There is also a useful discussion from Andy McKay's book, referenced here, on skins and layers.

Set Debug Mode in Plone

Firstly, set the debug option in buildout.cfg to on (or do this directly in the zope.conf file).

Secondly, from the Zope Management Interface screens look for three tools:-

• portal_css
• portal_javascript
• portal_kss

In each case, tick the box to enable debug/development mode.

Buildout Options

When you run:-

./bin/buildout -h

this is what you get:-

Usage: buildout [options] [assignments] [command [command arguments]]

Options:

  -h, --help

     Print this message and exit.

  -v

     Increase the level of verbosity.  This option can be used multiple times.

  -q

     Decrease the level of verbosity.  This option can be used multiple times.

  -c config_file

     Specify the path to the buildout configuration file to be used.
     This defaults to the file named "buildout.cfg" in the current
     working directory.

  -U

     Don't read user defaults.

  -o
  
    Run in off-line mode.  This is equivalent to the assignment 
    buildout:offline=true.

  -O

    Run in non-off-line mode.  This is equivalent to the assignment 
    buildout:offline=false.  This is the default buildout mode.  The
    -O option would normally be used to override a true offline
    setting in a configuration file.

  -n

    Run in newest mode.  This is equivalent to the assignment
    buildout:newest=true.  With this setting, which is the default,
    buildout will try to find the newest versions of distributions
    available that satisfy its requirements.

  -N

    Run in non-newest mode.  This is equivalent to the assignment 
    buildout:newest=false.  With this setting, buildout will not seek
    new distributions if installed distributions satisfy it's
    requirements. 

  -D

    Debug errors.  If an error occurs, then the post-mortem debugger
    will be started. This is especially useful for debuging recipe
    problems.

Assignments are of the form: section:option=value and are used to
provide configuration options that override those given in the
configuration file.  For example, to run the buildout in offline mode,
use buildout:offline=true.

Options and assignments can be interspersed.

Commands:

  install [parts]

    Install parts.  If no command arguments are given, then the parts
    definition from the configuration file is used.  Otherwise, the
    arguments specify the parts to be installed.

    Note that the semantics differ depending on whether any parts are
    specified.  If parts are specified, then only those parts will be
    installed. If no parts are specified, then the parts specified by
    the buildout parts option will be installed along with all of
    their dependencies.

  bootstrap

    Create a new buildout in the current working directory, copying
    the buildout and setuptools eggs and, creating a basic directory
    structure and a buildout-local buildout script.

  init

    Initialize a buildout, creating a buildout.cfg file if it doesn't
    exist and then performing the same actions as for the buildout
    command.

  setup script [setup command and options]

    Run a given setup script arranging that setuptools is in the
    script's path and and that it has been imported so that
    setuptools-provided commands (like bdist_egg) can be used even if
    the setup script doesn't import setuptools itself.

    The script can be given either as a script path or a path to a
    directory containing a setup.py script.
    

Plone 3 Setup

One time only

Get python 2.4 something.

$> wget http://peak.telecommunity.com/dist/ez_setup.py
$> python ez_setup.py
$> easy_install ZopeSkel

• PEAK


• ZopeSkel

Do this for each project

paster create -t plone3_buildout 

• Paster

At this point you are asked lots of questions for example about
the path where zope/plone is to be or is already installed
the user name/password for the install, the port number etc.
and some options about debug settings.
This information is used ot build the buildout.cfg file.

After this runs, you have a bootstrap.py file, and src and product directories, and a buildout.cfg file and a var file, all of which are empty.

Then:

cd 
python bootstrap.py

After running bootstrap you have an eggs folder, a develop-eggs folder, a parts folder, and a bin folder. The eggs folder contains some of the PEAK tools:- the setuptools egg and the zc.buildout eggs. The bin folder contains the buildout executable. The parts folder is empty, as is the develop-eggs folder.

• zc.buildout

You are now ready to run the buildout, but at this point it may be worthwhile reviewing the buildout to see if any changes are merited. Possibly none are. Also note, you can run the build out over and over again and it will not eat your Data.fs file, the holy of holies of zope/plone development.