diff --git a/docs/AutoGen Core/01_agent.md b/docs/AutoGen Core/01_agent.md
index b4c730f..5f5085f 100644
--- a/docs/AutoGen Core/01_agent.md	
+++ b/docs/AutoGen Core/01_agent.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Agent"
+parent: "AutoGen Core"
+nav_order: 1
+---
+
 # Chapter 1: Agent - The Workers of AutoGen
 
 Welcome to the AutoGen Core tutorial! We're excited to guide you through building powerful applications with autonomous agents.
diff --git a/docs/AutoGen Core/02_messaging_system__topic___subscription_.md b/docs/AutoGen Core/02_messaging_system__topic___subscription_.md
index 24e8e5d..febf3d9 100644
--- a/docs/AutoGen Core/02_messaging_system__topic___subscription_.md	
+++ b/docs/AutoGen Core/02_messaging_system__topic___subscription_.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Messaging System"
+parent: "AutoGen Core"
+nav_order: 2
+---
+
 # Chapter 2: Messaging System (Topic & Subscription)
 
 In [Chapter 1: Agent](01_agent.md), we learned about Agents as individual workers. But how do they coordinate when one agent doesn't know exactly *who* needs the information it produces? Imagine our Researcher finds some facts. Maybe the Writer needs them, but maybe a Fact-Checker agent or a Summary agent also needs them later. How can the Researcher just announce "Here are the facts!" without needing a specific mailing list?
diff --git a/docs/AutoGen Core/03_agentruntime.md b/docs/AutoGen Core/03_agentruntime.md
index 09aec0e..cca5212 100644
--- a/docs/AutoGen Core/03_agentruntime.md	
+++ b/docs/AutoGen Core/03_agentruntime.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "AgentRuntime"
+parent: "AutoGen Core"
+nav_order: 3
+---
+
 # Chapter 3: AgentRuntime - The Office Manager
 
 In [Chapter 1: Agent](01_agent.md), we met the workers (`Agent`) of our system. In [Chapter 2: Messaging System](02_messaging_system__topic___subscription_.md), we saw how they can communicate broadly using topics and subscriptions. But who hires these agents? Who actually delivers the messages, whether direct or published? And who keeps the whole system running smoothly?
diff --git a/docs/AutoGen Core/04_tool.md b/docs/AutoGen Core/04_tool.md
index e526be1..e518192 100644
--- a/docs/AutoGen Core/04_tool.md	
+++ b/docs/AutoGen Core/04_tool.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Tool"
+parent: "AutoGen Core"
+nav_order: 4
+---
+
 # Chapter 4: Tool - Giving Agents Specific Capabilities
 
 In the previous chapters, we learned about Agents as workers ([Chapter 1](01_agent.md)), how they can communicate directly or using announcements ([Chapter 2](02_messaging_system__topic___subscription_.md)), and the `AgentRuntime` that manages them ([Chapter 3](03_agentruntime.md)).
diff --git a/docs/AutoGen Core/05_chatcompletionclient.md b/docs/AutoGen Core/05_chatcompletionclient.md
index fb8d5e0..1a6551b 100644
--- a/docs/AutoGen Core/05_chatcompletionclient.md	
+++ b/docs/AutoGen Core/05_chatcompletionclient.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "ChatCompletionClient"
+parent: "AutoGen Core"
+nav_order: 5
+---
+
 # Chapter 5: ChatCompletionClient - Talking to the Brains
 
 So far, we've learned about:
diff --git a/docs/AutoGen Core/06_chatcompletioncontext.md b/docs/AutoGen Core/06_chatcompletioncontext.md
index 3b04b3d..6adb204 100644
--- a/docs/AutoGen Core/06_chatcompletioncontext.md	
+++ b/docs/AutoGen Core/06_chatcompletioncontext.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "ChatCompletionContext"
+parent: "AutoGen Core"
+nav_order: 6
+---
+
 # Chapter 6: ChatCompletionContext - Remembering the Conversation
 
 In [Chapter 5: ChatCompletionClient](05_chatcompletionclient.md), we learned how agents talk to Large Language Models (LLMs) using a `ChatCompletionClient`. We saw that we need to send a list of `messages` (the conversation history) to the LLM so it knows the context.
