keboola Keboola Component Reviewer
Run both code quality and backward compatibility reviews in a single pass, unless the user asks for only one.
CRITICAL: Repos are PUBLIC. Never write client names, project names, stack URLs, or any identifying information anywhere — including PR comments. Anonymized aggregate numbers only.
1. Scope
Default: git diff $(git merge-base HEAD main)..HEAD for a PR, or git diff for unstaged changes.
Specified: files or directories the user provides.
2. Automated Checks (run first)
Run ruff before doing any manual review — it catches formatting and linting mechanically:
uv run ruff format --check . 2>&1
uv run ruff check --target-version py313 . 2>&1
If either fails, report it as a single item: "run ruff format . && ruff check --fix .". Don't enumerate individual formatting or lint violations manually — that's ruff's job. Skip any review findings that ruff would catch.
3. Code Quality Review
Focus on what ruff doesn't catch. In priority order:
Blocking — architecture violations:
run()is not a clean orchestrator (should read like a table of contents, < 30 lines)- Clients or configuration initialized inside
run()instead of__init__— breaks sync_actions - Config not encapsulated in a typed object (Pydantic BaseModel or dataclass)
Important — quality improvements:
- Missing type hints on public methods
- Deprecated typing imports (
typing.List,typing.Dict,typing.Optional) — use built-ins - Config values accessed as raw
self.configuration.parameters.get(...)scattered through the code
Only report issues with confidence ≥ 60. See code-quality.md for detailed patterns and examples.
4. Backward Compatibility Review
Step 1: Find component IDs
grep -E 'KBC_DEVELOPERPORTAL_APP|APP_ID' .github/workflows/push*.yml
Handles single env var, multiple suffixed vars, and matrix strategy patterns.
Step 2: Analyze diff
git diff $(git merge-base HEAD main)..HEAD -- \
'component_config/' 'src/configuration.py' 'src/component.py' 'Dockerfile' '.github/workflows/'
Check each changed file against the breaking change vectors in breaking-changes.md: config schema, Pydantic models, sync actions, output tables, state file, Dockerfile.
Step 3: Telemetry
If Keboola MCP is available, query telemetry for each component ID — active configs, job stats, and property usage for any changed/removed field. See telemetry.md for exact queries and anonymization rules.
When MCP is unavailable, state it explicitly and treat all changes conservatively (assume configs exist).
5. Output
Start with a 1-2 sentence overall assessment, then:
Code quality — TODOs grouped by Blocking / Important / Nice-to-Have:
### TODO N: [Title]
**Location:** `src/component.py:45-52`
**Pattern:** the specific code that's wrong
**Fix:** concrete 2-3 sentence fix
Backward compatibility — findings grouped by HIGH / MEDIUM / LOW / SAFE risk. Include telemetry table when available. End with verdict: APPROVE / REQUEST CHANGES / WARN.
Use a constructive tone — direct but kind, giving the author agency. "I'd personally..." over "you must...". "LGTM" when there's nothing to flag.