use directory instead of folder terminology

Author: harjotgill

docs/guides/customize-coderabbit.md

@@ -55,8 +55,8 @@ reviews:
       - "feat/.*"
   tools:
     ast-grep:
-      rules_folder: "custom-rules-folder-name"
-      utils_folder: "custom-utils-folder-name"
+      rules_directory: "custom-rules-directory-name"
+      utils_directory: "custom-utils-directory-name"
 chat:
   auto_reply: true
 ```
@@ -70,47 +70,48 @@ repository.
 
 YAML settings:
 
-1. **language**: Set the language for reviews using the ISO language code. For
+1. **`language`**: Set the language for reviews using the ISO language code. For
    example, `"fr"` stands for French (default:`en`).
 
-2. **early_access**: Enroll in the early access program to take advantage of
+2. **`early_access`**: Enroll in the early access program to take advantage of
    forthcoming features before their general release (default:`false`).
 
-3. **reviews**: Configurations for the code reviews.
-   - **request_changes_workflow**: Enable Request Changes review workflow for
+3. **`reviews`**: Configurations for the code reviews.
+   - **`request_changes_workflow`**: Enable request changes review workflow for
      CodeRabbit reviews. (default: `false`).
-   - **high_level_summary**: CodeRabbit generates a high level summary of the
+   - **`high_level_summary`**: CodeRabbit generates a high-level summary of the
      changes (default:`true`).
-   - **poem**: Indicates whether a creative poem should be included in the
+   - **`poem`**: Indicates whether a creative poem should be included in the
      review (default:`true`).
-   - **review_status**: Indicates the status of the review (default:`true`).
-   - **collapse_walkthrough**: Collapses the walkthrough comment
+   - **`review_status`**: Indicates the status of the review (default:`true`).
+   - **`collapse_walkthrough`**: Collapses the walkthrough comment
      (default:`false`).
-   - **path_filters**: Specifies file patterns to exclude or include for a
+   - **`path_filters`**: Specifies file patterns to exclude or include for a
      review, such as `!dist/**` and `src/**.tsx`, using glob notation.
-   - **path_instructions**: Provides specific additional guidelines for code
+   - **`path_instructions`**: Provides specific additional guidelines for code
      review based on file paths. In the given example, JavaScript files are
      singled out for checks against the Google JavaScript style guide. File path
      accepts glob pattern
-   - **auto_review**: Manages settings for automated code reviews, such as:
-     - **enabled**: Automated code review (default: `true`).
-     - **ignore_title_keywords**: Review will be ignored if a pull request title
-       contains one of the list of keywords (e.g., `"WIP"`, `"DO NOT MERGE"`).
-     - **labels**: Review will be triggered if a pull request contains one of
+   - **`auto_review`**: Manages settings for automated code reviews, such as:
+     - **`enabled`**: Automated code review (default: `true`).
+     - **`ignore_title_keywords`**: Review will be ignored if a pull request
+       title contains one of the list of keywords (e.g., `"WIP"`,
+       `"DO NOT MERGE"`).
+     - **`labels`**: Review will be triggered if a pull request contains one of
        the list of labels.
-     - **drafts**: Determines whether draft pull requests are reviewed (default:
-       `true`).
-     - **base_branches**: A list of base branches where the reviews will occur
+     - **`drafts`**: Determines whether draft pull requests are reviewed
+       (default: `true`).
+     - **`base_branches`**: A list of base branches where the reviews will occur
        apart from the default branch. Accepts regex pattern.
-   - **tools**: Configurations for the tools used in the review.
-     - **ast-grep**: Configurations for the ast-grep tool.
-       - **rules_folder**: The folder name where the custom ast-grep rules are
-         stored.
-       - **utils_folder**: The folder name where the custom ast-grep utils are
-         stored.
-4. **chat**: Defines the behavior of CodeRabbit's bot in conversations.
-   - **auto_reply**: The bot automatically replies without the need of the user
-     tagging it (default: `true`).
+   - **`tools`**: Configurations for the tools used in the review.
+     - **`ast-grep`**: Configurations for the `ast-grep` tool.
+       - **`rules_directory`**: The directory name where the custom `ast-grep`
+         rules are stored.
+       - **`utils_directory`**: The directory name where the custom `ast-grep`
+         utils are stored.
+4. **`chat`**: Defines the behavior of CodeRabbit's bot in conversations.
+   - **`auto_reply`**: The bot automatically replies without the need of the
+     user tagging it (default: `true`).
 
 Refer:
 [CodeRabbit Configuration Schema](https://coderabbit.ai/integrations/coderabbit-overrides.v2.json).
@@ -157,47 +158,45 @@ settings:
   tools:
     # tools configuration for ast-grep
     ast-grep:
-      rules_folder: "custom-rules-folder-name"
-      utils_folder: "custom-utils-folder-name"
+      rules_directory: "custom-rules-directory-name"
+      utils_directory: "custom-utils-directory-name"
 ```
 
-<!-- ![code](./images/ymlrabbit.png) -->
-
 This configuration file consists of the following settings:
 
-1. **enable_draft_pr_reviews**: Set to **false** to disable draft pull
+1. **`enable_draft_pr_reviews`**: Set to **`false`** to disable draft pull
    request(PR) reviews.
-2. **additional_branches_to_be_reviewed**: Define additional branches to be
+2. **`additional_branches_to_be_reviewed`**: Define additional branches to be
    reviewed besides the default branch.
-3. **disable_high_level_summary**: If set to **true**, disables high-level
+3. **`disable_high_level_summary`**: If set to **`true`**, disables high-level
    summary generation.
-4. **path_based_instructions**: Allows you to specify instructions based on file
-   paths. In this example, instructions for Python and JavaScript files are
+4. **`path_based_instructions`**: Allows you to specify instructions based on
+   file paths. In this example, instructions for Python and JavaScript files are
    provided, encouraging adherence to the Google style guide.
-5. **ignored_pr_titles**: Specifies ignored PR titles, in this case, "WIP" (Work
-   in Progress).
-6. **review_language**: Sets the review language to French ("fr").
-7. **disable_poem**: If set to **false**, enables the "poem" feature.
-8. **early_access_program**: Determines whether to enable the early access
-   program (set to **false** in this case).
-9. **exclude_file_patterns**: Specifies patterns for excluding certain files
+5. **`ignored_pr_titles`**: Specifies ignored PR titles, in this case, "WIP"
+   (Work in Progress).
+6. **`review_language`**: Sets the review language to French (`fr`).
+7. **`disable_poem`**: If set to **`false`**, enables the "poem" feature.
+8. **`early_access_program`**: Determines whether to enable the early access
+   program (set to **`false`** in this case).
+9. **`exclude_file_patterns`**: Specifies patterns for excluding certain files
    from review, such as `!dist/**` and `!**.md`.
-10. **limit_reviews_by_label**: Limits reviews by label, targeting "first_bug"
+10. **`limit_reviews_by_label`**: Limits reviews by label, targeting "first_bug"
     label reviews.
-11. **disable_review**: Totally disables automatic code reviews for the
+11. **`disable_review`**: Totally disables automatic code reviews for the
     repository.
-12. **disable_review_status**: This is the comment posted for each incremental
+12. **`disable_review_status`**: This is the comment posted for each incremental
     review status. This removes the review status comment. Reviews will still
     take place. However, optional comments added to the review status will not
     be posted.
-13. **collapse_walkthrough_comment**: Specifies whether to collapse walkthrough
-    comments on the review.
-14. **tools**: Configurations for the tools used in the review.
-    - **ast-grep**: Configurations for the ast-grep tool.
-      - **rules_folder**: The folder name where the custom ast-grep rules are
-        stored.
-      - **utils_folder**: The folder name where the custom ast-grep utils are
-        stored.
+13. **`collapse_walkthrough_comment`**: Specifies whether to collapse
+    walkthrough comments on the review.
+14. **`tools`**: Configurations for the tools used in the review.
+    - **`ast-grep`**: Configurations for the `ast-grep` tool.
+      - **`rules_directory`**: The directory name where the custom `ast-grep`
+        rules are stored.
+      - **`utils_directory`**: The directory name where the custom `ast-grep`
+        utils are stored.
 
 Refer:
 [CodeRabbit configuration schema](https://coderabbit.ai/integrations/coderabbit-overrides.json).
@@ -224,7 +223,7 @@ section [Prompt Customization](/guides/prompt-customization)
 feedback. CodeRabbit supports most of the widely used languages. The default
 language is English.
 
-**Disable High Level Summary:** This allows disabling high-level summary added
+**Disable High-Level Summary:** This allows disabling high-level summary added
 with the pull request description.
 
 ---

docs/guides/prompt-customization.md

@@ -7,7 +7,7 @@ description:
   options.
 ---
 
-### Path-based instructions[](https://coderabbit.ai/docs/prompt-customization#path-based-instructions)
+### Path-based instructions {#path-based-instructions}
 
 This section explains how to add custom code review instructions for the entire
 project or specific file paths in your project using glob patterns. Developers
@@ -16,22 +16,22 @@ instructions are needed only if you want the reviewer to follow specific
 instructions besides the standard review.
 
 Adding file path prompts allows developers to specify custom instructions for
-different parts of the codebase. For example, you may want to enforce style
+different parts of the codebase. For example, you may want to enforce a style
 guide by file types or directories.
 
-### Sample Usage[](https://coderabbit.ai/docs/prompt-customization#sample-usage)
+### Sample Usage {#sample-usage}
 
-**path:** `**/*.js`
+- **`path`**: `**/*.js`
 
-**instructions:** Review the JavaScript code against the Google JavaScript style
-guide and point out any mismatches
+  **`instructions`**: Review the JavaScript code against the Google JavaScript
+  style guide and point out any mismatches
 
-**path:** `tests/**.*`
+- **`path`**: `tests/**.*`
 
-**instructions:** Review the following unit test code written using the Mocha
-test library. Ensure that: The code adheres to best practices associated with
-Mocha. Descriptive test names are used to clearly convey the intent of each
-test.
+  **`instructions`**: Review the following unit test code written using the
+  Mocha test library. Ensure that: The code adheres to best practices associated
+  with Mocha. Descriptive test names are used to clearly convey the intent of
+  each test.
 
 :::note
 
@@ -45,27 +45,33 @@ test.
 
 ## Abstract Syntax Tree (AST) instructions
 
-:::note **Deep dive into AST patterns and ast-grep rules**
+:::note
+
+**Deep dive into AST patterns and `ast-grep` rules**
 
-- AST patterns [wikipedia](https://en.wikipedia.org/wiki/Abstract_syntax_tree)
-- ast-grep
+- Abstract Syntax Tree (AST)
+  [Wikipedia article](https://en.wikipedia.org/wiki/Abstract_syntax_tree)
+- `ast-grep`
   [official documentation](https://ast-grep.github.io/guide/rule-config.html)
-  for detailed guides. :::
+  for detailed guides.
 
-This section explains how to add custom code review instructions using ast-grep
-rules. ast-grep is a tool used for searching code using abstract syntax trees
-(AST) patterns.
+:::
 
-By default, you can add ast-grep rules by following these steps:
+This section explains how to add custom code review instructions using
+`ast-grep` rules. `ast-grep` is a tool used for searching code using abstract
+syntax trees (AST) patterns.
 
-1. Create a folder that keeps all the ast-grep rules in your project directory.
-2. Add individual `.yaml` files for each ast-grep rule within the newly created
-   folder.
-3. Ensure that each `.yaml` file contains the necessary ast-grep rule
+By default, you can add `ast-grep` rules by following these steps:
+
+1. Create a directory that keeps all the `ast-grep` rules in your project
+   directory.
+2. Add individual `.yaml` files for each `ast-grep` rule within the newly
+   created directory.
+3. Ensure that each `.yaml` file contains the necessary `ast-grep` rule
    configurations.
 4. Ensure that all rules contains a `message` property, that will be used in the
    review process.
-5. Add the rules folder to the `.coderabbit.yml` file under `tools.ast-grep`
+5. Add the rules' directory to the `.coderabbit.yml` file under `tools.ast-grep`
    configuration.
 
 ```yaml
@@ -74,17 +80,17 @@ reviews:
   #...
   tools:
     ast-grep:
-      rules_folder: "custom-name"
+      rules_directory: "custom-name"
   #...
 ```
 
 ### The rule object
 
-Rule object is the core concept of ast-grep's rule system and every other
+Rule object is the core concept of `ast-grep` rule system and every other
 feature is built on top of it.
 
 Below is the full list of fields in a rule object. Every rule field is optional
-and can be omitted but at least one field should be present in a rule. A node
+and can be omitted, but at least one field should be present in a rule. A node
 will match a rule if and only if it satisfies all fields in the rule object.
 
 ```yaml
@@ -121,7 +127,7 @@ The rule object is inspired by the CSS selectors but with more composability and
 expressiveness. Thinking about how selectors in CSS works can help you
 understand the rule object!
 
-> Read ast-grep
+> Read `ast-grep` >
 > [documentation](https://ast-grep.github.io/guide/rule-config.html) for
 > detailed guides.
 
@@ -140,7 +146,7 @@ Relational rule defines the relationship between two syntax nodes. There are
 four kinds of relational rule: `inside`, `has`, `follows` and `precedes`.
 
 All four relational rules accept a sub-rule object as their value. The sub-rule
-will match the surrounding node while the relational rule itself will match the
+will match the surrounding node, while the relational rule itself will match the
 target node.
 
 > Official documentation guide on
@@ -156,10 +162,10 @@ rule:
 
 #### Composite rule
 
-Composite rule defines the logical relationship between multiple sub-rules.
+A composite rule defines the logical relationship between multiple sub-rules.
 There are three kinds of composite rule: `all`, `any` and `not`.
 
-**all**
+**`all`**
 
 The `all` rule matches if all sub-rules match.
 
@@ -170,7 +176,7 @@ rule:
     - kind: expression_statement
 ```
 
-**any**
+**`any`**
 
 `any` rule matches if any sub-rule matches.
 
@@ -182,7 +188,7 @@ rule:
     - pattern: let a = $A
 ```
 
-**not**
+**`not`**
 
 `not` applies negation to a sub-rule. It matches if the sub-rule does not match.
 
@@ -198,13 +204,13 @@ rule:
 
 ### Reusing rule as utility
 
-ast-grep chooses to use YAML for rule representation. While this decision makes
-writing rules easier, it does impose some limitations on the rule authoring. One
-of the limitations is that rule objects cannot be reused.
+`ast-grep` chooses to use YAML for rule representation. While this decision
+makes writing rules easier, it does impose some limitations on the rule
+authoring. One of the limitations is that rule objects cannot be reused.
 
 #### Local utility rule
 
-Local utility rules are defined in the utils field of the config file. utils is
+Local utility rules are defined in the utils field of the config file. Utils is
 a string-keyed dictionary.
 
 For example, the following config file defines a local utility rule
@@ -226,9 +232,9 @@ rule:
 Global utility rules are defined in a separate file. But they are available
 across all rule configurations in the project.
 
-To create global utility rules, you need to have the `rules` folder created on
-the root of your project and another `utils` directory inside the root of your
-project.
+To create global utility rules, you need to have the `rules` directory created
+on the root of your project and another `utils` directory inside the root of
+your project.
 
 ```yaml
 my-awesome-project   # project root
@@ -238,17 +244,17 @@ my-awesome-project   # project root
   | |- is-literal.yml
 ```
 
-> Also, you need to add the `rules` and `utils` folders to the `.coderabbit.yml`
-> file under `tools.ast-grep` configuration.
+> Also, you need to add the `rules` and `utils` directories to the
+> `.coderabbit.yml` file under `tools.ast-grep` configuration.
 
 ```yaml
 #...
 reviews:
   #...
   tools:
     ast-grep:
-      rules_folder: "rules"
-      utils_folder: "utils"
+      rules_directory: "rules"
+      utils_directory: "utils"
   #...
 ```
 
@@ -272,7 +278,8 @@ rule:
 
 ### Multiple Languages Support
 
-CodeRabbit supports multiple programming languages for defining ast-grep rules.
+CodeRabbit supports multiple programming languages for defining `ast-grep`
+rules.
 
 - JavaScript
 - Typescript
@@ -284,7 +291,7 @@ CodeRabbit supports multiple programming languages for defining ast-grep rules.
 - Python
 - C
 
-Below are examples of ast-grep rules in different languages:
+Below are examples of `ast-grep` rules in different languages:
 
 #### JavaScript
 
@@ -309,7 +316,7 @@ rule:
           regex: "^import$"
 ```
 
-**No console.log allowed except console.error on the catch block**
+**No console.log allowed except `console.error` on the catch block**
 
 ```yaml
 id: no-console-except-error
@@ -335,9 +342,9 @@ programmers use structs and function pointers to simulate classes and methods.
 
 However, this style can have some drawbacks, such as:
 
-- extra memory allocation and reallocation for the struct and the function
+- Extra memory allocation and reallocation for the struct and the function
   pointer.
-- indirection overhead when calling the function pointer.
+- Indirection overhead when calling the function pointer.
 
 A possible alternative is to use a plain function call with the struct pointer
 as the first argument.