anchor.diff:  reference as you add elements to the release.
   
   Go through any scripts you have created and note the files cited by each script.
  +_note package path_ and _go through all job templates_.
   The names of these files must be added to the `packages` block of the job spec.
   In our example, they are `ardo_web` and `ruby_1.9.3`.
   
  
positive.code: 6 directories, 1 file
  </pre>
  
  ## <a id="..."></a> Create the Job Skeleton ##
  
  For each piece of software you include in a release, you create a job.
  
  When you first create it, the job is a _skeleton_: an empty structure to be filled up
  as release creation progresses.
  
  The example release only includes one job.
  
negative.code: 1 directory, 2 files
  </pre>
  
  ### <a id="..."></a> Create control script for the jobs  ###
  
  Every deployed app must have a way to start and stop.
  You provide that in a BOSH release by writing a control script that
  includes a start command and a stop command.
  The script is an ERB template stored in the `templates` directory for the relevant job.
  At compile time, BOSH transforms templates into files which
  eventually reside on the VMs where the deployed software runs.
  
  In production situations, start and stop commands can be required to turn more things on and off
  than the simple commands in our example do.
  Control scripts can be the source of unexpected behavior that you discover while testing your dev releases.
  When that happens, you refine your scripts and iterate.
  For these reasons, writing scripts is typically one of the heavier tasks entailed in creating a release.
  
  Create the control script and save it as `ctl.erb` in the `templates` directory.
  
  ### <a id="..."></a> Update the job specs  ###
  
  The `spec` file is where metadata about your job resides.
  
  You now possess two pieces of information which must be recorded in that metadata.
  
  