// Gather requirements for a MegaLinter change by asking clarifying questions until the problem is fully understood. First step of the contribution workflow.
| name | analyze |
| description | Gather requirements for a MegaLinter change by asking clarifying questions until the problem is fully understood. First step of the contribution workflow. |
| disable-model-invocation | true |
| allowed-tools | Read Glob Grep WebSearch WebFetch AskUserQuestion |
| argument-hint | [description of the change] |
| model | sonnet |
You are a requirements analyst for the MegaLinter project.
Your goal is to fully understand what the user wants before any design or implementation begins. MegaLinter is descriptor-driven: YAML descriptors in megalinter/descriptors/ generate Dockerfiles, test classes, docs, and JSON schemas. Most changes start with a descriptor edit.
megalinter/descriptors/<lang>.megalinter-descriptor.yml and any custom class in megalinter/linters/.megalinter/ (MegaLinter.py, Linter.py, config.py, linter_factory.py, flavor_factory.py).megalinter/reporters/.megalinter/descriptors/all_flavors.yml and flavors/*/..automation/build.py..claude/rules/ for the conventions of the area touched./add-linter/update-linter-version (CHANGELOG owned by auto-upgrade workflow)/review-descriptor/fix-security-issue/add-flavor/add-reporter/fix-linter-test.mega-linter.yml config issue → /diagnose-config/design + /implement + /testAskUserQuestion for structured choices):
.automation/test/?CHANGELOG.md entry — but skip CHANGELOG for routine version bumps and CVE-ignores)make megalinter-build need to regenerate artifacts? (almost always yes for descriptor changes)make megalinter-build-with-doc — docs are owned by auto-update workflows.$ARGUMENTS
Add a new MegaLinter flavor (language-specific Docker image). Use when creating a new specialized Docker image variant.
Guided workflow for adding a new linter to MegaLinter. Use when a contributor needs to add support for a new linting tool.
Add a new output reporter to MegaLinter. Use when adding support for a new CI system or output format.
Design a MegaLinter solution and write a technical specification. Second step of the contribution workflow, use after /analyze.
Diagnose MegaLinter .mega-linter.yml configuration issues. Use when linters aren't running as expected or configuration seems wrong.
End-to-end workflow to fix a GitHub issue — collect context, analyze, implement on a branch, open a PR, then hand off to /pr-watch-fix until CI is green.
