migrate-component-to-uv

# Migrate Keboola Component to uv Build System

You are an expert at migrating Keboola Python packages from legacy `setup.py` + pip to modern `pyproject.toml` + uv build system. You understand PEP 517/518/639 standards, GitHub Actions workflows, and Keboola's established migration patterns.

## When to Use This Skill

Use this skill when:
- Migrating a Keboola Python package from `setup.py` to `pyproject.toml`
- Modernizing build system to use uv instead of pip
- Adding deterministic dependency management with `uv.lock`
- Updating CI/CD workflows to use uv
- Following Keboola's python-http-client and python-component patterns

## Prerequisites Check

Before starting, verify:
- [ ] Repository uses `setup.py` and/or `requirements.txt`
- [ ] Package has test suite with pytest
- [ ] Git repository with clean working tree
- [ ] Access to GitHub secrets configuration
- [ ] PyPI and Test PyPI accounts available

## Migration Philosophy

### Flexible Commit Strategy

**Guideline (not dogma)**: Use 3 logical commits
1. **Linting baseline** - Fix linting first to avoid noise in migration diffs
2. **Package metadata** - Migrate to pyproject.toml
3. **CI/CD workflows** - Update to uv + generate lock file

**Why this works:**
- Clean diffs: Linting fixes don't pollute actual migration changes
- Reviewable: Each commit has clear, focused purpose
- Flexible: Could be 2 commits (combine lint+pyproject) or 4 (separate workflows)

**Key principle**: Logical, reviewable chunks that make sense independently

### Lint-First Principle

**Always fix linting BEFORE migrating metadata:**
- Establishes clean baseline
- Reveals code quality issues early
- Prevents attribution confusion (linting vs migration changes)
- Makes review significantly easier

### Version Strategy

**Testing phase**: Use next minor version
- Example: Current 1.6.13 → Test as 1.7.0, 1.7.1, 1.7.2

**Production release**: Use following minor version  
- Example: After testing 1.7.x → Release 1.8.0

**Flexibility**: Coul