diff --git a/vignettes/feature1_constantAttributes.Rmd b/vignettes/feature1_constantAttributes.Rmd
index 6c3f301..dd231b9 100644
--- a/vignettes/feature1_constantAttributes.Rmd
+++ b/vignettes/feature1_constantAttributes.Rmd
@@ -41,6 +41,7 @@ knitr::kable(sampleAnnotationDF, format = "html")
 ```
 
 ----
+
 ## Solution
 As the name suggests the attributes in the specified attributes (here: `read_type`) can be defined as constant ones. The way how this process is carried out is indicated explicitly in the `project_config.yaml` file (presented below). The name of the column is determined in the `sample_modifiers.append` key-value pair. Note that definition of more than one constant attribute is possible.
 
@@ -72,7 +73,9 @@ sampleAnnotation = system.file(
 ```
 
 ----
+
 ## Code
+
 Read in the project metadata by specifying the path to the `project_config.yaml`:
 
 ```{r}
diff --git a/vignettes/feature2_impliedAttributes.Rmd b/vignettes/feature2_impliedAttributes.Rmd
index e28eb12..dc683f5 100644
--- a/vignettes/feature2_impliedAttributes.Rmd
+++ b/vignettes/feature2_impliedAttributes.Rmd
@@ -42,7 +42,9 @@ knitr::kable(sampleAnnotationDF, format = "html")
 ```
 
 ----
+
 ## Solution
+
 Noticeably, the samples with attributes `human` and `mouse` (in the `organism` column) follow two distinct patterns here. They have additional attributes in attributes `genome` and `genome_size` in the `sample_table.csv` file. Consequently you can use implied attributes to add those attributes to the sample annotations (set global, species-level attributes at the project level instead of duplicating that information for every sample that belongs to a species). The way how this process is carried out is indicated explicitly in the `project_config.yaml` file (presented below).
 
 ```{r, echo=FALSE,message=FALSE,collapse=TRUE,comment=" "}
@@ -74,7 +76,9 @@ sampleAnnotation = system.file(
 ```
 
 ----
+
 ## Code
+
 Rread in the project metadata by specifying the path to the `project_config.yaml`:
 
 ```{r}
diff --git a/vignettes/feature3_derivedAttributes.Rmd b/vignettes/feature3_derivedAttributes.Rmd
index d0dd9e7..e692680 100644
--- a/vignettes/feature3_derivedAttributes.Rmd
+++ b/vignettes/feature3_derivedAttributes.Rmd
@@ -27,6 +27,7 @@ This vignette will show you how and why to use the derived attributes functional
  - broader theoretical description in the derived attributes [documentation section](http://pep.databio.org/en/2.0.0/specification/#sample_modifiersderive).
 
 ## Problem/Goal
+
 The example below demonstrates how to use the derived attributes to **flexibly define the samples attributes the `file_path` column** of the `sample_table.csv` file to match the file names in  your project. Please consider the example below for reference:
 
 
@@ -45,7 +46,9 @@ knitr::kable(sampleAnnotationDF, format = "html")
 ```
 
 ----
+
 ## Solution
+
 As the name suggests the attributes in the specified attributes (here: `file_path`) can be derived from other ones. The way how this process is carried out is indicated explicitly in the `project_config.yaml` file (presented below). The name of the column is determined in the `sample_modifiers.derive.attributes` key-value pair, whereas the pattern for the attributes construction - in the `sample_modifiers.derive.sources` one. Note that the second level key (here: `source`) has to exactly match the attributes in the `file_path` column of the modified `sample_annotation.csv` (presented below).
 
 
@@ -78,7 +81,9 @@ kable(sampleAnnotationDF, format = "html")
 ```
 
 ----
+
 ## Code
+
 Load `pepr` and read in the project metadata by specifying the path to the `project_config.yaml`:
 
 ```{r}
diff --git a/vignettes/feature4_derivedImpliedAttributes.Rmd b/vignettes/feature4_derivedImpliedAttributes.Rmd
index 6a3bf50..f5ce524 100644
--- a/vignettes/feature4_derivedImpliedAttributes.Rmd
+++ b/vignettes/feature4_derivedImpliedAttributes.Rmd
@@ -34,6 +34,7 @@ sampleAnnotationDF = read.table(sampleAnnotation, sep = ",", header = T)
 knitr::kable(sampleAnnotationDF, format = "html") 
 ```
 ----
+
 ## Solution
 
 The specification of detailed file paths/names (as presented above) is cumbersome. In order to make your life easier just find the patterns that the file names in `file_path` column of `sample_table.csv` follow, imply needed attributes and derive the file names. This multi step process is orchestrated by the `project_config.yaml` file via the `sample_modifiers.derive` and `sample_modifiers.imply` sections:
@@ -67,7 +68,9 @@ sampleAnnotation = system.file(
 ```
 
 ----
+
 ## Code
+
 Load `pepr` and read in the project metadata by specifying the path to the `project_config.yaml`:
 
 ```{r collapse=TRUE}
diff --git a/vignettes/feature5_sampleSubtable.Rmd b/vignettes/feature5_sampleSubtable.Rmd
index ba5b482..9bc572b 100644
--- a/vignettes/feature5_sampleSubtable.Rmd
+++ b/vignettes/feature5_sampleSubtable.Rmd
@@ -28,6 +28,7 @@ This vignette will show you how and why to use the subsample table functionality
 
 This series of examples below demonstrates how and why to use sample subannoatation functionality in multiple cases to **provide multiple input files of the same type for a single sample**.
 
+
 ## Solutions
 
 ### Example 1: basic sample subannotation table