diff --git a/docs/AutoGen Core/07_memory.md b/docs/AutoGen Core/07_memory.md
index 8e648b5..26acff6 100644
--- a/docs/AutoGen Core/07_memory.md	
+++ b/docs/AutoGen Core/07_memory.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Memory"
+parent: "AutoGen Core"
+nav_order: 7
+---
+
 # Chapter 7: Memory - The Agent's Notebook
 
 In [Chapter 6: ChatCompletionContext](06_chatcompletioncontext.md), we saw how agents manage the *short-term* history of a single conversation before talking to an LLM. It's like remembering what was just said in the last few minutes.
diff --git a/docs/AutoGen Core/08_component.md b/docs/AutoGen Core/08_component.md
index 65d019a..7487873 100644
--- a/docs/AutoGen Core/08_component.md	
+++ b/docs/AutoGen Core/08_component.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Component"
+parent: "AutoGen Core"
+nav_order: 8
+---
+
 # Chapter 8: Component - The Standardized Building Blocks
 
 Welcome to Chapter 8! In our journey so far, we've met several key players in AutoGen Core:
diff --git a/docs/AutoGen Core/index.md b/docs/AutoGen Core/index.md
index 17fee53..a5bce1f 100644
--- a/docs/AutoGen Core/index.md	
+++ b/docs/AutoGen Core/index.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "AutoGen Core"
+nav_order: 3
+has_children: true
+---
+
 # Tutorial: AutoGen Core
 
 AutoGen Core helps you build applications with multiple **_Agents_** that can work together.
diff --git a/docs/Browser Use/01_agent.md b/docs/Browser Use/01_agent.md
index e2b5e02..3955bce 100644
--- a/docs/Browser Use/01_agent.md	
+++ b/docs/Browser Use/01_agent.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Agent"
+parent: "Browser Use"
+nav_order: 1
+---
+
 # Chapter 1: The Agent - Your Browser Assistant's Brain
 
 Welcome to the `Browser Use` tutorial! We're excited to help you learn how to automate web tasks using the power of Large Language Models (LLMs).
diff --git a/docs/Browser Use/02_system_prompt.md b/docs/Browser Use/02_system_prompt.md
index 84328f1..4f5cc29 100644
--- a/docs/Browser Use/02_system_prompt.md	
+++ b/docs/Browser Use/02_system_prompt.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "System Prompt"
+parent: "Browser Use"
+nav_order: 2
+---
+
 # Chapter 2: The System Prompt - Setting the Rules for Your AI Assistant
 
 In [Chapter 1: The Agent](01_agent.md), we met the `Agent`, our project manager for automating browser tasks. We saw it consults a Large Language Model (LLM) – the "planner" – to decide the next steps based on the current state of the webpage. But how does the Agent tell the LLM *how* it should think, behave, and respond? Just giving it the task isn't enough!
diff --git a/docs/Browser Use/03_browsercontext.md b/docs/Browser Use/03_browsercontext.md
index e642caa..f164fe2 100644
--- a/docs/Browser Use/03_browsercontext.md	
+++ b/docs/Browser Use/03_browsercontext.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "BrowserContext"
+parent: "Browser Use"
+nav_order: 3
+---
+
 # Chapter 3: BrowserContext - The Agent's Isolated Workspace
 
 In the [previous chapter](02_system_prompt.md), we learned how the `System Prompt` acts as the rulebook for the AI assistant (LLM) that guides our `Agent`. We know the Agent uses the LLM to decide *what* to do next based on the current situation in the browser.
diff --git a/docs/Browser Use/04_dom_representation.md b/docs/Browser Use/04_dom_representation.md
index e83263c..721ab34 100644
--- a/docs/Browser Use/04_dom_representation.md	
+++ b/docs/Browser Use/04_dom_representation.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "DOM Representation"
+parent: "Browser Use"
+nav_order: 4
+---
+
 # Chapter 4: DOM Representation - Mapping the Webpage
 
 In the [previous chapter](03_browsercontext.md), we learned about the `BrowserContext`, the Agent's private workspace for browsing. We saw that the Agent uses `browser_context.get_state()` to get a snapshot of the current webpage. But how does the Agent actually *understand* the content of that snapshot?
