diff --git a/chapters/00_intro.md b/chapters/00_intro.md
index 7720709..accca73 100644
--- a/chapters/00_intro.md
+++ b/chapters/00_intro.md
@@ -1,10 +1,9 @@
 ## Coding contingencies
 
-```note
-TODO:
--   how to quote propperly an introduction from a book series? (software studies)
--   find where to put code documentation & developers paragraphs
--   elaborate on citations
+```todo
+- how to quote propperly an introduction from a book series? (software studies)
+- find where to put code documentation & developers paragraphs
+- elaborate on citations
 ```
 
 
diff --git a/chapters/01_who_is_reading.md b/chapters/01_who_is_reading.md
index 84906dd..34d079d 100644
--- a/chapters/01_who_is_reading.md
+++ b/chapters/01_who_is_reading.md
@@ -1,6 +1,6 @@
 ## Who is reading
 
-```
+```note
 documentation as a publishing surface?
 
 yes because
@@ -13,7 +13,9 @@ yes but
 ```
 
 ### Getting started
-`("Getting startled" could also make for a nice title)`
+```note
+("Getting startled" could also make for a nice title)
+```
 
 Reading undocumented code feels like being an ant walking on a big painting. You can see the strokes of a brush and have an intuition of their direction, but what's missing is an overall idea of how the composition flows. Documentation provides guidance through the bunch of functions and statements that makes software, a bird's eye perspective. It is often the first thing one gets across when approaching a new library or programming language, and it shapes the way a developer thinks about particular piece of code.
 
@@ -63,7 +65,7 @@ Programming means to deal with picky stubborn machines that don't overlook a sin
 
 
 Instead...
-```
+```note
 lowering barriers
 -   debugging (p5.js education working group, 2015)
 -   aesthetic programming
@@ -71,7 +73,7 @@ lowering barriers
 ```
 ## "Natural" reader
 
-```
+```note
 -   assuming a certain kind of reader - expert - dude
 -   references:
     -   programming for the millions (ullman, 2016)