implement

---
name: implement
description: Implement a feature, bug fix, or code change in MegaLinter. Use whenever the user asks to add a feature, fix a bug, or make a code change - with or without a prior /design phase.
disable-model-invocation: true
allowed-tools: Read Glob Grep Write Edit Bash WebSearch WebFetch
argument-hint: "[feature or change to implement]"
model: sonnet
metadata:
  internal: true
---

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