diff --git a/docs/Browser Use/05_action_controller___registry.md b/docs/Browser Use/05_action_controller___registry.md
index 091f0b2..a192f2a 100644
--- a/docs/Browser Use/05_action_controller___registry.md	
+++ b/docs/Browser Use/05_action_controller___registry.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Action Controller & Registry"
+parent: "Browser Use"
+nav_order: 5
+---
+
 # Chapter 5: Action Controller & Registry - The Agent's Hands and Toolbox
 
 In the [previous chapter](04_dom_representation.md), we saw how the `DomService` creates a simplified map (`DOMState`) of the webpage, allowing the Agent and its LLM planner to identify interactive elements like buttons and input fields using unique numbers (`highlight_index`). The LLM uses this map to decide *what* specific action to take next, like "click element [5]" or "type 'hello world' into element [12]".
diff --git a/docs/Browser Use/06_message_manager.md b/docs/Browser Use/06_message_manager.md
index 8c405c4..4181a2b 100644
--- a/docs/Browser Use/06_message_manager.md	
+++ b/docs/Browser Use/06_message_manager.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Message Manager"
+parent: "Browser Use"
+nav_order: 6
+---
+
 # Chapter 6: Message Manager - Keeping the Conversation Straight
 
 In the [previous chapter](05_action_controller___registry.md), we learned how the `Action Controller` and `Registry` act as the Agent's "hands" and "toolbox", executing the specific actions decided by the LLM planner. But how does the LLM get all the information it needs to make those decisions in the first place? How does the Agent keep track of the ongoing conversation, including what it "saw" on the page and what happened after each action?
diff --git a/docs/Browser Use/07_data_structures__views_.md b/docs/Browser Use/07_data_structures__views_.md
index 9d11c09..3b55d28 100644
--- a/docs/Browser Use/07_data_structures__views_.md	
+++ b/docs/Browser Use/07_data_structures__views_.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Data Structures (Views)"
+parent: "Browser Use"
+nav_order: 7
+---
+
 # Chapter 7: Data Structures (Views) - The Project's Blueprints
 
 In the [previous chapter](06_message_manager.md), we saw how the `MessageManager` acts like a secretary, carefully organizing the conversation between the [Agent](01_agent.md) and the LLM. It manages different pieces of information – the browser's current state, the LLM's plan, the results of actions, and more.
diff --git a/docs/Browser Use/08_telemetry_service.md b/docs/Browser Use/08_telemetry_service.md
index 6f9b7df..1abbe0f 100644
--- a/docs/Browser Use/08_telemetry_service.md	
+++ b/docs/Browser Use/08_telemetry_service.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Telemetry Service"
+parent: "Browser Use"
+nav_order: 8
+---
+
 # Chapter 8: Telemetry Service - Helping Improve the Project (Optional)
 
 In the [previous chapter](07_data_structures__views_.md), we explored the essential blueprints (`Data Structures (Views)`) that keep communication clear and consistent between all the parts of `Browser Use`. We saw how components like the [Agent](01_agent.md) and the [Action Controller & Registry](05_action_controller___registry.md) use these blueprints to exchange information reliably.
diff --git a/docs/Browser Use/index.md b/docs/Browser Use/index.md
index 8865237..b1d71e1 100644
--- a/docs/Browser Use/index.md	
+++ b/docs/Browser Use/index.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Browser Use"
+nav_order: 4
+has_children: true
+---
+
 # Tutorial: Browser Use
 
 **Browser Use** is a project that allows an *AI agent* to control a web browser and perform tasks automatically.
