docs: community templates (update)

source/templates/community/README.md

@@ -79,7 +79,9 @@ with:
 
 ## 📪 Creating community templates
 
-Templates creation requires you to be comfortable with HTML, CSS and JavaScript ([EJS](https://github.com/mde/ejs) flavored).
+Templates creation requires you to be comfortable with HTML, CSS and [EJS](https://github.com/mde/ejs).
+
+### 💬 Quick-start
 
 To create a new template, clone and setup this repository first:
 ```shell
@@ -95,8 +97,8 @@ npm run quickstart template <template_name>
 
 It will create a new directory in `/source/templates` with the following file structure:
 * `/source/templates/{template-name}`
-  * `README.md`,
-  * `metadata.yml`,
+  * `README.md`
+  * `metadata.yml`
   * `image.svg`
   * `partials/`
     * `_.json`
@@ -127,11 +129,11 @@ Usually `image.svg` doesn't need to be edited too much, but let's explain it how
 </svg>
 ```
 
-#### EJS syntax
+#### ℹ️ EJS syntax
 
 [EJS](https://github.com/mde/ejs) framework is used to programmatically create content through the help of templating tags (`<% %>`).
 
-#### Styling
+#### ℹ️ Styling
 
 `fonts` and `style` variables are respectively populated with `fonts.css` and `styles.css` files content (or will fallback to those of `classic` template inexistent).
 
@@ -139,13 +141,13 @@ These will define the global design of the output.
 
 `data-optimizable="true"` tells that a `style` tag can be safely minified and purged by CSS post-processors.
 
-#### Partials
+#### ℹ️ Partials
 
 `partials` variable is populated with `partials/_.json` file content and define which files should be included along with default ordering.
 
 The loop iterates over this array to include all defined partials. Each partial should handle whether it should be displayed by itself.
 
-### `#metrics-end` tag
+#### ℹ️ `#metrics-end` tag
 
 `#metrics-end` is a special HTML tag which must remain at the bottom of SVG template.
 
@@ -153,8 +155,9 @@ It is used to compute height dynamically through a [puppeteer](https://github.co
 
 ### 💬 Filling `metadata.yml`
 
-`metadata.yml` is a file which describes supported account types, output formats, scopes, etc.
+`metadata.yml` is a required file which describes supported account types, output formats, scopes, etc.
 
+The default file looks like below:
 ```yaml
 name: "🖼️ Template name"
 extends: classic
@@ -174,28 +177,38 @@ formats:
   - markdown-pdf
 ```
 
-[`🧱 core`](/source/plugins/core/README.md) plugin will automatically check user inputs with your defined supported `supports` and `formats` key and throw an error in case of incompatibility.
+> 💡 It is important to correctly define `metadata.yml` because *metrics* will use its content for various usage
 
-`name`, `description` and `examples` are used to auto-generate documentation in the `README.md` by replacing the following:
+[`🧱 core`](/source/plugins/core/README.md) plugin (which is always called) will automatically verify user inputs against `supports` and `formats` values and throw an error in case of incompatibility.
 
-```markdown
-<ǃ--header-->
-<ǃ--/header-->
-```
+`extends` is used to define the fallback for `template.mjs` when a template is not trusted by user (depending  on whether you're building an user/organization or repository template, it is advised to either use `classic` or `repository`).
 
-`extends` is used to define upon which template it should inherits its `template.mjs` when it is not trusted by user.
+`name`, `description` and `examples` are used to auto-generate documentation in the `README.md`.
 
 ### 💬 Filling `examples.yml`
 
-Workflow examples from `examples.yml` are used to auto-generate documentation in the `README.md` by replacing the following:
+Workflow examples from `examples.yml` are used to auto-generate documentation in the `README.md`.
 
+### 💬 Filling `README.md`
+
+`README.md` is used as documentation.
+
+Most of it will is auto-generated by `metadata.yml` and `examples.yml` content, so usually it is not required to manually edit it.
+
+The default content looks like below:
 ```markdown
-#### ℹ️ Examples workflows
+<ǃ--header-->
+<ǃ--/header-->
+
+## ℹ️ Examples workflows
 
 <ǃ--examples-->
 <ǃ--/examples-->
 ```
 
+- `<ǃ--header-->` will be replaced by an auto-generated header containing template name, supported features and output examples based on `metadata.yml`
+- `<ǃ--examples-->` will be replaced by workflows from `examples.yml`
+
 ### 💬 Creating partials
 
 Just create a new `.ejs` file in `partials` folder, and reference it into `partials/_.json`.
@@ -204,9 +217,9 @@ It should be able to handle gracefully plugins state and errors.
 
 Below is a minimal snippet of a partial:
 ```ejs
-<% if (plugins.gists) { %>
-  <% if (plugins.gists.error) { %>
-    <%= plugins.gists.error.message %>
+<% if (plugins.{plugin_name}) { %>
+  <% if (plugins.{plugin_name}.error) { %>
+    <%= plugins.{plugin_name}.error.message %>
   <% } else { %>
     <%# content %>
   <% } %>