implement

You are a developer working on the **MegaLinter** project. Implement the requested changes. If a prior `/design` conversation exists, follow that specification. Otherwise, derive the implementation plan from the user's request and the existing codebase — explore with Glob/Grep before writing code. Read `.claude/rules/` for the conventions of the area you're touching: - `descriptors.md` — YAML descriptor schema and property coverage - `python-style.md` — Python conventions - `documentation.md` — Zensical markdown rules - `generated-files.md` — what NOT to edit - `testing.md` — test structure and fixtures ## Process 1. **Understand what to implement**. If `/design` produced a spec, follow it. Otherwise grep for relevant code and form a clear plan before writing. 2. **Pick the right specialist** (prefer delegation when the work fits): - Authoring/editing descriptors → use the `descriptor-expert` agent. - Brand-new linter → follow `/add-linter`. - Linter version bump → follow `/update-linter-version`. - New flavor → `/add-flavor`. New reporter → `/add-reporter`. - CVE / vulnerability → `/fix-security-issue`. 3. **Descriptor changes**: - Edit `megalinter/descriptors/<lang>.megalinter-descriptor.yml`. - Maximize property coverage — see the catalog in `.claude/agents/descriptor-expert.md`. - Always renovate-compatible pin: ```yaml install: dockerfile: - |- # renovate: datasource=pypi depName=tool-name ARG PIP_TOOL_VERSION=1.2.3 pip: - tool-name==${PIP_TOOL_VERSION} ``` - For new linters, **search the internet** to gather: rules URL, configuration URL, inline-disable URL, ignore-file URL, SPDX license, IDE extensions, SARIF support, latest version, supported platforms. 4. **Python changes** (`megalinter/`): - PEP 8 + type hints where possible. - **No docstrings** on classes/methods. - Imports at the top only — no inline / conditional / `try/except ImportError`. - Config: `megalinter.config.get(request_id, "VAR", default)` — never `os.environ`. - Logging: `logging` module — never `print()`. - Custom linter classes extend `megalinter.Linter` and stay minimal. Override only what YAML can't express. - Reporters extend `megalinter.reporters.Reporter` with `manage_activation()` and `produce_report()`. - No defensive error handling for internal paths; validate only at system boundaries. 5. **Test fixtures**: for any change affecting detection or error parsing, add/update files in `.automation/test/<test_folder>/`. Good file lints clean; bad file triggers `cli_lint_errors_regex`. 6. **Never edit generated files**: - `linters/*/Dockerfile`, `flavors/*/Dockerfile`, `flavors/*/action.yml`, `flavors/*/flavor.json`. - `megalinter/tests/test_megalinter/linters/*_test.py` files with the `automatically @generated by .automation/build.py` header. - `docs/descriptors/*`. - Schemas under `megalinter/descriptors/schemas/`. - Change the source (descriptor YAML or `.automation/build.py`) instead. 7. **Build**: after descriptor or build-logic changes, run `make megalinter-build`. Delegate to the `build-runner` agent if it gets complex. **Never run `make megalinter-build-with-doc`** — docs are owned by auto-update workflows; running it in a PR causes merge conflicts. 8. **Dependencies**: after editing `pyproject.toml`, run `uv lock`. Prefer descriptor `install:` blocks for linter-specific runtime deps over editing the core `Dockerfile`. 9. **CHANGELOG**: add a one-line user-facing entry under `## [beta] (master)` in repo-root `CHANGELOG.md`. Write it for end users per `.claude/rules/changelog.md` — lead with the benefit or required action, no implementation details in user-facing sections. Internal-only changes (refactors, test suite, repo CI, build tooling) go under the **Dev** or **CI** sections, where technical detail is fine. **Skip** for: - Routine linter version bumps (auto-upgrade workflow owns those). - CVE-ignore entries. 10. **Documentation**: improve descriptor metadata (`linter_text`, `linter_rules_url`, `ide`, `examples`) so the auto-generated `docs/descriptors/*` pages improve. Zensical: blank line after every heading, blank line before/after every list. Continue iterating until the change is complete. Do not stop to ask whether to continue mid-task. ## Important - Do not add abstractions, fallbacks, feature flags, or backwards-compatibility shims the change doesn't need. - Do not leave half-finished implementations or `// removed` placeholder comments. - Default to no comments — add one only when the WHY is non-obvious. - Linters are NOT installed locally. Final validation must happen inside Docker — that's the `/test` skill's job. $ARGUMENTS