diff --git a/docs/Celery/01_celery_app.md b/docs/Celery/01_celery_app.md
index 4124b90..c3788af 100644
--- a/docs/Celery/01_celery_app.md
+++ b/docs/Celery/01_celery_app.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Celery App"
+parent: "Celery"
+nav_order: 1
+---
+
 # Chapter 1: The Celery App - Your Task Headquarters
 
 Welcome to the world of Celery! If you've ever thought, "I wish this slow part of my web request could run somewhere else later," or "How can I process this huge amount of data without freezing my main application?", then Celery is here to help.
diff --git a/docs/Celery/index.md b/docs/Celery/index.md
index 44a0458..e1a8891 100644
--- a/docs/Celery/index.md
+++ b/docs/Celery/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Celery"
+nav_order: 5
+has_children: true
+---
+
 # Tutorial: Celery
 
 Celery is a system for running **distributed tasks** *asynchronously*. You define *units of work* (Tasks) in your Python code. When you want a task to run, you send a message using a **message broker** (like RabbitMQ or Redis). One or more **Worker** processes are running in the background, listening for these messages. When a worker receives a message, it executes the corresponding task. Optionally, the task's result (or any error) can be stored in a **Result Backend** (like Redis or a database) so you can check its status or retrieve the output later. Celery helps manage this whole process, making it easier to handle background jobs, scheduled tasks, and complex workflows.
diff --git a/docs/Click/index.md b/docs/Click/index.md
index 1d5a82f..186ffaa 100644
--- a/docs/Click/index.md
+++ b/docs/Click/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Click"
+nav_order: 6
+has_children: true
+---
+
 # Tutorial: Click
 
 Click is a Python library that makes creating **command-line interfaces (CLIs)** *easy and fun*.
diff --git a/docs/Crawl4AI/index.md b/docs/Crawl4AI/index.md
index f9d5c9d..2ac766f 100644
--- a/docs/Crawl4AI/index.md
+++ b/docs/Crawl4AI/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Crawl4AI"
+nav_order: 7
+has_children: true
+---
+
 # Tutorial: Crawl4AI
 
 `Crawl4AI` is a flexible Python library for *asynchronously crawling websites* and *extracting structured content*, specifically designed for **AI use cases**.
diff --git a/docs/CrewAI/index.md b/docs/CrewAI/index.md
index 5ca63b8..f560f2b 100644
--- a/docs/CrewAI/index.md
+++ b/docs/CrewAI/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "CrewAI"
+nav_order: 8
+has_children: true
+---
+
 # Tutorial: CrewAI
 
 **CrewAI** is a framework for orchestrating *autonomous AI agents*.
diff --git a/docs/DSPy/index.md b/docs/DSPy/index.md
index 21b0f08..7069c68 100644
--- a/docs/DSPy/index.md
+++ b/docs/DSPy/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "DSPy"
+nav_order: 9
+has_children: true
+---
+
 # Tutorial: DSPy
 
 DSPy helps you build and optimize *programs* that use **Language Models (LMs)** and **Retrieval Models (RMs)**.
diff --git a/docs/FastAPI/index.md b/docs/FastAPI/index.md
index 7748920..f94fc7c 100644
--- a/docs/FastAPI/index.md
+++ b/docs/FastAPI/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "FastAPI"
+nav_order: 10
+has_children: true
+---
+
 # Tutorial: FastAPI
 
 FastAPI is a modern, *high-performance* web framework for building APIs with Python.
diff --git a/docs/Flask/index.md b/docs/Flask/index.md
index 5eacc25..66abb33 100644
--- a/docs/Flask/index.md
+++ b/docs/Flask/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Flask"
+nav_order: 11
+has_children: true
+---
+
 # Tutorial: Flask
 
 Flask is a lightweight **web framework** for Python.
diff --git a/docs/LangGraph/index.md b/docs/LangGraph/index.md
index 6bbfdc8..89082bc 100644
--- a/docs/LangGraph/index.md
+++ b/docs/LangGraph/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "LangGraph"
+nav_order: 12
+has_children: true
+---
+
 # Tutorial: LangGraph
 
 LangGraph helps you build complex **stateful applications**, like chatbots or agents, using a *graph-based approach*.
