From 1af0031eae2ed026b9e45d746a6f23563ba6d950 Mon Sep 17 00:00:00 2001
From: Ole Herman Schumacher Elgesem
 <4048546+olehermanse@users.noreply.github.com>
Date: Fri, 8 Aug 2025 15:57:03 +0200
Subject: [PATCH] Revert "Fixed / skipped policy snippets"

---
 cheatsheet.markdown                           |  3 +-
 content/examples/_index.markdown              |  6 +-
 .../example_aborting_execution.markdown       |  2 +-
 ...ute-files-from-a-central-location.markdown |  2 +-
 .../integrating-with-sumo-logic.markdown      | 10 +--
 .../json-yaml-support-in-cfengine.markdown    |  6 +-
 .../examples/tutorials/manage-ntp.markdown    | 50 ++++++++-------
 ...der-files-with-mustache-templates.markdown |  2 +-
 .../reporting/command-line-reports.markdown   |  2 +-
 content/examples/tutorials/tags.markdown      |  4 +-
 .../tutorials/write-cfengine-policy.markdown  | 33 +++++-----
 ...thoring-policy-tools-and-workflow.markdown |  2 +-
 .../policy-style.markdown                     |  2 +-
 content/reference/components/_index.markdown  |  8 +--
 .../reference/components/cf-agent.markdown    | 10 +--
 .../reference/components/cf-serverd.markdown  | 14 ++---
 content/reference/macros.markdown             | 18 +++---
 .../additional-topics/devops.markdown         | 35 ++++++-----
 .../distributed-scheduling.markdown           | 12 ++--
 .../additional-topics/file-content.markdown   |  4 +-
 .../additional-topics/hierarchies.markdown    |  2 +-
 .../additional-topics/open-nebula.markdown    | 62 +++++++++----------
 .../faq/fix-undefined-body-error.markdown     |  2 +-
 23 files changed, 149 insertions(+), 142 deletions(-)

diff --git a/cheatsheet.markdown b/cheatsheet.markdown
index 600dd8693..339c67597 100644
--- a/cheatsheet.markdown
+++ b/cheatsheet.markdown
@@ -246,7 +246,8 @@ Linux
 ```
 
 You might also specify output syntax highlighting by adding language
-after the starting backticks and placing `{output}` at the end of the line.
+after the starting backticks and placing `[output]` in the first line.
+This line won't be shown in the resulted HTML.
 
 ```command
 curl --user admin:admin https://test.cfengine.com/api/user
diff --git a/content/examples/_index.markdown b/content/examples/_index.markdown
index 07044603c..a87842b8e 100644
--- a/content/examples/_index.markdown
+++ b/content/examples/_index.markdown
@@ -219,7 +219,7 @@ from the example.
 3. Insert the example's bundle name in the `bundlesequence` section
    of the main policy file `/var/cfengine/masterfiles/promises.cf`:
 
