Contributing

Here's the deal: I don't want to review big, LLM generated patches to this codebase. I haven't reviewed most of the code that I've generated; most of my confidence arises from careful prompt writing and manual testing.

So if you want to contribute a patch, here's what I'll accept:

1. A small patch that I can easily review it by hand, or

2. A prompt you used to generate the output by LLM, and evidence that you manually tested the result and it worked.

You can feel free to submit the code that the LLM generated too but for safety reasons I will regenerate the diff from your prompt myself. I also don't trust LLM generated tests, so either argue why the LLM tests are sufficient or tell me what your manual testing protocol was. I'm willing to hand-review hand-written tests, keep them separate so I can easily patch them in. If you needed to blend prompting + final touchups, keep them in separate commits and we'll figure something out.

If you're looking for backlog to tackle since you want to practice AI coding, check out https://github.com/ezyang/codemcp/issues

Local development tips

Instead of using uvx directly, I have a uv venv setup in my source directory and connect using:

    "codemcp": {
      "command": "/Users/ezyang/Dev/codemcp-prod/.venv/bin/python",
      "args": [
        "-m",
        "codemcp"
      ]
    }

I recommend using git worktree to keep a separate "prod" folder from the folder you're actually editing with Claude. You can then git checkout --detach main in the prod folder to checkout your latest changes and manually test them.

Type Checking

This project uses pyright for type checking with strict mode enabled. The type checking configuration is in pyproject.toml. We use a few strategies to maintain type safety:

1. Type stubs for external libraries:

   • Custom type stubs are in the stubs/ directory
   • The stubPackages configuration in pyproject.toml maps libraries to their stub packages

2. File-specific ignores for challenging cases:

   • For some files with complex dynamic typing patterns (particularly testing code), we use file-specific ignores via tool.pyright.ignoreExtraErrors in pyproject.toml
   • This is preferable to inline ignores and lets us maintain type safety in most of the codebase

When making changes, please ensure type checking passes by running:

./run_typecheck.sh