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:

     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