explain-project

Explain an existing Kedro project

Scope

Use this skill when the user wants to understand a Kedro project as it is, through a full overview or one focused question. If the request is only to write, change, fix or test code, or to audit the project against best practices, stop here: this skill has nothing to add and must not be mentioned. In a mixed request, use it for the explanation part only.

Answer in the conversation, and save an overview to a file only if the user asks. Flag concrete problems you find without fixing them. Apart from an overview file the user asks for, explaining is read-only: do not create, edit or delete project files, install packages without asking, or run the pipeline, call node functions or load datasets (Rule 7).

For the rules behind catalog entries, parameters or LLM context nodes, follow the catalog-config, parameters-and-config or llm-context-nodes skill if it is installed.

CRITICAL: Describe what Kedro resolves, not what file names or the order of code suggest. The pipeline registry decides which pipelines exist, dataset names decide the order nodes run in, and a dataset with no catalog entry or matching factory is kept in memory and never saved. A pipeline folder missing from the registry was skipped by discovery, usually after a failed import, unless the registry code leaves it out or renames it. Check the installed versions first, ask before loading the project's code, never run the pipeline, and never print credential values.

Find the project

In pyproject.toml, [tool.kedro] gives package_name and source_dir (usually src); below, src/<package>/ stands for that location. Its tools and example_pipeline keys only record kedro new options: a starter says example_pipeline = "False" and still ships pipelines. If the repository holds several Kedro projects, explain the one the request or working directory points to.

In src/<package>/settings.py, CONF_SOURCE can move the configuration folder, and CONFIG_LOADER_ARGS can rename the environments (base_env, default_run_env), change which files are read (config_patterns) or set how environments merge (merge_strategy). By default an environment replaces each top-level key it defines; soft merges nested keys instead. Runtime parameters (--params, runtime_params) are applied to the run environment before it merges with base: under the default merge, overriding model.factor replaces base's whole model group if that environment has a parameters file; with soft, or no file there, the other keys survive. The template sets OmegaConfigLoader, base_env and default_run_env itself, so only other values are customisations. Explain the environment the user names, otherwise the default run environment, and say which one you explained.