Add placeholder TODOs into the User Guide (#35)

guide/annotations/cli.md

@@ -33,4 +33,6 @@ As with commands typically we also want to add a `description` that describes wh
     defaultCommand = GettingStarted.class, 
     commands = { GettingStarted.class, Tool.class })
 public class BasicCli {
-```
+```
+
+**TODO Write up the rest of the @Cli annotation**

guide/annotations/command.md

@@ -59,5 +59,8 @@ public class Tool { }
 
 Here we add our command to the `common` group, we also add it to the `bar` group which is a sub-group of the `foo` group.
 
-Note that since command and group names cannot contain whitespace **any** whitespace in the specified group names is interpreted as a separator and thus treated as a path to the actual group you want to place your command in.
+Note that since command and group names cannot contain whitespace **any** whitespace in the specified group names is interpreted as a separator and thus treated as a path to the actual group you want to place your command in.
+
+{% include alert.html %}
+You can also specify groups by using the [`@Group`](group.html) annotation or as part of the [`@Cli`](cli.html) annotation.
 

guide/annotations/discussion.md

@@ -18,4 +18,4 @@ To add a discussion section simply add the `@Discussion` annotated to a class li
 	"We can have as many paragraphs as we feel are necessary"})
 public class MyClass { }```
 
-The annotation takes a single `paragraphs` field which takes a `String[]` array where each entry in the array is treated as a separate paragraph.
+The annotation takes a single `paragraphs` field which takes a `String[]` array where each entry in the array is treated as a separate paragraph of discussion in the help output.

guide/annotations/group.md

@@ -5,4 +5,6 @@ title: Group Annotation
 
 ## `@Group`
 
-The `@Group` annotation is used to specify group information.  This may be done as an alternative or in addition to using the relevant fields of the [`@Command`](command.html) or [`@Cli`](cli.html) annotations to specify groups.
+The `@Group` annotation is used to specify group information.  This may be done as an alternative or in addition to using the relevant fields of the [`@Command`](command.html) or [`@Cli`](cli.html) annotations to specify groups.
+
+**TODO Write up this annotation**

guide/annotations/index.md

@@ -15,6 +15,7 @@ The following annotations are used to define the high level aspects of your CLIs
 - The [`@Option`](option.html) annotation defines fields of a class as denoting options
 - The [`@Arguments`](arguments.html) annotation defines a field of a class as denoting arguments
 - The [`@Cli`](cli.html) annotation defines a class as being a CLI which consists of potentially many commands
+- The [`@Group`](group.html) annotation defines a command group within a CLI
 - The [`@Parser`](parser.html) annotation defines the parser behaviour
 - The [`@DefaultOption`](default-option.html) annotation defines an `@Option` annotated field as being able to also be populated as if it were `@Arguments` annotated
 
@@ -28,4 +29,6 @@ The following annotations are used to define various restrictions on options and
 
 The following annotations are used to add additional help information to commands that may be consumed by the various help generators provided by Airline.
 
-**TODO** - List help annotations
+**TODO** - List help annotations
+
+- The [`@Discussion`](discussion.html) annotation adds extended discussion to an [`@Command`](command.html) annotated class

guide/annotations/parser.md

@@ -5,4 +5,8 @@ title: Parser Annotation
 
 ## `@Parser`
 
-The `@Parser` annotation is applied to classes also annotated with `@Command` to configure the parser behaviour for that single command.  It may also be used as an argument to the `@Cli` annotation (see the [CLI Annotation](cli.html) documentation) in order to configure parser behaviour for a CLI.
+The `@Parser` annotation is applied to classes also annotated with `@Command` to configure the parser behaviour for that single command when parsers are created using `SingleCommand.singleCommand()`.
+
+It may also be used as an argument to the [`@Cli`](cli.html) annotation in order to configure parser behaviour for a CLI.
+
+**TODO Write up @Parser annotation**

guide/index.md

@@ -200,7 +200,8 @@ For a more complex CLI we need to use the [`@Cli`](annotations/cli.html) annotat
     commands = { GettingStarted.class, Tool.class })
 ```
 
-This states that our CLI has a `name` of `basic` and that it consists of two commands - `GettingStarted.class` and `Tool.class`.   Each command itself needs to be appropriately defined with at minimum an `@Command` annotation as shown in the earlier `GettingStarted.java` example.
+This states that our CLI has a `name` of `basic` and that it consists of two commands - `GettingStarted.class` and `Tool.class`.   Each command itself needs to be appropriately defined with at minimum a `@Command` annotation as shown in the earlier `GettingStarted.java` example.
 
 We also specify that `GettingStarted.class` will serve as our `defaultCommand`, this specifies what the behaviour of our CLI is if a user does not explicitly provide the name of the command to be run.
 
+**TODO Complete this example**

guide/parser/index.md

@@ -3,4 +3,6 @@ layout: page
 title: Parsing
 ---
 
-The core of Airline is its parser which takes in string arguments passed into the JVM and turns that into a command instance with appropriately populated fields that your code can then use to actually run its intended function.
+The core of Airline is its parser which takes in string arguments passed into the JVM and turns that into a command instance with appropriately populated fields that your code can then use to actually run its intended function.
+
+**TODO Document the parser**

guide/practise/oop.md

@@ -3,3 +3,4 @@ layout: page
 title: Inheritance and Composition
 ---
 
+**TODO Document how inheritance and composition are used within Airline**

guide/practise/types.md

@@ -40,4 +40,8 @@ More generally Airline supports any Java class that meets one of the following c
 
 Airline also supports any type which is a `Collection` of another supported type.
 
-The advantage of using collection types e.g. `List<String>` is that your `@Option` or `@Arguments` annotated field stores all the values passed in.  If your field has a non-collection type then only the last use of that option/argument will be stored in the final class that Airline creates.
+The advantage of using collection types e.g. `List<String>` is that your `@Option` or `@Arguments` annotated field stores all the values passed in.  If your field has a non-collection type then only the last use of that option/argument will be stored in the final class that Airline creates.
+
+## Custom Type Converters
+
+**TODO Document creating custom type converters**

guide/restrictions/index.md

@@ -3,16 +3,20 @@ layout: page
 title: Restrictions
 ---
 
-Airline includes a powerful and extensible restrictions system that allows users to significantly reduce the boiler plate code typical of many CLI libraries.  Restrictions work by simply applying appropriate annotations to the `@Option` or `@Arguments` annotated fields that you wish to restrict and Airline handles all the work of enforcing those restrictions for you.
+Airline includes a powerful and extensible restrictions system that allows users to significantly reduce the boiler plate code typical of many CLI libraries.  Restrictions work by simply applying appropriate annotations to the [`@Option`](../annotations/option.html) or [`@Arguments`](../annotations/arguments.html) annotated fields that you wish to restrict and Airline handles all the work of enforcing those restrictions for you.
 
 **TODO** Simple restriction example
 
 ## Available Restrictions
 
 ### Required Restrictions
 
+**TODO List required restrictions**
 
 ### Value Restrictions
 
+**TODO List value restrictions**
 
-## Custom Restrictions
+## Custom Restrictions
+
+**TODO Document creating custom restrictions**