aider

Add a new argument definition using `group.add_argument(...)` inside the appropriate argument group (e.g., `model_group`, `output_group`, `git_group`). Include `--flag-name`, `type`, `default`, `help`, and optionally `env_var` for environment variable support.

Pattern: Follow the pattern of existing arguments like `--model` or `--auto-commits` in aider/args.py — each uses `group.add_argument` with metavar, default, help text, and const/action for boolean flags

If the new option needs to be changeable at runtime via a slash command, add a handler method `cmd_<name>(self, args)` and register it in the command dispatch logic

Pattern: See how `cmd_model` or `cmd_map_tokens` is implemented in aider/commands.py — each reads from `self.coder` or `self.coder.main_model` and updates state

If the argument contains sensitive data (API keys, tokens), add it to the masking logic so it is redacted in logs and settings output

Pattern: See how aider/format_settings.py masks sensitive fields — it checks argument names against known sensitive patterns and replaces values with masked strings

Add a test that verifies the new argument is parsed correctly with expected defaults and type coercion

Pattern: Follow the test structure in tests/basic/ where each test function creates an argument parser via `get_parser()` and asserts parsed values

Add a new method named `cmd_<commandname>(self, args)` to the `Commands` class. The method receives the user's arguments as a string. Use `self.io` for output, `self.coder` for accessing the current coder state, and `self.coder.repo` for git operations.

Pattern: See how `cmd_add(self, args)` and `cmd_drop(self, args)` are implemented in aider/commands.py — they parse the args string, validate input, interact with `self.coder.abs_fnames`, and call `self.io.tool_output()` for feedback

Add a docstring to the new `cmd_<commandname>` method. The first line of the docstring becomes the help text shown when users type `/help`.

Pattern: See how `cmd_help` reads docstrings from all `cmd_*` methods to build the help listing in aider/commands.py

If the command needs tab-completion, add a `completions_<commandname>(self)` method that returns a list of completion strings

Pattern: See how `completions_add(self)` returns file paths and `completions_model(self)` returns model names in aider/commands.py

Add test cases for the new command, mocking `self.io` and `self.coder` as needed

Pattern: See how tests in tests/basic/test_commands.py create a `Commands` instance with mock IO and coder objects, then call `cmd_*` methods directly and assert outcomes

Understand the base coder class which defines the interface all coder strategies must implement: `get_edits()`, `apply_edits()`, prompt template attributes (`main_system`, `example_messages`, etc.), and the `edit_format` class attribute

Pattern: Read aider/coders/base_coder.py to understand the abstract interface — all coders inherit from `Coder` and override `get_edits()` and `apply_edits()`

Use this as the reference implementation for creating a new coder. Create a new file `aider/coders/<newformat>_coder.py` with a class that inherits from `Coder`, sets `edit_format = '<newformat>'`, and implements `get_edits()` to parse LLM output and `apply_edits()` to modify files

Pattern: See how `EditBlockCoder` in aider/coders/editblock_coder.py defines `edit_format = 'diff'`, sets prompt template paths, implements `get_edits()` to parse SEARCH/REPLACE blocks, and `apply_edits()` to apply them

Create a corresponding prompts file `aider/coders/<newformat>_prompts.py` with a class containing `main_system`, `example_messages`, and `files_content_prefix` string attributes that define the LLM prompt templates for the new format

Pattern: See how aider/coders/editblock_prompts.py defines `EditBlockPrompts` with multi-line string attributes for system prompts and example conversations

Register the new coder by importing it and adding it to the coder registry so it can be selected via CLI arguments

Pattern: See how aider/coders/__init__.py imports `EditBlockCoder`, `WholeFileCoder`, `UnifiedDiffCoder` and makes them available for selection

Add the new edit format as a valid choice for the `--edit-format` argument

Pattern: See how `--edit-format` in aider/args.py lists valid format strings that map to coder classes

Add tests for the new coder's `get_edits()` parsing and `apply_edits()` file modification logic

Pattern: See how tests/basic/test_coder.py tests coder instantiation, edit parsing, and file application for existing coder types

Add the new model's metadata to the model registry. Define its name pattern, context window size, default edit format, and any provider-specific settings. If the model needs special handling, add a conditional block.

