anchor.diff:      depends_on: "a"
   ```
   
  -- adding an explicit empty dependency ensures that a step isn't dependent on any other and will run immediately at the start of the build
  +In the above example, the second command step (b) will not run until the first command step (a) has completed. Without the `depends_on` attribute, and given enough agents, these steps would run in parallel.
  +
  +To ensure that a step is not dependent on any other step, add an explicit empty dependency with the `~` character. This also ensures that the step will run immediately at the start of the build:
   
   ```yml
   steps:
  
positive.code:   - command: "d.sh"
  ```
  
  - block steps perform the same function, as well as requiring the unblocking either manually or via an API call
  
  - if you are collecting information with your block steps using the `prompt` or `fields` attributes, but don't require the actual blocking behaviour, you can use an input step
  
  ```yml
  steps:
    - input: "Ask a question"
  ```
  
  - same functionality as the block step, but no implicit dependencies are automatically applied to input steps
  
  ## defining explicit dependencies
  
  - the `depends_on` attribute can be added to all step types
  - add a dependency of another step
  
  ```yml
  steps:
  
negative.code:     depends_on: ~
  ```
  
  Even though the second command step in the above example is after a wait step, the empty dependency directs it not to wait until after the `wait` step is complete. Both commands steps will be available to run immediately at the start of the build. 
  
  ## order of operations
  
  - `if` then `depends_on` then `concurrency`
  - if the step you're dependent on doesn't exist for any reason, the current step will run as soon as the rest of the jobs complete
  
  ## Allowing dependency failures
  
  You can add the `allow_dependency_failure` attribute to any step. If there is a dependency failure - the dependency doesn't exist - the next step will still run.
  
  However, even if you continue to run the next step, if there are any failures at all, the build will still end up failing.
  
  This pattern is often used to run steps like code coverage or annotations to the build log that will give insight into what failed.
  