update cursor rule files

.cursor/rules/design_pattern/agent.mdc

@@ -12,7 +12,7 @@ Agent is a powerful design pattern in which nodes can take dynamic actions based
 ## Implement Agent with Graph
 
 1. **Context and Action:** Implement nodes that supply context and perform actions.  
-2. **Branching:** Use branching to connect each action node to an agent node. Use action to allow the agent to direct the [flow](mdc:../core_abstraction/flow.md) between nodes—and potentially loop back for multi-step.
+2. **Branching:** Use branching to connect each action node to an agent node. Use action to allow the agent to direct the [flow](../core_abstraction/flow.md) between nodes—and potentially loop back for multi-step.
 3. **Agent Node:** Provide a prompt to decide action—for example:
 
 ```python
@@ -48,7 +48,7 @@ parameters:
 
 The core of building **high-performance** and **reliable** agents boils down to:
 
-1. **Context Management:** Provide *relevant, minimal context.* For example, rather than including an entire chat history, retrieve the most relevant via [RAG](mdc:rag.md). Even with larger context windows, LLMs still fall victim to ["lost in the middle"](mdc:https:/arxiv.org/abs/2307.03172), overlooking mid-prompt content.
+1. **Context Management:** Provide *relevant, minimal context.* For example, rather than including an entire chat history, retrieve the most relevant via [RAG](mdc:./rag.md). Even with larger context windows, LLMs still fall victim to ["lost in the middle"](https://arxiv.org/abs/2307.03172), overlooking mid-prompt content.
 
 2. **Action Space:** Provide *a well-structured and unambiguous* set of actions—avoiding overlap like separate `read_databases` or  `read_csvs`. Instead, import CSVs into the database.
 

.cursor/rules/design_pattern/mapreduce.mdc

@@ -13,7 +13,7 @@ and there is a logical way to break the task into smaller, ideally independent p
 
 
 
-You first break down the task using [BatchNode](mdc:../core_abstraction/batch.md) in the map phase, followed by aggregation in the reduce phase.
+You first break down the task using [BatchNode](../core_abstraction/batch.md) in the map phase, followed by aggregation in the reduce phase.
 
 ### Example: Document Summarization
 
@@ -65,5 +65,5 @@ print("Individual Summaries:", shared["file_summaries"])
 print("\nFinal Summary:\n", shared["all_files_summary"])
 ```
 
-> **Performance Tip**: The example above works sequentially. You can speed up the map phase by running it in parallel. See [(Advanced) Parallel](mdc:../core_abstraction/parallel.md) for more details.
+> **Performance Tip**: The example above works sequentially. You can speed up the map phase by running it in parallel. See [(Advanced) Parallel](../core_abstraction/parallel.md) for more details.
 {: .note }

.cursor/rules/design_pattern/multi_agent.mdc

@@ -5,7 +5,7 @@ alwaysApply: false
 ---
 # (Advanced) Multi-Agents
 
-Multiple [Agents](mdc:flow.md) can work together by handling subtasks and communicating the progress. 
+Multiple [Agents](mdc:./flow.md) can work together by handling subtasks and communicating the progress. 
 Communication between agents is typically implemented using message queues in shared storage.
 
 > Most of time, you don't need Multi-Agents. Start with a simple solution first.

.cursor/rules/design_pattern/rag.mdc

@@ -16,9 +16,9 @@ For certain LLM tasks like answering questions, providing relevant context is es
 ## Stage 1: Offline Indexing
 
 We create three Nodes:
-1. `ChunkDocs` – [chunks](mdc:../utility_function/chunking.md) raw text.
-2. `EmbedDocs` – [embeds](mdc:../utility_function/embedding.md) each chunk.
-3. `StoreIndex` – stores embeddings into a [vector database](mdc:../utility_function/vector.md).
+1. `ChunkDocs` – [chunks](../utility_function/chunking.md) raw text.
+2. `EmbedDocs` – [embeds](../utility_function/embedding.md) each chunk.
+3. `StoreIndex` – stores embeddings into a [vector database](../utility_function/vector.md).
 
 ```python
 class ChunkDocs(BatchNode):

.cursor/rules/design_pattern/structure.mdc

@@ -81,7 +81,7 @@ summary:
         return structured_result
 ```
 
-> Besides using `assert` statements, another popular way to validate schemas is [Pydantic](mdc:https:/github.com/pydantic/pydantic)
+> Besides using `assert` statements, another popular way to validate schemas is [Pydantic](https://github.com/pydantic/pydantic)
 {: .note }
 
 ### Why YAML instead of JSON?

.cursor/rules/design_pattern/workflow.mdc

@@ -5,14 +5,14 @@ alwaysApply: false
 ---
 # Workflow
 
-Many real-world tasks are too complex for one LLM call. The solution is to **Task Decomposition**: decompose them into a [chain](mdc:../core_abstraction/flow.md) of multiple Nodes.
+Many real-world tasks are too complex for one LLM call. The solution is to **Task Decomposition**: decompose them into a [chain](../core_abstraction/flow.md) of multiple Nodes.
 
 
 
 > - You don't want to make each task **too coarse**, because it may be *too complex for one LLM call*.
 > - You don't want to make each task **too granular**, because then *the LLM call doesn't have enough context* and results are *not consistent across nodes*.
 > 
-> You usually need multiple *iterations* to find the *sweet spot*. If the task has too many *edge cases*, consider using [Agents](mdc:agent.md).
+> You usually need multiple *iterations* to find the *sweet spot*. If the task has too many *edge cases*, consider using [Agents](mdc:./agent.md).
 {: .best-practice }
 
 ### Example: Article Writing
@@ -46,4 +46,4 @@ shared = {"topic": "AI Safety"}
 writing_flow.run(shared)
 ```
 
-For *dynamic cases*, consider using [Agents](mdc:agent.md).
+For *dynamic cases*, consider using [Agents](mdc:./agent.md).