NeMo-Agent-Toolkit / rules

---
description: Follow these rules when the user's request involves creating, modifying, organizing, or structuring Cursor rules within the project
globs:
alwaysApply: false
---
# Cursor Rules Location

How to add new cursor rules to the project

1. Always place rule files in PROJECT_ROOT/.cursor/rules/:
    ```
    .cursor/rules/
    ├── your-rule-name.mdc
    ├── another-rule.mdc
    └── ...
    ```

2. Follow the naming convention:
    - Use kebab-case for filenames
    - Always use .mdc extension
    - Make names descriptive of the rule's purpose

3. Directory structure:
    ```
    PROJECT_ROOT/
    ├── .cursor/
    │   └── rules/
    │       ├── your-rule-name.mdc
    │       └── ...
    └── ...
    ```

4. For related rules sharing the same topic, create a subdirectory:
    ```
    .cursor/rules/
    ├── topic-name/
    │   ├── general.mdc          # General rules for this topic
    │   ├── specific-rule.mdc    # Specific rules within the topic
    │   └── another-rule.mdc
    ├── another-topic/
    │   ├── general.mdc
    │   └── specific-rule.mdc
    └── standalone-rule.mdc
    ```

5. When creating topic subdirectories:
    - Use kebab-case for directory names
    - Always include a `general.mdc` file with overarching guidelines for the topic
    - Place specific rules as separate .mdc files within the subdirectory
    - Example: `nat-cli/` folder contains general NAT CLI rules in `general.mdc` and specific command rules in separate files

6. For `general.mdc` files in subdirectories:
    - Always include a "Referenced Documentation" section that lists all documentation referenced in the rules
    - Format documentation references with descriptive names and brief descriptions
    - Reference the documentation section in the main rules instead of directly linking to documentation
    - Example structure:
    ```markdown
    # General Rules for [Topic]

    ## Referenced Documentation

    - **Documentation Name**: [filename.md](mdc:path/to/filename.md) - Brief description of the documentation
    - **Another Doc**: [another.md](mdc:path/to/another.md) - Description of this documentation

    ## Rules

    - Rule content referencing "the documentation listed in the Referenced Documentation section above"
    ```

7. Writing effective descriptions for Cursor rules:
    - **Start with "Follow these rules when"**: All descriptions should begin with this consistent phrase
    - **Use specific trigger conditions**: Clearly define when the rule should be requested by the agent
    - **Include relevant action verbs**: Use precise verbs like "creating", "modifying", "implementing", "configuring", "adding", "installing", "evaluating", etc.
    - **Be comprehensive but concise**: Cover all relevant scenarios without being overly verbose
    - **Use consistent terminology**: Match the language used in the project (e.g., "NAT workflows", "NAT CLI commands")
    - **Check for typos**: Ensure proper spelling and grammar (avoid errors like "ollow" instead of "Follow")
    - **Examples of good descriptions:**
      - "Follow these rules when the user's request involves creating, modifying, organizing, or structuring Cursor rules within the project"
      - "Follow these rules when the user's request involves NAT CLI commands, operations, or functionality"
      - "Follow these rules when the user's request involves implementing, adding, creating, or modifying functions within NAT workflows"
    - **Avoid overly narrow descriptions**: Don't limit to just one action when the rule covers multiple related scenarios
    - **Use "user's request involves" pattern**: This clearly indicates the trigger condition for the agent

8. Never place rule files:
    - In the project root
    - In subdirectories outside .cursor/rules
    - In any other location

9. Cursor rules have the following structure:

---
description: Short description of the rule's purpose
globs: optional/path/pattern/**/*
alwaysApply: false
---
# Rule Title

Main content explaining the rule with markdown formatting.

1. Step-by-step instructions
2. Code examples
3. Guidelines
Example:
```python
# Good example
async def good_example_function():
    """Implementation following NeMo Agent Toolkit guidelines."""
    # Use async/await for I/O operations
    # Follow snake_case naming convention
    # Include proper type hints and docstrings
    pass

# Bad example
def badExample():
    # Missing async, type hints, and docstring
    # Uses camelCase instead of snake_case
    pass
```