get-qodo-rules
npx machina-cli add skill qwibitai/nanoclaw/get-qodo-rules --openclawGet Qodo Rules Skill
Description
Fetches repository-specific coding rules from the Qodo platform API before code generation or modification tasks. Rules include security requirements, coding standards, quality guidelines, and team conventions that must be applied during code generation. Use before any code generation or modification task when rules are not already loaded. Invoke when user asks to write, edit, refactor, or review code, or when starting implementation planning. Skip if "Qodo Rules Loaded" already appears in conversation context
Workflow
Step 1: Check if Rules Already Loaded
If rules are already loaded (look for "Qodo Rules Loaded" in recent messages), skip to step 6.
Step 2: Verify working in a git repository
- Check that the current directory is inside a git repository. If not, inform the user that a git repository is required and exit gracefully.
- Extract the repository scope from the git
originremote URL. If no remote is found, exit silently. If the URL cannot be parsed, inform the user and exit gracefully. - Detect module-level scope: if inside a
modules/*subdirectory, use it as the query scope; otherwise use repository-wide scope.
See repository scope detection for details.
Step 3: Verify Qodo Configuration
Check that the required Qodo configuration is present. The default location is ~/.qodo/config.json.
- API key: Read from
~/.qodo/config.json(API_KEYfield). If not found, inform the user that an API key is required and provide setup instructions, then exit gracefully. - Environment name: Read from
~/.qodo/config.json(ENVIRONMENT_NAMEfield), withQODO_ENVIRONMENT_NAMEenvironment variable taking precedence. If not found, inform the user that an API key is required and provide setup instructions, then exit gracefully.
Step 4: Fetch Rules with Pagination
- Fetch all pages from the API (50 rules per page) until no more results are returned.
- On each page, handle HTTP errors and exit gracefully with a user-friendly message.
- Accumulate all rules across pages into a single list.
- Stop after 100 pages maximum (safety limit).
- If no rules are found after all pages, inform the user and exit gracefully.
See pagination details for the full algorithm and error handling.
Step 5: Format and Output Rules
- Print the "📋 Qodo Rules Loaded" header with repository scope, scope context, and total rule count.
- Group rules by severity and print each non-empty group: ERROR, WARNING, RECOMMENDATION.
- Each rule is formatted as:
- **{name}** ({category}): {description} - End output with
---.
See output format details for the exact format.
Step 6: Apply Rules by Severity
| Severity | Enforcement | When Skipped |
|---|---|---|
| ERROR | Must comply, non-negotiable. Add comment documenting compliance (e.g., # Following Qodo rule: No Hardcoded Credentials) | Explain to user and ask for guidance |
| WARNING | Should comply by default | Briefly explain why in response |
| RECOMMENDATION | Consider when appropriate | No action needed |
Step 7: Report
After code generation, inform the user about rule application:
- ERROR rules applied: List which rules were followed
- WARNING rules skipped: Explain why
- No rules applicable: Inform: "No Qodo rules were applicable to this code change"
- RECOMMENDATION rules: Mention only if they influenced a design decision
How Scope Levels Work
Determines scope from git remote and working directory (see Step 2):
Scope Hierarchy:
- Universal (
/) - applies everywhere - Org Level (
/org/) - applies to organization - Repo Level (
/org/repo/) - applies to repository - Path Level (
/org/repo/path/) - applies to specific paths
Configuration
See ~/.qodo/config.json for API key setup. Set QODO_ENVIRONMENT_NAME env var or ENVIRONMENT_NAME in config to select environment.
Common Mistakes
- Re-running when rules are loaded - Check for "Qodo Rules Loaded" in context first
- Missing compliance comments on ERROR rules - ERROR rules require a comment documenting compliance
- Forgetting to report when no rules apply - Always inform the user when no rules were applicable, so they know the rules system is active
- Not in git repo - Inform the user that a git repository is required and exit gracefully; do not attempt code generation
- No API key - Inform the user with setup instructions; set
QODO_API_KEYor create~/.qodo/config.json - No rules found - Inform the user; set up rules at app.qodo.ai
Source
git clone https://github.com/qwibitai/nanoclaw/blob/main/.claude/skills/get-qodo-rules/SKILL.mdView on GitHub Overview
This skill fetches org- and repo-level coding rules from the Qodo platform API before any code generation or modification. It ensures that generated or modified code adheres to security requirements, coding standards, and team conventions.
How This Skill Works
If rules aren’t already loaded, it checks the conversation for 'Qodo Rules Loaded', confirms you’re inside a git repo, and determines the scope (module vs repository). It then reads ~/.qodo/config.json for API_KEY and ENVIRONMENT_NAME (ENV overrides if set) and fetches all rules with 50-per-page pagination up to 100 pages, formats them by severity, and presents them for enforcement.
When to Use It
- Before starting a new code task in a repository or module to ensure alignment with team standards
- When asked to write, edit, refactor, or review code to load and apply Qodo rules
- During implementation planning to incorporate security and quality guidelines
- When evaluating code changes for compliance during review
- When rules are not already loaded and you need a standards baseline prior to coding
Quick Start
- Step 1: Trigger rule load with a command like 'get-qodo-rules' before coding
- Step 2: Ensure ~/.qodo/config.json contains a valid API_KEY and ENVIRONMENT_NAME (ENV override supported)
- Step 3: Proceed with code generation or modification; rules will guide compliance and quality
Best Practices
- Ensure Qodo is configured with a valid API key in ~/.qodo/config.json
- Verify 'Qodo Rules Loaded' appears in the conversation before coding
- Respect severities: apply ERROR rules as non-negotiable and document compliance
- Correctly determine scope (module vs repo) before applying rules
- Re-run rule loading after significant config or repository changes to refresh rules
Example Use Cases
- Starting a new feature: load Qodo rules, then generate code compliant with security and style guidelines
- Refactoring a module: verify Qodo recommendations on naming, error handling, and dependencies
- Fixing a bug: ensure changes comply with mandatory ERROR rules (e.g., no hardcoded credentials)
- Code review: use Qodo rules as a checklist to assess impact on quality and security
- Implementation planning: fetch rules to inform architectural decisions and coding standards