mcpField
O
odoo_coding_guidelines

odoo_coding_guidelines

github.com/odoo-psOther541 installsUpdated 7w ago
Repository

About odoo_coding_guidelines

odoo_coding_guidelines is a skill for reviewing, writing, checking, or validating Odoo code against the official coding guidelines. It directs users to load guidance files by language and task, including Python, XML, JavaScript, CSS, module structure, and full reviews.

Key features

  1. 01Guidance mapped to file type
  2. 02Separate Python, XML, JavaScript, and CSS rules
  3. 03Module structure guidance
  4. 04Checklist for full code reviews
  5. 05Naming and comment principles

Use cases

  1. 01Reviewing Odoo Python models and methods
  2. 02Checking XML views or data files
  3. 03Validating JavaScript and CSS changes
  4. 04Auditing a module’s structure and naming

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/odoo-ps/ps-ai-skills --skill odoo_coding_guidelines

After installing, type/odoo_coding_guidelinesin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

checklist.md
css.md
javascript.md
python.md
structure.md
xml.md

Details

From the project README

Odoo Coding Guidelines

Use this skill when the user asks to review, check, write, or validate Odoo code against official coding standards. Source: https://www.odoo.com/documentation/19.0/contributing/development/coding_guidelines.html

Load sub-files based on what is being reviewed:

  • Python files, models, fields, methods → read python.md
  • XML views, data files, templates → read xml.md
  • JavaScript files → read javascript.md
  • CSS / SCSS files → read css.md
  • Full code review or checklist requested → read checklist.md
  • Module structure, file naming, directory layout → read structure.md

For mixed reviews (e.g. a whole module), load all relevant files.


General Principles

Language
  • All code must be in English: variable names, field names, method names, model names, comments, commit messages, XML IDs, and string literals used as technical identifiers.
Comments
  • Comments must explain WHY, never WHAT. The code itself should be readable enough to convey what it does.
  • If a comment is needed to explain what a block of code does, refactor the code until it is self-explanatory, then remove the comment.
  • Acceptable comments: hidden constraints, non-obvious invariants, workarounds for specific bugs, behavior that would surprise a reader.
Naming
  • Never truncate names to save keystrokes. Autocomplete makes long names free — short names cost readability.
    # ❌
    def comp_tot_amt(self): ...
    inv_dt = fields.Date(...)
    
    # ✅
    def _compute_total_amount(self): ...
    invoice_date = fields.Date(...)
    

Comments

Markdown supported