docs: update hierarchical repository examples with generic naming conventions

docs/docs/tools/compliance.md

@@ -168,7 +168,7 @@ Qodo Merge supports hierarchical compliance checklists using a dedicated global
 ```bash
 pr-agent-settings/
 ├── metadata.yaml                              # Maps repos/folders to compliance paths
-└── compliance_standards/                      # Root for all compliance definitions
+└── codebase_standards/                        # Root for all compliance definitions
     ├── global/                                # Global compliance, inherited widely
     │   └── pr_compliance_checklist.yaml
     ├── groups/                                # For groups of repositories
@@ -181,17 +181,19 @@ pr-agent-settings/
     │   ├── cpp_repos/
     │   │   └── pr_compliance_checklist.yaml
     │   └── ...
-    ├── qodo-merge/                            # For standalone repositories
+    ├── repo_a/                                # For standalone repositories
     │   └── pr_compliance_checklist.yaml
-    ├──  qodo-monorepo/                        # For monorepo-specific compliance
+    ├──  monorepo-name/                        # For monorepo-specific compliance
     │   ├── pr_compliance_checklist.yaml       # Root-level monorepo compliance
-    │   ├── qodo-github/                       # Subproject compliance
+    │   ├── service-a/                         # Subproject compliance
     │   │   └── pr_compliance_checklist.yaml
-    │   └── qodo-gitlab/                       # Another subproject
+    │   └── service-b/                         # Another subproject
     │       └── pr_compliance_checklist.yaml
     └── ...                                    # More repositories
 ```
 
+> **Note:** In this structure, `pr-agent-settings`, `codebase_standards`, `global`, `groups`, `metadata.yaml`, and `pr_compliance_checklist.yaml` are hardcoded names that must be used exactly as shown. All other names (such as `frontend_repos`, `backend_repos`, `repo_a`, `monorepo-name`, `service-a`, etc.) are examples and should be replaced with your actual repository and service names.
+
 ???+ tip "Grouping and categorizing compliance checklists"
     - Each folder (including the global folder) can contain a single `pr_compliance_checklist.yaml` file
     - Organize repository compliance checklists by creating subfolders within the `groups` folder. Group them by purpose, programming languages, or other categories
@@ -200,9 +202,9 @@ pr-agent-settings/
 
 ```yaml
 # Standalone repos
-qodo-merge:
+repo_a:
   pr_compliance_checklist_paths:
-    - "qodo-merge"
+    - "repo_a"
 
 # Group-associated repos
 repo_b:
@@ -216,16 +218,16 @@ repo_c:
     - "groups/backend_repos"
 
 # Monorepo with subprojects
-qodo-monorepo:
+monorepo-name:
   pr_compliance_checklist_paths:
-    - "qodo-monorepo"
+    - "monorepo-name"
   monorepo_subprojects:
-    frontend:
+    service-a:
       pr_compliance_checklist_paths:
-        - "qodo-monorepo/qodo-github"
-    backend:
+        - "monorepo-name/service-a"
+    service-b:
       pr_compliance_checklist_paths:
-        - "qodo-monorepo/qodo-gitlab"
+        - "monorepo-name/service-b"
 ```
 
 4\. Set the following configuration:

docs/docs/tools/improve.md

@@ -241,17 +241,19 @@ For organizations managing multiple repositories with different requirements, Qo
        │   ├── cpp_repos/
        │   │   └── best_practices.md
        │   └── ...
-       ├── qodo-merge/                  # For standalone repositories
+       ├── repo_a/                      # For standalone repositories
        │   └── best_practices.md
-       ├── qodo-monorepo/               # For monorepo-specific rules 
+       ├── monorepo-name/               # For monorepo-specific rules 
        │   ├── best_practices.md        # Root level monorepo rules
-       │   ├── qodo-github/             # Subproject best practices
+       │   ├── service-a/               # Subproject best practices
        │   │   └── best_practices.md
-       │   └── qodo-gitlab/             # Another subproject
+       │   └── service-b/               # Another subproject
        │       └── best_practices.md
        └── ...                          # More repositories
    ```
 
+> **Note:** In this structure, `pr-agent-settings`, `codebase_standards`, `global`, `groups`, `metadata.yaml`, and `best_practices.md` are hardcoded names that must be used exactly as shown. All other names (such as `frontend_repos`, `backend_repos`, `repo_a`, `monorepo-name`, `service-a`, etc.) are examples and should be replaced with your actual repository and service names.
+
 ???+ tip "Grouping and categorizing best practices"
     - Each folder (including the global folder) can contain a single `best_practices.md` file
     - Organize repository best practices by creating subfolders within the `groups` folder. Group them by purpose, programming languages, or other categories
@@ -260,9 +262,9 @@ For organizations managing multiple repositories with different requirements, Qo
 
    ```yaml
    # Standalone repos
-   qodo-merge:
+   repo_a:
      best_practices_paths:
-       - "qodo-merge"
+       - "repo_a"
 
    # Group-associated repos
    repo_b:
@@ -276,16 +278,16 @@ For organizations managing multiple repositories with different requirements, Qo
        - "groups/backend_repos"
 
    # Monorepo with subprojects
-   qodo-monorepo:
+   monorepo-name:
      best_practices_paths:
-       - "qodo-monorepo"
+       - "monorepo-name"
      monorepo_subprojects:
-       qodo-github:
+       service-a:
          best_practices_paths:
-           - "qodo-monorepo/qodo-github"
-       qodo-gitlab:
+           - "monorepo-name/service-a"
+       service-b:
          best_practices_paths:
-           - "qodo-monorepo/qodo-gitlab"
+           - "monorepo-name/service-b"
    ```
 
 4\. Set the following configuration in your global configuration file: