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.

1. 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 PIPTOOLVERSION=1.2.3 pip: - tool-name==${PIPTOOLVERSION} `` - 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.

1. 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(requestid, "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 manageactivation() and produce_report(). - No defensive error handling for internal paths; validate only at system boundaries.

1. Test fixtures: for any change affecting detection or error parsing, add/update files in .automation/test/<testfolder>/. Good file lints clean; bad file triggers clilinterrorsregex.
2. Never edit generated files:

- linters//Dockerfile, flavors//Dockerfile, flavors//action.yml, flavors//flavor.json. - megalinter/tests/testmegalinter/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.

1. 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.
2. Dependencies: after editing pyproject.toml, run uv lock. Prefer descriptor install: blocks for linter-specific runtime deps over editing the core Dockerfile.
3. 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.

1. Documentation: improve descriptor metadata (lintertext, linterrules_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