diff --git a/BehavioralPatterns.sln b/BehavioralPatterns.sln
index fbcd77c..4e2e187 100644
--- a/BehavioralPatterns.sln
+++ b/BehavioralPatterns.sln
@@ -8,6 +8,7 @@ EndProject
 Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = "Solution Items", "Solution Items", "{4780CECA-2B6F-4F79-97C5-D1B483CFC881}"
 	ProjectSection(SolutionItems) = preProject
 		global.json = global.json
+		README.md = README.md
 	EndProjectSection
 EndProject
 Project("{8BB2217D-0F2D-49D1-97BC-3654ED321F3B}") = "BehavioralPatterns", "src\BehavioralPatterns\BehavioralPatterns.xproj", "{E3092EE0-1282-4AB4-9FA2-0338348D8FD1}"
diff --git a/README.md b/README.md
index 5095303..9f5489f 100644
--- a/README.md
+++ b/README.md
@@ -1,2 +1,46 @@
 # BehavioralPatterns
 Behavioral Patterns is a .NET core solution that shows some ways to implement the behavioral patterns described by the Gang of Four.
+Patterns described:
+1. Chain of responssibility
+Implemented in project: ChainOfResponsibility
+a. Pattern description:
+Decouples sender and receiver (as a sender you don't know who will handle the request/ as a receiver you don't know who the sender is necessary)
+Hierarchical in nature
+When using the Chain of Responsibility is more effective:
+More than one object can handle a command
+The handler is not known in advance
+The handler should be determined automatically
+It’s wished that the request is addressed to a group of objects without explicitly specifying its receiver
+The group of objects that may handle the command must be specified in a dynamic way.
+Examples in real life:
+ -java.util.logging.Logger.#log()
+ -javax.servlet.Filter#doFilter()
+ -Spring Security Filter Chain
+b. Pitfalls:
+Handling/Handler guarantee - you won't be sure that someone can process the request
+Runtime configuration risk - the order matters/and it might be that the chain is not configured correctly
+Chain length/performance issues - in theory you could see a chain that is too big, and it would be a bottleneck in performance
+c. Flavors:
+Flavor 1: Execute first that matches the condition and exit -> Get one to process the request, or get the type of object
+Flavor 2: Execute all elements of chain until the condition does not match -> Execute all validators until one invalidates the request
+Flavor 3: Always execute all handlers
+Flavor 4: Instead of each handler, having a successor, you could have each handler have a list of successors, and have it's policy what handlers to execute
+d. Examples described:
+Purchase example: 
+Starting class: PurchaseExample.CheckAuthority
+Problem that we are trying to solve:
+CheckAuthority allows an employee to request money for approval
+ if(manager can approve it) manager will process the request
+ if (director can approve it) director will process the request
+ if (vice president can approve it) vice president will process the request
+ if (president can approve it) president will process the request
+
+2. Command pattern
+3. Iterator pattern
+4. Mediator pattern
+5. Memento pattern
+6. Observer pattern
+7. State pattern
+8. Strategy pattern
+9. Template pattern
+10. Visitor pattern
diff --git a/src/ChainOfResponssibility/PurchaseExample/CheckAuthority.cs b/src/ChainOfResponssibility/PurchaseExample/CheckAuthority.cs
index 4cfe78c..ab39792 100644
--- a/src/ChainOfResponssibility/PurchaseExample/CheckAuthority.cs
+++ b/src/ChainOfResponssibility/PurchaseExample/CheckAuthority.cs
@@ -82,8 +82,7 @@ namespace ChainOfResponssibility.PurchaseExample
 
         public string GetDescriptionOfExample()
         {
-            return @"Description of example:
-CheckAuthority allows an employee to spend money
+            return @"Description of example: CheckAuthority allows an employee to request money for approval
  if(manager can approve it) manager will process the request
  if (director can approve it) director will process the request
  if (vice president can approve it) vice president will process the request