-   ```cf3 {skip TODO}
+   ```cf3
    bundlesequence => {
        ...
        "hello_world",
@@ -230,7 +230,7 @@ from the example.
 4. Insert the policy file name in the [`inputs`][Components#inputs] section of the main policy file
    `/var/cfengine/masterfiles/promises.cf`:
 
-   ```cf3 {skip TODO}
+   ```cf3
    inputs => {
        ...
        "hello_world.cf",
@@ -241,7 +241,7 @@ from the example.
 5. You must also remove any inputs section from the example that
    includes the external library:
 
-   ```cf3 {skip TODO}
+   ```cf3
    inputs => {
        "libraries/cfengine_stdlib.cf"
    };
diff --git a/content/examples/example-snippets/promise-patterns/example_aborting_execution.markdown b/content/examples/example-snippets/promise-patterns/example_aborting_execution.markdown
index a2eda0b5c..0f3b01864 100644
--- a/content/examples/example-snippets/promise-patterns/example_aborting_execution.markdown
+++ b/content/examples/example-snippets/promise-patterns/example_aborting_execution.markdown
@@ -42,7 +42,7 @@ Copy and paste `abortbundleclasses => { "invalid" };` into
 `/var/cfengine/masterfiles/controls/cf_agent.cf`. If you add it to
 the end of the file it should look something like this:
 
-```cf3 {skip TODO}
+```cf3
 ...
     #  dryrun => "true";
 
diff --git a/content/examples/tutorials/distribute-files-from-a-central-location.markdown b/content/examples/tutorials/distribute-files-from-a-central-location.markdown
index a3bfdbb53..3c2552854 100644
--- a/content/examples/tutorials/distribute-files-from-a-central-location.markdown
+++ b/content/examples/tutorials/distribute-files-from-a-central-location.markdown
@@ -46,7 +46,7 @@ These variables provide path definitions for storing and deploying patches.
 
 Add the following variable information to the `masterfiles/def.cf` file:
 
-```cf3 {file="def.cf" skip TODO}
+```cf3 {file="def.cf"}
 "dir_patch_store"
   string => "/storage/patches",
   comment => "Define patch files source location",
diff --git a/content/examples/tutorials/integrating-with-sumo-logic.markdown b/content/examples/tutorials/integrating-with-sumo-logic.markdown
index 09fafd96a..b42275007 100644
--- a/content/examples/tutorials/integrating-with-sumo-logic.markdown
+++ b/content/examples/tutorials/integrating-with-sumo-logic.markdown
@@ -29,7 +29,7 @@ First, we define a couple of variables.
 
 The two Sumo variables are used to access the service, while the `curl_args` is the actual curl command that will upload our timestamp file to Sumo Logic.
 
-```cf3 {skip TODO}
+```cf3
 vars:
   "policy_update_file"
     string => "/tmp/CFEngine_policy_updated";
@@ -47,7 +47,7 @@ We also ensures that the content of this file will be the value of the `sys.last
 
 Finally, below you will see a body defining how CFEngine is going to detect changes in policy files, this time using an md5 hash and only looking for change in the content (not permissions or ownership).
 
-```cf3 {skip TODO}
+```cf3
 files:
  "$(policy_update_file)"
   create => "true",
@@ -71,7 +71,7 @@ The final section in the CFEngine policy is where the command that uploads the f
 
 The command will only be issued whenever a class called `new_policy_update` is set, which we above defined to be set when there is a change detection. The handle argument is a useful way to document your intentions.
 
-```cf3 {skip TODO}
+```cf3
 commands:
   new_policy_update::
     "/usr/bin/curl"
@@ -105,7 +105,7 @@ Normally, to ensure your policy file is put into action, you would need to follo
 
 Under the body common control, add `sumo_logic_policy_update` to your bundle sequence.
 
-```cf3 {skip TODO}
+```cf3
 body common control
 
 {
@@ -118,7 +118,7 @@ body common control
 
 Under body common control, add /sumologic_policy_update.cf/ to your inputs section.
 
-```cf3 {skip TODO}
+```cf3
 inputs => {
            # File definition for global variables and classes
            "sumologic_policy_update.cf",
diff --git a/content/examples/tutorials/json-yaml-support-in-cfengine.markdown b/content/examples/tutorials/json-yaml-support-in-cfengine.markdown
index 87ff02292..ab3ec97d9 100644
--- a/content/examples/tutorials/json-yaml-support-in-cfengine.markdown
+++ b/content/examples/tutorials/json-yaml-support-in-cfengine.markdown
@@ -109,13 +109,13 @@ through them and look up values.
 
 Well, you can change
 
-```cf3 {skip TODO}
+```cf3
 "bykey" data => parsejson('{ "dev": ["c", "b"], "prod": ["flea"], "qa": ["a"], "private": ["linux"] }');
 ```
 
 with
 
-```cf3 {skip TODO}
+```cf3
 "bykey" data => data_readstringarray(...);
 ```
 
@@ -131,7 +131,7 @@ private linux
 
 You can also use
 
-```cf3 {skip TODO}
+```cf3
 "bykey" data => readjson(...);
 ```
 
diff --git a/content/examples/tutorials/manage-ntp.markdown b/content/examples/tutorials/manage-ntp.markdown
index a22e696a2..9731c2d2a 100644
--- a/content/examples/tutorials/manage-ntp.markdown
+++ b/content/examples/tutorials/manage-ntp.markdown
@@ -34,7 +34,7 @@ You can think of bundles as a collection of desired states. You can have as many
 
 #### vars
 
-```cf3 {skip TODO}
+```cf3
 vars:
 ```
 
@@ -42,7 +42,7 @@ vars:
 
 ##### ntp_package_name
 
-```cf3 {skip TODO}
+```cf3
 "ntp_package_name" string => "ntp";
 ```
 
@@ -50,7 +50,7 @@ A variable with the name `ntp_package_name` is declared and it is assigned a val
 
 #### packages
 
-```cf3 {skip TODO}
+```cf3
 packages:
     "$(ntp_package_name)"   -> { "StandardsDoc 3.2.1" }
       policy          => "present",
@@ -62,7 +62,7 @@ packages:
 
 ##### $(ntp_package_name)
 
-```cf3 {skip TODO}
+```
 "$(ntp_package_name)"   -> { "StandardsDoc 3.2.1" }
 ```
 
@@ -72,7 +72,7 @@ This promiser has a number of additional attributes defined:
 
 ###### policy
 
-```cf3 {skip TODO}
+```cf3
 policy          => "present",
 ```
 
@@ -80,7 +80,7 @@ policy          => "present",
 
 ###### handle
 
-```cf3 {skip TODO}
+```cf3
 handle          => "ntp_packages_$(ntp_package_name)",
 ```
 
@@ -88,7 +88,7 @@ The handle uniquely identifies a promise within a policy. A recommended naming s
 
 ###### classes
 
-```cf3 {skip TODO}
+```cf3
 classes         => results("bundle", "ntp_package_");
 ```
 
@@ -134,10 +134,16 @@ Validate it.
 python -m json.tool < def.json
 ```
 
-```json {output}
+```output
 {
-  "inputs": ["services/ntp.cf"],
-  "vars": { "control_common_bundlesequence_end": ["ntp"] }
+    "inputs": [
+        "services/ntp.cf"
+    ],
+    "vars": {
+        "control_common_bundlesequence_end": [
+            "ntp"
+        ]
+    }
 }
 ```
 
@@ -207,7 +213,7 @@ Let's dissect this policy and review the differences in the policy.
 
 #### vars
 
-```cf3 {skip TODO}
+```cf3
 redhat::
     "ntp_service_name" string => "ntpd";
 debian::
@@ -218,7 +224,7 @@ The first thing that you will notice is that the variable declarations section h
 
 #### reports
 
-```cf3 {skip TODO}
+```cf3
 reports:
   ntp_service_repaired.inform_mode::
     "NTP service repaired";
@@ -232,7 +238,7 @@ ntp_service_repaired.inform_mode::
 
 This line restricts the context for the promises that follow to hosts that have `ntp_service_repaired` and `inform_mode` defined. Note: `inform_mode` is defined when information level logging is requested, e.g. the `-I`, `--inform`, or `--log-level inform` options are given to `cf-agent` defined.
 
-```cf3 {skip TODO}
+```cf3
 "NTP service repaired";
 ```
 
@@ -354,7 +360,7 @@ Let's review the different sections of the code, starting with the variable decl
 
 #### vars
 
-```cf3 {skip TODO}
+```cf3
    vars:
      linux::
        "ntp_package_name" string => "ntp";
@@ -384,7 +390,7 @@ A few new variables are defined. The variables `ntp_package_name`, `config_file`
 
 Now let's walk through the files promise in detail.
 
-```cf3 {skip TODO}
+```cf3
 files:
  "$(config_file)"
    create                => "true",
@@ -400,7 +406,7 @@ The promiser here is referenced by the `config_file` variable. In this case, it
 
 ##### create
 
-```cf3 {skip TODO}
+```cf3
 create                => "true",
 ```
 
@@ -408,7 +414,7 @@ Valid values for this attribute are `true` or `false` to instruct the agent whet
 
 ##### perms
 
-```cf3 {skip TODO}
+```cf3
 perms                 => mog( "644", "root", "root" ),
 ```
 
@@ -416,7 +422,7 @@ This attribute sets the permissions and ownership of the file. [`mog()`][stdlib-
 
 ##### handle
 
-```cf3 {skip TODO}
+```cf3
 handle                => "ntp_files_conf",
 ```
 
@@ -424,7 +430,7 @@ A handle uniquely identifies a promise within a policy set. The [policy style gu
 
 ##### classes
 
-```cf3 {skip TODO}
+```cf3
 classes               => results( "bundle", "ntp_config" );
 ```
 
@@ -432,7 +438,7 @@ The classes attribute here uses the [`results()`][lib/common.cf#results] classes
 
 ##### template_method
 
-```cf3 {skip TODO}
+```cf3
 template_method       => "inline_mustache",
 ```
 
@@ -440,7 +446,7 @@ CFEngine supports multiple templating engines, the [template_method][files#templ
 
 ##### edit_template_string
 
-```cf3 {skip TODO}
+```cf3
 edit_template_string  => "$(config_template_string)",
 ```
 
@@ -448,7 +454,7 @@ The `edit_template_string` attribute is set to `$(config_template_string)` which
 
 ##### template_data
 
-```cf3 {skip TODO}
+```cf3
 template_data         => mergedata( '{ "driftfile": "$(driftfile)", "servers": servers }' ),
 ```
 
diff --git a/content/examples/tutorials/render-files-with-mustache-templates.markdown b/content/examples/tutorials/render-files-with-mustache-templates.markdown
index a6e16a8b2..ccac0e57a 100644
--- a/content/examples/tutorials/render-files-with-mustache-templates.markdown
+++ b/content/examples/tutorials/render-files-with-mustache-templates.markdown
@@ -78,7 +78,7 @@ bundle agent myapp_confs
           }
     ');
 }
-bundle agent __main__
+body agent __main__
 {
   methods:
     "myapp_confs";
diff --git a/content/examples/tutorials/reporting/command-line-reports.markdown b/content/examples/tutorials/reporting/command-line-reports.markdown
index bcf42fc54..fb30000d7 100644
--- a/content/examples/tutorials/reporting/command-line-reports.markdown
+++ b/content/examples/tutorials/reporting/command-line-reports.markdown
@@ -176,7 +176,7 @@ reports:
 
 A bonus to this is that you can get CFEngine to report system anomalies:
 
-```cf3 {skip TODO}
+```cf3
 reports:
 
  rootprocs_high_dev2::
diff --git a/content/examples/tutorials/tags.markdown b/content/examples/tutorials/tags.markdown
index f1f1d7eab..67e929ee6 100644
--- a/content/examples/tutorials/tags.markdown
+++ b/content/examples/tutorials/tags.markdown
@@ -114,7 +114,7 @@ way to categorize various data accessible to the agent.
 Dynamic bundlesequences are extremely easy. First you find all the bundles whos
 name matches a regular expression and N tags.
 
-```cf3 {skip TODO}
+```cf3
 vars:
   "bundles" slist => bundlesmatching("regex", "tag1", "tag2", ...);
 ```
@@ -122,7 +122,7 @@ vars:
 Then every bundle matching the regular expression `regex` and **all**
 the tags will be found and run.
 
-```cf3 {skip TODO}
+```cf3
 methods:
   "run $(bundles)" usebundle => $(bundles);
 ```
diff --git a/content/examples/tutorials/write-cfengine-policy.markdown b/content/examples/tutorials/write-cfengine-policy.markdown
index f6b5c5fb8..542719203 100644
--- a/content/examples/tutorials/write-cfengine-policy.markdown
+++ b/content/examples/tutorials/write-cfengine-policy.markdown
@@ -20,10 +20,10 @@ detailed information see the Language concepts section of the Reference manual.
 
 ### Bundles
 
-Bundles are re-usable and blocks of CFEngine policy. The following defines a _bundle_ called `example`, and it is a bundle for the agent.
+Bundles are re-usable and blocks of CFEngine policy. The following defines a _bundle_ called `my_test`, and it is a bundle for the agent.
 
 ```cf3
-bundle agent example
+bundle agent my_test
 {
   # ...
 }
@@ -45,12 +45,9 @@ do some file configuration for example, you would use the files promise type.
 The following policy ensures the existence of the `/tmp/hello-world` file:
 
 ```cf3
-bundle agent example
-{
-  files:
-    "/tmp/hello-world"
-      create => "true";
-}
+files:
+  "/tmp/hello-world"
+    create => "true";
 ```
 
 When defining desired states it is important to be clear about when and where
@@ -78,8 +75,8 @@ Now let's put the bundle, promise type and class components together in a
 final policy. As for classes we will use linux to define that the file
 `/tmp/hello-world` must exists on all hosts of type _linux_:
 
-```cf3 {file="example.cf"}
-bundle agent example
+```cf3 {file="my_test.cf"}
+bundle agent my_test
 {
   files:
     linux::
@@ -89,11 +86,11 @@ bundle agent example
 
 bundle agent __main__
 {
-  methods: "example";
+  methods: "my_test";
 }
 ```
 
-Let's save this policy in `/tmp/example.cf`.
+Let's save this policy in `/tmp/my-policy.cf`.
 
 You can now run this policy either in Distributed (client-server) System or in a
 Stand Alone system. The next two sections will cover each of the options.
@@ -112,13 +109,13 @@ this as it is the same cf-agent that runs on the hosts as on the Policy Server.
 command to run a syntax check:
 
 ```command
-cf-promises -f /tmp/example.cf
+cf-promises -f /tmp/my-policy.cf
 ```
 
 Unless you get any output, the syntax is correct. Now, to run this policy, simply type:
 
 ```command
-cf-agent -Kf /tmp/example.cf
+cf-agent -Kf /tmp/my-policy.cf
 ```
 
 As you can see, the response is immediate! Running CFEngine locally like this is
@@ -133,7 +130,7 @@ If you want to see what the agent is doing during its run, you can run the agent
 in verbose mode. Try:
 
 ```command
-cf-agent -Kf /tmp/example.cf --verbose
+cf-agent -Kf /tmp/my-policy.cf --verbose
 ```
 
 In a Stand Alone system, to make and run a policy remember to:
@@ -157,7 +154,7 @@ directory. When the content changes, cf-agent will download the updated files to
 
 This means that by default you should store all your policies in the
 `/var/cfengine/masterfiles` directory on your policy server. So, now create
-`/var/cfengine/masterfiles/example.cf` with the content of the test policy
+`/var/cfengine/masterfiles/my-policy.cf` with the content of the test policy
 previously authored.
 
 **NOTE:** We recommend that you use a version control system to store the audit
@@ -169,7 +166,7 @@ Now we need to tell CFEngine that there is a new policy in town:
 
 ```json {file="def.json"}
 {
-  "inputs": ["example.cf"]
+  "inputs": ["my-policy.cf"]
 }
 ```
 
@@ -185,7 +182,7 @@ any of the bootstrapped clients and you will find the `/tmp/-hello-world` file
 there.
 
 Whenever a host connects to the Policy Server, the host will ensure that it has
-the `example.cf` file from the masterfiles directory exists in the local
+the `my-policy.cf` file from the masterfiles directory exists in the local
 inputs directory. `def.json` will also be downloaded with the new
 instruction that there is a new policy. Within 5 minutes, whether you have 5
 Linux hosts or 50,000 Linux hosts, they will all have the `/tmp/hello-world` file
diff --git a/content/examples/tutorials/writing-and-serving-policy/authoring-policy-tools-and-workflow.markdown b/content/examples/tutorials/writing-and-serving-policy/authoring-policy-tools-and-workflow.markdown
index e1a4896dd..e460f59d7 100644
--- a/content/examples/tutorials/writing-and-serving-policy/authoring-policy-tools-and-workflow.markdown
+++ b/content/examples/tutorials/writing-and-serving-policy/authoring-policy-tools-and-workflow.markdown
@@ -124,7 +124,7 @@ body contain masterfiles_contain
 3. Save the file.
 4. Add bundle and file information to `/var/cfengine/masterfiles/promises.cf`. Example (where `...` represents existing text in the file, omitted for clarity):
 
-```cf3 {file="promises.cf" skip TODO}
+```cf3 {file="promises.cf"}
 body common control
 
 {
diff --git a/content/examples/tutorials/writing-and-serving-policy/policy-style.markdown b/content/examples/tutorials/writing-and-serving-policy/policy-style.markdown
index 6a2ba2a15..532cbabae 100644
--- a/content/examples/tutorials/writing-and-serving-policy/policy-style.markdown
+++ b/content/examples/tutorials/writing-and-serving-policy/policy-style.markdown
@@ -512,7 +512,7 @@ bundle agent satellite_bootstrap_main
 {
 
 @if feature(this_is_not_the_feature_your_looking_for)
-   some_promise: "foo" unknown => "bar";
+   Hello there.
 @endif
 
   meta:
diff --git a/content/reference/components/_index.markdown b/content/reference/components/_index.markdown
index da450c582..90ff9b02a 100644
--- a/content/reference/components/_index.markdown
+++ b/content/reference/components/_index.markdown
@@ -90,7 +90,7 @@ bundles act like characteristics of the systems. If you want
 different systems to have different `bundlesequences`, distinguish
 them with classes
 
-```cf3 {skip TODO}
+```cf3
 webservers::
 
   bundlesequence => { "main", "web" };
@@ -183,7 +183,7 @@ runs of e.g. `cf-agent` and `cf-promises`.
 
 **Example:**
 
-```cf3 {skip TODO}
+```cf3
 cache_system_functions => "true";
 ```
 
@@ -251,7 +251,7 @@ sequence do not exist, ignore and continue.
 
 **Example:**
 
-```cf3 {skip TODO}
+```cf3
 ignore_missing_bundles => "true";
 ```
 
@@ -283,7 +283,7 @@ not found.
 
 **Example:**
 
-```cf3 {skip TODO}
+```cf3
 ignore_missing_inputs => "true";
 ```
 
diff --git a/content/reference/components/cf-agent.markdown b/content/reference/components/cf-agent.markdown
index cde2f4922..d41063e2b 100644
--- a/content/reference/components/cf-agent.markdown
+++ b/content/reference/components/cf-agent.markdown
@@ -297,7 +297,7 @@ the control section are hard-classes.
 
 **Example:**
 
-```cf3 {skip TODO}
+```cf3
 any::
 
   addclasses => { "My_Organization" }
@@ -329,7 +329,7 @@ rather than a security measure.
 
 **Example:**
 
-```cf3 {skip TODO}
+```cf3
 agentaccess => { "mark", "root", "sudo" };
 ```
 
@@ -357,7 +357,7 @@ syslog facility level.
 
 **Example:**
 
-```cf3 {skip TODO}
+```cf3
 agentfacility => "LOG_USER";
 ```
 
@@ -449,7 +449,7 @@ be given as the argument, not the device name.
 
 **Example:**
 
-```cf3 {skip TODO}
+```cf3
 bindtointerface => "192.168.1.1";
 ```
 
@@ -709,7 +709,7 @@ bundle agent one
 
 Some interactive programs insist on values being set, for example:
 
-```cf3 {skip TODO}
+```cf3
 # Required by apt-cache, debian
 
 environment => { "LANG=C" };
diff --git a/content/reference/components/cf-serverd.markdown b/content/reference/components/cf-serverd.markdown
index b4dddc6c4..54b59f19b 100644
--- a/content/reference/components/cf-serverd.markdown
+++ b/content/reference/components/cf-serverd.markdown
@@ -69,7 +69,7 @@ See also the warning about regular expressions in
 
 **Examples**:
 
-```cf3 {skip TODO}
+```cf3
 allowconnects => {
      "127.0.0.1",
      "::1",
@@ -101,7 +101,7 @@ will potentially match more than one hostname (e.g.,
 
 **Examples**:
 
-```cf3 {skip TODO}
+```cf3
 allowallconnects      => {
      "127.0.0.1",
      "::1",
@@ -117,7 +117,7 @@ that are not using the latest protocol.
 
 To define subnets or address ranges, use CIDR notation:
 
-```cf3 {skip TODO}
+```cf3
 allowlegacyconnects =>  { "192.168.1.0/24", "192.168.2.123" }
 ```
 
@@ -127,7 +127,7 @@ for compatibility with pre-3.6 CFEngine versions.
 Set this attribute to an empty list to not allow any incoming connections
 using legacy protocol versions:
 
-```cf3 {skip TODO}
+```cf3
 allowlegacyconnects => { }
 ```
 
@@ -216,7 +216,7 @@ correspond to system identities on the server-side system.
 
 **Example:**
 
-```cf3 {skip TODO}
+```cf3
 allowusers => { "cfengine", "root" };
 ```
 
@@ -233,13 +233,13 @@ be given as the argument, not the device name.
 
 **Allowed input range:** (arbitrary string)
 
-```cf3 {skip TODO}
+```cf3
 bindtointerface => "192.168.1.1";
 ```
 
 To bind to all interfaces, including IPV6:
 
-```cf3 {skip TODO}
+```cf3
 bindtointerface => "::";
 ```
 
diff --git a/content/reference/macros.markdown b/content/reference/macros.markdown
index f5d0992ed..0fb77fe07 100644
--- a/content/reference/macros.markdown
+++ b/content/reference/macros.markdown
@@ -28,7 +28,7 @@ bundle agent extractor
 {
 @if minimum_version(3.8)
 # the function `new_function_3_8()` was introduced in 3.8
-vars: "container" data => new_function_3_8();
+vars: "container" data => new_function_3_8(...);
 @endif
 }
 ```
@@ -47,7 +47,7 @@ bundle agent extractor
 @if maximum_version(3.15)
   # This policy will only be parsed on versions 3.15 and earlier
   vars:
-    "container" data => old_function_3_15();
+    "container" data => old_function_3_15(...);
 @endif
 }
 ```
@@ -68,7 +68,7 @@ bundle agent extractor
 @if at_version(3.15)
   # This policy will only be parsed on 3.15 clients
   vars:
-    "container" data => old_function_3_15();
+    "container" data => old_function_3_15(...);
 @endif
 }
 ```
@@ -89,7 +89,7 @@ bundle agent extractor
 @if between_versions(3.12, 3.15)
   # Policy specific to 3.12, 3.13, 3.14, 3.15
   vars:
-    "container" data => workaround_3_12_3_15();
+    "container" data => workaround_3_12_3_15(...);
 @endif
 }
 ```
@@ -111,7 +111,7 @@ bundle agent extractor
   # Policy to work around issue which was fixed in 3.15
   vars:
     "container"
-      data => workaround_pre_3_15();
+      data => workaround_pre_3_15(...);
 @endif
 }
 ```
@@ -133,7 +133,7 @@ bundle agent extractor
   # This policy is only parsed on 3.16+
   vars:
     "container"
-      data => not_neded_on_3_15();
+      data => not_neded_on_3_15(...);
 @endif
 }
 ```
@@ -157,12 +157,12 @@ bundle agent extractor
   # Implementation for 3.16+
   vars:
     "container"
-      data => classfiltercsv();
+      data => classfiltercsv(...);
 @else
   # Implementation for versions before 3.16
   vars:
     "container"
-      data => readcsv();
+      data => readcsv(...);
 @endif
 }
 ```
@@ -180,7 +180,7 @@ bundle agent extractor
 {
   @if feature(xml)
 # the yaml library may not be compiled in
-  vars: "container" data => parseyaml();
+  vars: "container" data => parseyaml(...);
   @endif
 }
 ```
diff --git a/content/resources/additional-topics/devops.markdown b/content/resources/additional-topics/devops.markdown
index a13de9098..5b59b90ae 100644
--- a/content/resources/additional-topics/devops.markdown
+++ b/content/resources/additional-topics/devops.markdown
@@ -126,13 +126,11 @@ organizes similar operations into chapters in a simple separation of concerns.
 bundle agent example
 {
   files:
-    "affected object"
-      # ...details....
-      ;
+     "affected object" ...details....
+
   processes:
-    "affected object"
-      # ...details....
-      ;
+     "affected object" ...details....
+
 }
 ```
 
@@ -140,14 +138,14 @@ In general, many such promises and types are collected into bundles, so that the
 form is
 
 ```cf3
-bundle agent some_user_defined_name
+bundle agent SomeUserDefinedName
 {
   type_of_promise:
+
     "affected object/promiser"
-      # attributes of the promise/details
-      ;
-    # More promises...
-  # More promise types...
+
+     body of the promise/details
+ ...
 }
 ```
 
@@ -159,13 +157,18 @@ written as a prefix, a bit like a target in a Makefile. They represent known
 properties of the environment.
 
 ```cf3
-bundle agent some_user_defined_name
+bundle agent SomeUserDefinedName
 {
+
   type_of_promise:
+
     property::
-      "make one promise...";
+
+      make one promise...
+
     !property::
-      "make a different promise...";
+
+      make a different promise...
 }
 ```
 
@@ -178,7 +181,7 @@ certain hard-classes by default. In addition, you can probe as many more as you
 like, as separate promises.
 
 ```cf3
-bundle agent some_user_defined_name
+bundle agent SomeUserDefinedName
 {
  classes:
 
@@ -197,7 +200,7 @@ To go from if-then-else thinking to using classes, you just need to thihnk about
 classes as booleans:
 
 ```cf3
-bundle agent some_user_defined_name
+bundle agent Name
 {
   classes:
 
diff --git a/content/resources/additional-topics/distributed-scheduling.markdown b/content/resources/additional-topics/distributed-scheduling.markdown
index 4ec3415f5..5ff49c10c 100644
--- a/content/resources/additional-topics/distributed-scheduling.markdown
+++ b/content/resources/additional-topics/distributed-scheduling.markdown
@@ -112,7 +112,7 @@ classes:
                                            );
 methods:
 
-  Host2.hostX_did_my_job::
+  Host2.hostX_did_my_job
 
     "any" usebundle => do_my_job_bundle;
 
@@ -193,7 +193,7 @@ classes:
                                                         );
 methods:
 
-  Host2.hostX_did_my_job::
+  Host2.hostX_did_my_job
 
     "any" usebundle => do_my_job_bundle;
 
@@ -361,7 +361,7 @@ classes:
                                  if => "Host$(n)";
 methods:
 
-  Host2.Host3.Host4.hostX_did_my_job::
+  Host2.Host3.Host4.hostX_did_my_job
 
     "any" usebundle => do_my_job_bundle;
 
@@ -382,12 +382,12 @@ no error handling or recovery except to schedule the whole thing again.
 Triggering from one or more predecessors, i.e. combining with OR, looks similar,
 we just have to change the class expression:
 
-```cf3
+```
 bundle agent example
 {
   methods:
 
-    (Host2|Host3|Host4).hostX_did_my_job::
+    (Host2|Host3|Host4).hostX_did_my_job
 
       "any" usebundle => do_my_job_bundle;
 }
@@ -414,7 +414,7 @@ classes:
                                                         );
 methods:
 
-  Host2.hostX_did_my_job::
+  Host2.hostX_did_my_job
 
     "any" usebundle => do_my_job_bundle1;
     "any" usebundle => do_my_job_bundle2;
diff --git a/content/resources/additional-topics/file-content.markdown b/content/resources/additional-topics/file-content.markdown
index 0800c96bb..60f26b2cf 100644
--- a/content/resources/additional-topics/file-content.markdown
+++ b/content/resources/additional-topics/file-content.markdown
@@ -803,8 +803,8 @@ with the standard library method:
 ```cf3
 bundle agent example
 {
-  files:
-    "/tmp/expander"
+  "/tmp/expander"
+
            create => "true",
     edit_template => "/home/a10004/input.dat",
     edit_defaults => empty;
diff --git a/content/resources/additional-topics/hierarchies.markdown b/content/resources/additional-topics/hierarchies.markdown
index 6abd1a5bb..6941844bf 100644
--- a/content/resources/additional-topics/hierarchies.markdown
+++ b/content/resources/additional-topics/hierarchies.markdown
@@ -351,7 +351,7 @@ bundle agent example
 
   processes:
     servers::  # the next rules `extend` or add to the class servers
-      "...";
+      "..."
 }
 ```
 
diff --git a/content/resources/additional-topics/open-nebula.markdown b/content/resources/additional-topics/open-nebula.markdown
index 2abfd8b0d..268bc0b05 100644
--- a/content/resources/additional-topics/open-nebula.markdown
+++ b/content/resources/additional-topics/open-nebula.markdown
@@ -70,7 +70,7 @@ cluster-node.
 
 First we can classify the physical machines in this case by IP address:
 
-```cf3 {skip TODO}
+```cf3
 classes:
         "front_end" or => {"192.168.1.2"};
         "node_controllers" or => {"192.168.1.3"};
@@ -81,7 +81,7 @@ IP addresses of intended node controllers. This will allow the "onehost create"
 command to execution each new node controller in turn reducing redundancy in the
 policy file for example:
 
-```cf3 {skip TODO}
+```cf3
 vars:
  "node_controller" slist => { "192.168.1.3", "192.168.1.4", "192.168.1.5" };
 
@@ -100,7 +100,7 @@ classes:
 To install the dependancies for each physical machine we can define these in a
 list and use the CFEngine standard library package promises to install them:
 
-```cf3 {skip TODO}
+```cf3
 vars:
   "front_end_deps" slist => {
     "libcurl3",
@@ -127,7 +127,7 @@ vars:
 
 Promises to perform dependency installation:
 
-```cf3 {skip TODO}
+```cf3
 packages:
 
 front_end::
@@ -149,7 +149,7 @@ The additional line in the front end dependancy installation promise, assuming a
 successful installation, will ensure the Open Nebula daemon is running at all
 times:
 
-```cf3 {skip TODO}
+```cf3
 front_end::
 
 ensure_opennebula_running::
@@ -159,7 +159,7 @@ ensure_opennebula_running::
 
 Resulting in:
 
-```cf3 {skip TODO}
+```cf3
 commands:
 
   start_oned::
@@ -171,7 +171,7 @@ commands:
 Since we will be using Open Nebula version 2 we must manually supply the
 package:
 
-```cf3 {skip TODO}
+```cf3
 commands:
 
   front_end.!opennebula_installed::
@@ -184,7 +184,7 @@ repeated installation we can do a check to see if Open Nebula has already been
 installed by classifying a successful installation as having the oned.conf file
 in existence:
 
-```cf3 {skip TODO}
+```cf3
 classes:
 
   "opennebula_installed" or => {fileexists("/etc/one/oned.conf")};
@@ -194,7 +194,7 @@ Open nebula requires a privileged user "oneadmin" to issue commands. In order to
 have CFEngine perform these commands with the correct privileges we can use the
 contain body by appending the following to commands promises:
 
-```cf3 {skip TODO}
+```cf3
 contain => oneadmin
 ```
 
@@ -214,7 +214,7 @@ dependancy configuration, Up: Top NFS config for shared image repository
 If not present append the NFS export directory stored in the corresponding
 variable (including a new line):
 
-```cf3 {skip TODO}
+```cf3
 vars:
 
 "nfs_export_dir"
@@ -234,7 +234,7 @@ files:
 
 To ensure the NFS service remains available:
 
-```cf3 {skip TODO}
+```cf3
 processes:
 
 ensure_nfs_running::
@@ -251,7 +251,7 @@ start_nfs::
 In order to ensure the share is mounted on all node controllers we can use the
 NFS promise:
 
-```cf3 {skip TODO}
+```cf3
 storage:
 
   cluster_node::
@@ -262,7 +262,7 @@ storage:
 
 Next we will create a directory to hold our virtual machine images:
 
-```cf3 {skip TODO}
+```cf3
 "/var/lib/one/images/.",
   comment => "create dir in image repo share",
   perms => mog("644", "oneadmin", "oneadmin"),
@@ -273,7 +273,7 @@ Next we will create a directory to hold our virtual machine images:
 
 Create the oneadmin bashrc file containing the ONE_XMLRPC environment variable with appropriate permissions:
 
-```cf3 {skip TODO}
+```cf3
 files:
   front_end::
     "/var/lib/one/.bashrc"
@@ -286,7 +286,7 @@ files:
 
 We also need to create the one_auth file:
 
-```cf3 {skip TODO}
+```cf3
 files:
   front_end::
     "/var/lib/one/.one/one_auth",
@@ -300,7 +300,7 @@ Finally password-less authentication for the oneadmin user:
 
 Add key to autorized_keys file:
 
-```cf3 {skip TODO}
+```cf3
 files:
   front_end::
     "/var/lib/one/.ssh/authorized_keys",
@@ -311,7 +311,7 @@ files:
 
 Disable known hosts prompt:
 
-```cf3 {skip TODO}
+```cf3
 front_end::
   "/var/lib/one/.ssh/config",
     comment => "disable strict host key checking",
@@ -325,7 +325,7 @@ Now on the node controller(s) we need to add the oneadmin group and user with
 the same uid and gid as the front end and add the oneadmin user to the libvertd
 group:
 
-```cf3 {skip TODO}
+```cf3
 files:
   node_controller::
     "/etc/passwd",
@@ -344,7 +344,7 @@ files:
 Now that the user environment is configured we can register our node controller
 with the front end:
 
-```cf3 {skip TODO}
+```cf3
 files:
   front_end::
     "/usr/bin/onehost create 192.168.1.2 im_kvm vmm_kvm tm_nfs",
@@ -357,7 +357,7 @@ Before we can create virtual networks we must configure our node controller
 interfaces. In this example we will bridge a virtual interface (vbr0) with eth0.
 First we define the contents of the interfaces file in a variable:
 
-```cf3 {skip TODO}
+```cf3
 vars:
 "interfaces_contents" slist => {
   "auto lo",
@@ -379,7 +379,7 @@ vars:
 
 Next we edit the interfaces file to include our new settings:
 
-```cf3 {skip TODO}
+```cf3
 files:
   node_controller::
     "/etc/network/interfaces",
@@ -391,7 +391,7 @@ files:
 
 And restart networking:
 
-```cf3 {skip TODO}
+```cf3
 commands:
   restart_networking::
     "/etc/init.d/networking restart",
@@ -403,7 +403,7 @@ network file and submit it to the system. The contents of the virtual network
 template file could be defined as a variable as we have seen before but in this
 case it is passed as a parameter to the append promise body:
 
-```cf3 {skip TODO}
+```cf3
 "/var/lib/one/network.template",
   comment => "create lan template",
   create => "true",
@@ -418,7 +418,7 @@ The network template only deals with fixed ip addresses and provides only one
 lease. Obviously this should be altered to suite your requirements. Now we have
 a template we can register it with open nebula:
 
-```cf3 {skip TODO}
+```cf3
 commands:
   front_end::
      "/usr/bin/onevnet create /var/lib/one/network.template",
@@ -430,7 +430,7 @@ commands:
 This follows the same pattern as virtual network setup. First we create the
 template file:
 
-```cf3 {skip TODO}
+```cf3
 files:
 
   "/var/lib/one/vm.template",
@@ -457,7 +457,7 @@ GRAPHICS = [TYPE = \"vnc\", LISTEN = \"localhost\", PORT = 5910]
 
 Now we can launch the virtual machine defined in its template file:
 
-```cf3 {skip TODO}
+```cf3
 commands:
   front_end::
     "/usr/bin/onevm create /var/lib/one/vm.template",
@@ -491,7 +491,7 @@ Once registration is complete we can define a new class based on the ip of our
 virtual machine. In this example that is 192.168.1.100 so we can create a class
 with a meaningful name:
 
-```cf3 {skip TODO}
+```cf3
 "webserver" or => {"192_168_1_100"};
 ```
 
@@ -502,7 +502,7 @@ other machine for example:
 
 First we install apache:
 
-```cf3 {skip TODO}
+```cf3
 packages:
   webserver::
     "apache2",
@@ -514,7 +514,7 @@ packages:
 
 Next we ensure it is running
 
-```cf3 {skip TODO}
+```cf3
 processes:
   ensure_apache_running::
     ".*apache2.*"
@@ -523,7 +523,7 @@ processes:
 
 If not, the service is restarted
 
-```cf3 {skip TODO}
+```cf3
 commands:
   start_apache::
     "/etc/init.d/apache2 restart";
@@ -532,7 +532,7 @@ commands:
 Finally we can copy some content into the document root on our new virtual
 webserver:
 
-```cf3 {skip TODO}
+```cf3
 files:
   "/var/www"
     perms => system("744"),
diff --git a/content/resources/faq/fix-undefined-body-error.markdown b/content/resources/faq/fix-undefined-body-error.markdown
index 0da971d1f..eac0bf807 100644
--- a/content/resources/faq/fix-undefined-body-error.markdown
+++ b/content/resources/faq/fix-undefined-body-error.markdown
@@ -34,7 +34,7 @@ Body file control allows you to build modular policy. Body file control inputs
 are typically relative to the policy file itself.
 
 ```cf3
-bundle common file_remover_control
+bundle file_remover_control
 {
   vars:
     "inputs" slist => {