diff --git a/docs/LevelDB/index.md b/docs/LevelDB/index.md
index 2ec4603..7f11dda 100644
--- a/docs/LevelDB/index.md
+++ b/docs/LevelDB/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "LevelDB"
+nav_order: 13
+has_children: true
+---
+
 # Tutorial: LevelDB
 
 LevelDB is a fast *key-value storage library* written at Google.
diff --git a/docs/MCP Python SDK/index.md b/docs/MCP Python SDK/index.md
index 8789634..2cfe42c 100644
--- a/docs/MCP Python SDK/index.md	
+++ b/docs/MCP Python SDK/index.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "MCP Python SDK"
+nav_order: 14
+has_children: true
+---
+
 # Tutorial: MCP Python SDK
 
 The **MCP Python SDK** helps developers build applications (clients and servers) that talk to each other using the *Model Context Protocol (MCP)* specification.
diff --git a/docs/NumPy Core/index.md b/docs/NumPy Core/index.md
index df45091..c126f3f 100644
--- a/docs/NumPy Core/index.md	
+++ b/docs/NumPy Core/index.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "NumPy Core"
+nav_order: 15
+has_children: true
+---
+
 # Tutorial: NumPy Core
 
 NumPy provides the powerful **ndarray** object, a *multi-dimensional grid* optimized for numerical computations on large datasets. It uses **dtypes** (data type objects) to precisely define the *kind of data* (like integers or floating-point numbers) stored within an array, ensuring memory efficiency and enabling optimized low-level operations. NumPy also features **ufuncs** (universal functions), which are functions like `add` or `sin` designed to operate *element-wise* on entire arrays very quickly, leveraging compiled code. Together, these components form the foundation for high-performance scientific computing in Python.
diff --git a/docs/OpenManus/index.md b/docs/OpenManus/index.md
index 70ee083..2c49350 100644
--- a/docs/OpenManus/index.md
+++ b/docs/OpenManus/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "OpenManus"
+nav_order: 16
+has_children: true
+---
+
 # Tutorial: OpenManus
 
 OpenManus is a framework for building autonomous *AI agents*.
diff --git a/docs/Pydantic Core/index.md b/docs/Pydantic Core/index.md
index 28b002f..552bd04 100644
--- a/docs/Pydantic Core/index.md	
+++ b/docs/Pydantic Core/index.md	
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Pydantic Core"
+nav_order: 17
+has_children: true
+---
+
 # Tutorial: Pydantic Core
 
 Pydantic Core provides the fundamental machinery for **data validation**, **parsing**, and **serialization** in Pydantic. It takes Python *type hints* and uses them to define how data should be structured and processed. Users typically interact with it by defining classes that inherit from `BaseModel`, which automatically gets validation and serialization capabilities based on its annotated fields. Pydantic Core ensures data conforms to the defined types and allows converting between Python objects and formats like JSON efficiently, leveraging Rust for performance.
diff --git a/docs/Requests/index.md b/docs/Requests/index.md
index 2f3e3f6..d71709f 100644
--- a/docs/Requests/index.md
+++ b/docs/Requests/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "Requests"
+nav_order: 18
+has_children: true
+---
+
 # Tutorial: Requests
 
 Requests is a Python library that makes sending *HTTP requests* incredibly simple.
diff --git a/docs/SmolaAgents/index.md b/docs/SmolaAgents/index.md
index 0cad9d5..16c6f80 100644
--- a/docs/SmolaAgents/index.md
+++ b/docs/SmolaAgents/index.md
@@ -1,3 +1,10 @@
+---
+layout: default
+title: "SmolaAgents"
+nav_order: 19
+has_children: true
+---
+
 # Tutorial: SmolaAgents
 
 `SmolaAgents` is a project for building *autonomous agents* that can solve complex tasks.
diff --git a/docs/_config.yml b/docs/_config.yml
index e3c3d17..3dc4cc8 100644
--- a/docs/_config.yml
+++ b/docs/_config.yml
@@ -1,5 +1,5 @@
 # Basic site settings
-title: Codebase to Tutorial
+title: Codebase2Tutorial
 
 # Theme settings
 remote_theme: just-the-docs/just-the-docs