get-qodo-rules

Loads org- and repo-level coding rules from Qodo before code tasks begin, ensuring all generation and modification follows team standards. 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.

16 stars

Best use case

get-qodo-rules is best used when you need a repeatable AI agent workflow instead of a one-off prompt.

Loads org- and repo-level coding rules from Qodo before code tasks begin, ensuring all generation and modification follows team standards. 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.

Teams using get-qodo-rules should expect a more consistent output, faster repeated execution, less prompt rewriting.

When to use this skill

  • You want a reusable workflow that can be run more than once with consistent structure.

When not to use this skill

  • You only need a quick one-off answer and do not need a reusable workflow.
  • You cannot install or maintain the underlying files, dependencies, or repository context.

Installation

Claude Code / Cursor / Codex

$curl -o ~/.claude/skills/get-qodo-rules/SKILL.md --create-dirs "https://raw.githubusercontent.com/diegosouzapw/awesome-omni-skill/main/skills/development/get-qodo-rules/SKILL.md"

Manual Installation

  1. Download SKILL.md from GitHub
  2. Place it in .claude/skills/get-qodo-rules/SKILL.md inside your project
  3. Restart your AI agent — it will auto-discover the skill

How get-qodo-rules Compares

Feature / Agentget-qodo-rulesStandard Approach
Platform SupportNot specifiedLimited / Varies
Context Awareness High Baseline
Installation ComplexityUnknownN/A

Frequently Asked Questions

What does this skill do?

Loads org- and repo-level coding rules from Qodo before code tasks begin, ensuring all generation and modification follows team standards. 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.

Where can I find the source code?

You can find the source code on GitHub using the link provided at the top of the page.

Related Guides

SKILL.md Source

# Get 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 `origin` remote 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](references/repository-scope.md) 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_KEY` field). 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_NAME` field), with `QODO_ENVIRONMENT_NAME` environment 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](references/pagination.md) 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](references/output-format.md) 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](#step-2-verify-working-in-a-git-repository)):

**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_KEY` or create `~/.qodo/config.json`
- **No rules found** - Inform the user; set up rules at app.qodo.ai

Related Skills

my-react-rules

16
from diegosouzapw/awesome-omni-skill

This is a new rule

mobile-first-design-rules

16
from diegosouzapw/awesome-omni-skill

Focuses on rules and best practices for mobile-first design and responsive typography using tailwind.

history-and-next-task-rules

16
from diegosouzapw/awesome-omni-skill

Specifies the format for ending responses, including a summary of requirements, code written, source tree, and next task, applying to all files.

file-management-rules

16
from diegosouzapw/awesome-omni-skill

Specifies file management guidelines, including including full file paths as comments, updating project structure in AI.MD, and maintaining package.json. This rule ensures organized and well-documente

eslint-rules

16
from diegosouzapw/awesome-omni-skill

Use when eSLint built-in rules including rule configuration, severity levels, and disabling strategies.

editing-code-rules

16
from diegosouzapw/awesome-omni-skill

Prioritizes the method for editing code and defines verbosity levels.

cursor-rules

16
from diegosouzapw/awesome-omni-skill

This skill should be used when creating or editing Cursor rules files (.mdc format) in the .cursor/rules directory. Provides guidance on rule types, frontmatter configuration, effective rule writing patterns, and best practices for structuring AI instructions for Cursor IDE.

cursor-rules-writing

16
from diegosouzapw/awesome-omni-skill

Create Cursor IDE rules in .mdc format with proper frontmatter, glob patterns, and cross-references. Covers rule structure, file organization, triggering mechanisms, and quality standards. Use when creating or modifying Cursor rules for context injection.

creating-cursor-rules-skill

16
from diegosouzapw/awesome-omni-skill

Expert guidance for creating effective Cursor IDE rules with best practices, patterns, and examples

create-rules

16
from diegosouzapw/awesome-omni-skill

Create or update Cursor Rules (.mdc files) and Skills (SKILL.md). Use when creating rules, adding coding standards, setting up conventions, updating .cursor/rules/, or converting rules to skills. Defines standard format, naming, frontmatter, token budget.

crafting-rules

16
from diegosouzapw/awesome-omni-skill

Use when creating or modifying OpenCode rules (.md/.mdc files) that customize agent behavior. Helps extract patterns from conversation history, analyze project conventions (AGENTS.md, linters, package.json), and draft well-formatted rules with appropriate globs/keywords. Trigger when user wants to create a rule, codify repeated instructions, persist guidance across sessions, or customize agent behavior for specific files or topics.

containerization-rules

16
from diegosouzapw/awesome-omni-skill

Rules for creating and maintaining Dockerfiles.