better doc

docs/async.md

@@ -7,7 +7,7 @@ nav_order: 5
 
 # (Advanced) Async
 
-**Async Nodes** implement `prep_async()`, `exec_async()`, `exec_fallback_async()`, and/or `post_async()`. This is useful for:
+**Async** Nodes implement `prep_async()`, `exec_async()`, `exec_fallback_async()`, and/or `post_async()`. This is useful for:
 
 1. **prep_async()**  
    - For *fetching/reading data (files, APIs, DB)* in an I/O-friendly way.

docs/communication.md

@@ -15,9 +15,8 @@ Nodes and Flows **communicate** in two ways:
 If you know memory management, **Shared Store** is like a **heap** shared across function calls, while **Params** is like a **stack** assigned by parent function calls.
 
 
-### Why Not Use Other Communication Models like Message Passing?
-
-**Message passing** works well for simple DAGs, but with **nested graphs** (Flows containing Flows, repeated or cyclic calls), routing messages becomes hard to maintain. A shared store keeps the design simple and easy.
+{: .Why-Not-Use-Other-Communication-Models-like-Message-Passing }
+*Message passing* works well for simple DAGs, but with *nested graphs* (Flows containing Flows, repeated or cyclic calls), routing messages becomes hard to maintain. A shared store keeps the design simple and easy.
 
 ---
 
@@ -74,11 +73,14 @@ No special data-passing—just the same `shared` object.
 
 ## 2. Params
 
-**Params** let you store **per-Node** or **per-Flow** config that doesn’t need to live in the global store. They are:
+**Params** let you store *per-Node* or *per-Flow* config that doesn't need to live in the shared store. They are:
 - **Immutable** during a Node’s run cycle (i.e., they don’t change mid-`prep`, `exec`, `post`).
-- **Set** via `set_params()`. **⚠️ Warning** Only set the uppermost Flow params because others will be overwritten by the parent Flow. If you need to set child node params, see [Batch](./batch.md).
+- **Set** via `set_params()`.
 - **Cleared** and updated each time a parent Flow calls it.
 
+{: .warning }
+Only set the uppermost Flow params because others will be overwritten by the parent Flow. If you need to set child node params, see [Batch](./batch.md).
+
 Typically, **Params** are identifiers (e.g., file name, page number). Use them to fetch the task you assigned or write to a specific part of the shared store.
 
 ### Example

docs/flow.md

@@ -22,7 +22,7 @@ You define transitions with the syntax:
 2. Named action transition: `node_a - "action_name" >> node_b`
   This means if `node_a.post()` returns `"action_name"`, go to `node_b`.
 
-It’s possible to create loops, branching, or multi-step flows. You can also chain with multiple Actions from a single node to different successors.
+It’s possible to create loops, branching, or multi-step flows.
 
 ## 2. Creating a Flow
 
@@ -83,10 +83,13 @@ flowchart TD
 
 ### Running Individual Nodes vs. Running a Flow
 
-- **`node.run(shared)`**: Just runs that node alone (calls `prep()`, `exec()`, `post()`), returns an Action. ⚠️ **Does not** proceed automatically to the successor and may use incorrect parameters. This is mainly for debugging or testing a single node.
-- **`flow.run(shared)`**: Executes from the start node, follows Actions to the next node, and so on until the flow can’t continue (no next node or no next Action).
+- `node.run(shared)`: Just runs that node alone (calls `prep()`, `exec()`, `post()`), returns an Action. 
+- `flow.run(shared)`: Executes from the start node, follows Actions to the next node, and so on until the flow can’t continue (no next node or no next Action).
 
-Always use `flow.run(...)` in production to ensure the full pipeline runs correctly.
+{: .warning }
+> node.run(shared) **does not** proceed automatically to the successor and may use incorrect parameters.
+> This is mainly for debugging or testing a single node.
+> Always use `flow.run(...)` in production to ensure the full pipeline runs correctly.
 
 ## 3. Nested Flows
 

docs/index.md

@@ -31,7 +31,9 @@ We model the LLM workflow as a **Nested Directed Graph**:
 - [(Advanced) Parallel](./parallel.md)
 
 ## Low-Level Details
-⚠️ We do not provide
+
+{: .note }
+We do not provide implementation
 
 - [LLM Wrapper](./llm.md)
 - [Tool](./tool.md)
@@ -40,9 +42,9 @@ We model the LLM workflow as a **Nested Directed Graph**:
 
 - [Structured Output](./structure.md)
 - Task Decomposition
+- Map Reduce
 - RAG
 - Chat Memory
-- Map Reduce
 - Agent
 - Multi-Agent
 - Evaluation

docs/node.md

@@ -25,6 +25,7 @@ A **Node** is the smallest building block of Mini LLM Flow. Each Node has 3 step
    - Examples: *finalize outputs, trigger next steps, or log results*.
    - Returns a **string** to specify the next action (`"default"` if nothing or `None` is returned).
 
+{: .note }
 All 3 steps are optional. For example, you might only need to run the Prep without calling the LLM.
 
 ## Fault Tolerance & Retries