Pattern: See how aider/models.py defines model entries with attributes like `name`, `edit_format`, `weak_model_name`, `use_repo_map`, `send_undo_reply`, `accepts_images`, and `max_chat_history_tokens` — follow the pattern of existing GPT-4 or Claude model definitions

If the new provider requires custom API call handling (non-standard auth, custom headers, streaming differences), modify the `send_completion()` function to handle the provider's specifics

Pattern: See how aider/sendchat.py wraps litellm completion calls with retry logic, streaming handling, and hash-based caching — add provider-specific branches where needed

If the new provider returns unique error codes or exception types, add mappings so they produce user-friendly error messages

Pattern: See how aider/exceptions.py maps LiteLLM exception types to human-readable descriptions with retry guidance

If the provider needs a dedicated CLI shortcut flag (like `--openai` or `--anthropic`), add it to the model argument group

Pattern: See how `--model` and provider-specific shortcut flags are defined in aider/args.py

Add tests verifying the new model's metadata is correctly loaded and its edit format, context window, and capabilities are set properly

Pattern: See how tests/basic/test_models.py tests model lookup, attribute resolution, and fallback behavior

Modify the exercise loading, execution, or scoring logic. To add a new exercise set, update the directory scanning and test execution pipeline. To change scoring, modify the result collection and pass/fail determination.

Pattern: See how benchmark/benchmark.py iterates over exercise directories, runs the coder against each, executes test suites, and collects pass/fail results with timing metrics

Update visualization code if the new benchmark data needs new chart types or if scoring changes affect how results are displayed

Pattern: See how benchmark/plots.py uses matplotlib to generate bar charts and comparison plots with model names on axes and percentage scores — add new plot functions following the same `plt.figure()` / `plt.savefig()` pattern

Update the aggregation logic if new metrics or difficulty classifications are needed

Pattern: See how benchmark/problem_stats.py aggregates results across models and languages, computing solve rates and difficulty tiers

If adding a new model to benchmarks, ensure its release date is included so it appears on the timeline visualization

Pattern: See how benchmark/over_time.py maps model names to release dates and plots performance trends chronologically

Add a new event tracking method or extend an existing one. Define the event name and the properties dictionary to be sent to the analytics provider.

Pattern: See how aider/analytics.py defines event methods that check consent status before calling the provider's `track()` method with an event name string and properties dict

If the event should fire during coding operations (e.g., after an edit is applied, after a message is sent), add the analytics call at the appropriate point in the coder lifecycle

Pattern: See how aider/coders/base_coder.py calls analytics methods after key operations like sending messages or applying edits

If the event should fire when a slash command is used, add the analytics call inside the relevant `cmd_*` method

Pattern: See how aider/commands.py integrates with the analytics system by calling tracking methods from command handlers

Modify the `GitRepo` class to add new git operations (e.g., new commit strategies, branch handling, diff generation). This is the central abstraction over git operations.

Pattern: See how aider/repo.py wraps gitpython calls in methods like `commit()`, `get_diffs()`, `get_tracked_files()` — each method handles error cases and returns clean Python objects

If the change affects how the repository map (code structure summary sent to the LLM) is generated, modify the repo map builder here

Pattern: See how aider/repomap.py uses tree-sitter to parse source files, extract symbols, and build a ranked map of the most relevant code structures

If the git feature needs a user-facing command, add a `cmd_*` method that calls the new `GitRepo` method

Pattern: See how `cmd_commit` and `cmd_diff` in aider/commands.py delegate to `self.coder.repo` methods

Add tests for the new git operations using temporary git repositories

Pattern: See how tests/basic/test_repo.py creates temp directories with `git init`, makes commits, and tests `GitRepo` methods against real git state

Modify the web scraping logic to handle new content types, change parsing behavior, or add new scraping targets

Pattern: See how aider/scrape.py fetches URLs, extracts text content from HTML, and returns cleaned text suitable for LLM consumption

Modify the documentation indexing or query logic. This file builds a vector search index from markdown docs and retrieves relevant passages for /help queries.

Pattern: See how aider/help.py loads markdown files, chunks them, builds embeddings, and performs similarity search to find relevant documentation passages

If adding a new help-related command or modifying how `/help` or `/web` works, update the corresponding `cmd_*` method

Pattern: See how `cmd_help` and `cmd_web` in aider/commands.py call into aider/help.py and aider/scrape.py respectively