Thank you for your interest in contributing to Claude Code Vision! This document provides guidelines and instructions for contributing to the project.
- Development Setup
- Project Structure
- Coding Standards
- Testing Guidelines
- Pull Request Process
- Reporting Issues
- Python 3.8 or higher
- Git
- Linux environment (X11 or Wayland)
- Screenshot tools: scrot (X11) or grim (Wayland)
- Region selection tools: slop (X11) or slurp (Wayland)
-
Clone the repository
git clone https://github.com/Patrik652/claude-code-vision.git cd claude-code-vision -
Run the installation script
./install.sh --dev
This will:
- Install system dependencies
- Create a Python virtual environment
- Install Python dependencies (including dev dependencies)
- Initialize the configuration
-
Activate the virtual environment
source venv/bin/activate -
Verify the installation
claude-vision --doctor claude-vision --test-capture
If you prefer manual setup:
-
Create virtual environment
python3 -m venv venv source venv/bin/activate -
Install dependencies
pip install --upgrade pip pip install -r requirements.txt pip install -r requirements-dev.txt pip install -e . -
Install system dependencies
- Ubuntu/Debian:
sudo apt install scrot slop grim slurp imagemagick - Fedora:
sudo dnf install scrot slop grim slurp ImageMagick - Arch:
sudo pacman -S scrot slop grim slurp imagemagick
- Ubuntu/Debian:
claude-code-vision/
├── src/
│ ├── cli/ # CLI command implementations
│ │ ├── main.py # Main CLI entry point
│ │ ├── vision_command.py # /vision command
│ │ ├── vision_area_command.py
│ │ ├── vision_auto_command.py
│ │ └── ...
│ ├── services/ # Business logic services
│ │ ├── vision_service.py # Core vision service
│ │ ├── screenshot_capture/ # Screenshot implementations
│ │ ├── image_processor.py
│ │ ├── config_manager.py
│ │ └── ...
│ ├── interfaces/ # Interface definitions (ABC)
│ │ └── screenshot_service.py
│ ├── models/ # Data models
│ │ └── entities.py
│ └── lib/ # Utility libraries
│ ├── exceptions.py # Custom exceptions
│ ├── desktop_detector.py
│ ├── tool_detector.py
│ └── logging_config.py
├── tests/
│ ├── contract/ # Contract tests (interface compliance)
│ ├── integration/ # Integration tests
│ └── unit/ # Unit tests
├── specs/ # SpecKit specifications
│ └── 002-claude-code-vision/
│ ├── spec.md
│ ├── plan.md
│ └── tasks.md
├── install.sh # Installation script
└── README.md
We follow PEP 8 with some modifications:
- Line length: 100 characters (not 79)
- Imports: Organized in groups (stdlib, third-party, local)
- Type hints: Required for all public functions
- Docstrings: Google-style docstrings for all public classes and methods
We use Black for code formatting:
black src testsWe use Ruff for linting:
ruff check src testsWe use mypy for static type checking:
mypy srcBefore committing, ensure:
- Code is formatted with Black
- No linting errors from Ruff
- Type checking passes with mypy
- All tests pass
- New code has tests
- Docstrings are complete
"""
Module docstring describing the purpose.
"""
from pathlib import Path
from typing import Optional
from src.interfaces.screenshot_service import IScreenshotCapture
from src.lib.exceptions import ScreenshotCaptureError
class MyScreenshotCapture(IScreenshotCapture):
"""
Class implementing screenshot capture.
Args:
config: Configuration object
temp_manager: Temporary file manager
Attributes:
config: Stored configuration
temp_manager: File manager instance
"""
def __init__(self, config: Configuration, temp_manager: TempFileManager):
"""Initialize the capture instance."""
self.config = config
self.temp_manager = temp_manager
def capture_full_screen(self, monitor: int = 0) -> Screenshot:
"""
Capture full screen from specified monitor.
Args:
monitor: Monitor index (0 = primary)
Returns:
Screenshot object with captured image
Raises:
ScreenshotCaptureError: If capture fails
"""
# Implementation here
passWe follow Test-First Development:
- Write the test first (it should fail)
- Implement the minimal code to make it pass
- Refactor if needed
- Repeat
We use three types of tests:
-
Contract Tests (
tests/contract/)- Verify interface implementations comply with contracts
- Test that classes implement all required methods
- Validate return types and exceptions
-
Integration Tests (
tests/integration/)- Test multiple components working together
- Test real file I/O, subprocess calls
- Test full workflows
-
Unit Tests (
tests/unit/)- Test individual functions/methods in isolation
- Use mocks/stubs for dependencies
- Fast execution
# Run all tests
pytest
# Run with coverage
pytest --cov=src --cov-report=html
# Run specific test file
pytest tests/unit/test_desktop_detector.py
# Run specific test
pytest tests/unit/test_desktop_detector.py::test_detect_x11
# Run with verbose output
pytest -v
# Run with output (don't capture stdout)
pytest -sExample test structure:
"""Tests for MyClass."""
import pytest
from unittest.mock import Mock, patch
from src.services.my_class import MyClass
class TestMyClass:
"""Test suite for MyClass."""
def test_basic_functionality(self):
"""Test basic functionality works."""
instance = MyClass()
result = instance.do_something()
assert result == expected_value
def test_error_handling(self):
"""Test error is raised correctly."""
instance = MyClass()
with pytest.raises(MyError):
instance.do_invalid_thing()
@patch('src.services.my_class.subprocess.run')
def test_with_mock(self, mock_run):
"""Test using mocked subprocess."""
mock_run.return_value = Mock(returncode=0, stdout="output")
instance = MyClass()
result = instance.run_command()
assert result == "output"-
Create a new branch
git checkout -b feature/my-new-feature
-
Make your changes
- Follow coding standards
- Write tests
- Update documentation
-
Run the test suite
pytest black src tests ruff check src tests mypy src
-
Commit your changes
git add . git commit -m "feat: add new feature"
Use conventional commits:
feat:- New featurefix:- Bug fixdocs:- Documentation changestest:- Test changesrefactor:- Code refactoringchore:- Build/tooling changes
-
Push to your fork
git push origin feature/my-new-feature
- Title: Clear, descriptive title following conventional commits
- Description: Explain what and why (not how)
- Tests: Include tests for new functionality
- Documentation: Update relevant documentation
- Single Purpose: One feature/fix per PR
- Size: Keep PRs reasonably sized (< 500 lines preferred)
## Description
Brief description of what this PR does.
## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update
## Testing
- [ ] Unit tests pass
- [ ] Integration tests pass
- [ ] Manual testing completed
## Checklist
- [ ] Code follows project style guidelines
- [ ] Self-review completed
- [ ] Comments added for complex code
- [ ] Documentation updated
- [ ] No new warnings generated
- [ ] Tests added/updatedWhen reporting bugs, include:
-
Environment
- OS and version
- Python version
- Desktop environment (X11/Wayland)
- Claude Code Vision version
-
Steps to Reproduce
- Detailed steps to reproduce the issue
- Expected behavior
- Actual behavior
-
Logs and Output
- Error messages
- Relevant log entries
- Screenshots if applicable
-
Diagnostic Output
claude-vision --doctor
When requesting features, include:
- Use Case: Describe the problem you're trying to solve
- Proposed Solution: Your idea for how to solve it
- Alternatives: Other solutions you've considered
- Priority: How important is this feature to you?
## Environment
- OS: Ubuntu 22.04
- Python: 3.10.6
- Desktop: X11
- Version: 0.1.0
## Description
Clear description of the issue.
## Steps to Reproduce
1. Step one
2. Step two
3. Step three
## Expected Behavior
What you expected to happen.
## Actual Behavior
What actually happened.
## LogsPaste relevant logs here
## Diagnostic Output
Output from claude-vision --doctor
This project follows the SpecKit methodology:
- Specify - Define requirements in
spec.md - Clarify - Resolve ambiguities
- Plan - Create implementation plan in
plan.md - Tasks - Break down into tasks in
tasks.md - Implement - Execute tasks with TDD
From our constitution (specs/002-claude-code-vision/constitution.md):
- Test-First Development - Tests before implementation
- Interface-Based Architecture - Clear contracts via ABCs
- Defense in Depth - Multiple fallback mechanisms
- Explicit Error Handling - Comprehensive error messages
- Minimal External Dependencies - Keep it simple
- Documentation: Check README.md and specs/
- Issues: Search existing issues
- Discussions: Start a discussion for questions
- Doctor: Run
claude-vision --doctorfor diagnostics
By contributing, you agree that your contributions will be licensed under the same license as the project.
Thank you for contributing to Claude Code Vision! 🎉