{"owner":"renovatebot","repo":"renovate","hasSkills":true,"totalSkillsCount":7,"totalTokensCount":2642,"categories":["root-instruction","claude-rule","plugin-manifest","subagent-persona"],"hasMcp":false,"mcpConfig":null,"found":["AGENTS.md","CLAUDE.md","lib/modules/datasource/gitlab-packages/readme.md","lib/modules/datasource/jenkins-plugins/readme.md","lib/modules/datasource/unity3d-packages/readme.md","lib/modules/versioning/unity3d-packages/readme.md","tools/agents/hooks/readme.md"],"skills":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance for AI agents working in this repository.\n\n## What is Renovate?\n\nRenovate is an automated dependency update tool that scans repositories for dependency files, checks for newer versions via datasources, and creates pull requests to update them. It supports 90+ package managers and multiple hosting platforms (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo, Gerrit, etc.).\n\n## Development Documentation\n\nThe **./docs/development/** directory contains detailed documentation for developers, like style guides, testing guidelines, and configuration options.\n\nALWAYS READ ./docs/development/best-practices.md for guidance on code style.\n\n## Architecture\n\nRenovate is an automated dependency update tool. The runtime flow is:\n\n```mermaid\nflowchart TD\n    entry[\"lib/renovate.ts\\nEntry Point\"]\n    global[\"Global Worker\\nOrchestration & Autodiscovery\"]\n    init[\"Init\\nClone repo, read config\"]\n    extract[\"Extract\\nScan dependency files\"]\n    lookup[\"Lookup\\nFetch versions & compare\"]\n    update[\"Update\\nWrite changes, create PRs\"]\n    finalize[\"Finalize\\nPrune branches, update cache\"]\n\n    platform([Platform])\n    manager([Manager])\n    datasource([Datasource])\n    versioning([Versioning])\n\n    entry --> global\n    global --> init\n    init --> extract\n    extract --> lookup\n    lookup --> update\n    update --> finalize\n\n    global -. \"autodiscover repos\" .-> platform\n    init -. \"clone, read config\" .-> platform\n    extract -. \"parse dep files\" .-> manager\n    lookup -. \"fetch releases\" .-> datasource\n    lookup -. \"compare versions\" .-> versioning\n    update -. \"update dep files\" .-> manager\n    update -. \"create/update PRs\" .-> platform\n    finalize -. \"prune branches\" .-> platform\n    finalize -- \"next repository\" --> init\n```\n\n### Module System (`lib/modules/`)\n\nFour module categories, each with many implementations:\n\n- **manager/** — Detects and updates dependency files (npm, maven, dockerfile, go-mod, cargo, etc.). Each manager extracts dependencies from specific file types and knows how to update them.\n- **datasource/** — Fetches version/release information from registries (npm registry, Docker Hub, GitHub releases, PyPI, etc.).\n- **versioning/** — Parses and compares version strings per ecosystem (semver, docker, maven, pep440, etc.).\n- **platform/** — Interacts with Git hosting APIs (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo, Gerrit, etc.) for PRs, issues, and comments.\n\nEach module category has an `api.ts` barrel file at its root.\n\n### Other Key Directories\n\n- **lib/config/** — Configuration parsing, validation, defaults, preset resolution\n- **lib/util/** — Shared utilities (HTTP, git, caching, regex, template, etc.)\n- **lib/workers/global/** — Top-level orchestration, autodiscovery, config loading\n- **lib/workers/repository/** — Per-repository processing pipeline\n- **lib/constants/** — Shared constants\n- **tools/** — Build tooling, doc generation, schema generation, custom lint rules\n\n### Generated Files\n\nFiles matching `*.generated.ts` in `lib/` are auto-generated during build (`pnpm generate:*`). Do not edit these directly.\n\n## Raising issues/feature requests\n\n**Do not create GitHub Issues directly.** Issue creation is restricted to repository administrators. Creating an issue as a non-administrator will result in being blocked from the repository.\n\nInstead, use **GitHub Discussions**: https://github.com/renovatebot/renovate/discussions/new/choose\n\nTwo discussion categories are available:\n\n- **Request help** (`.github/DISCUSSION_TEMPLATE/request-help.yml`) - for bugs, questions, or unexpected behavior. Include a minimal reproduction and relevant logs where possible.\n- **Suggest an idea** (`.github/DISCUSSION_TEMPLATE/suggest-an-idea.yml`) - for feature requests or improvements.\n\n**Do not attempt** to create a Discussion body without following the template, as it may result in being blocked from the repository.\n\n**Security vulnerabilities must not be reported on GitHub.** See [`SECURITY.md`](./SECURITY.md) for more details.\n\n## Contributing Notes\n\n- PRs require 100% test coverage. Use `/* v8 ignore ... */` sparingly when tests wouldn't prove anything.\n- Do not force push PR branches.\n- Follow the PR template (`.github/pull_request_template.md`). Before running `gh pr create`, read that file in full and use its exact section structure for the PR body — do not substitute a generic Summary/Test plan format.\n- PRs should be raised as a draft PR, and only marked ready once the CLA has been signed, and the user has confirmed that the changes are ready to go\n\n### Commands\n\nUse `pnpm` for all commands (NOT npm/npx).\n\n- **Install dependencies:** `pnpm install`\n- **Lint / Type-check / Test / Autofix:** `pnpm check --all <paths>` for the changed files, `pnpm check --all` without a path for a full verification. It already runs lint, prettier, type-check and the tests of those files, so do not run `pnpm type-check`, `tsc`, a separate lint or extra `pnpm vitest` runs next to it.\n- **Run from source:** `pnpm start` or `node lib/renovate.ts`\n\nTests use Vitest (invoked via `pnpm vitest`). Test files use `.spec.ts` suffix and are co-located with source. Globals from `jest-extended` and `expect-more-jest` are available in tests.\n","CLAUDE.md":"AGENTS.md","lib/modules/datasource/gitlab-packages/readme.md":"[GitLab Packages API](https://docs.gitlab.com/ee/api/packages.html) supports looking up package versions from [all types of packages registry supported by GitLab](https://docs.gitlab.com/ee/user/packages/package_registry/index.html) and can be used in combination with [regex managers](../../manager/regex/index.md) to keep dependencies up-to-date which are not specifically supported by Renovate.\n\nTo specify which specific repository should be queried when looking up a package, the `packageName` should be formed with the project path first, then a `:` and finally the package name.\n\nAs an example, `gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js` would look for the`@gitlab-org/nk-js` packages in the generic packages repository of the `gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list` project.\n\nTo specify where to find a self-hosted GitLab instance, specify `registryUrl`.\nAn example would be `https://gitlab.company.com`.\n\nIf you are using a self-hosted GitLab instance, please note the following requirements:\n\n- If you are on the `Free` edition, this datasource requires at least GitLab 13.3\n- If you are on the `Premium` or the `Ultimate` edition, this datasource requires at least GitLab 11.8, but GitLab 12.9 or more is recommended if you have a lot of packages with different names in the same project\n\n**Usage Example**\n\nA real-world example for this specific datasource would be maintaining package versions in a config file.\nThis can be achieved by configuring a custom manager in `renovate.json` for files named `versions.ini`:\n\n```json\n{\n  \"customManagers\": [\n    {\n      \"customType\": \"regex\",\n      \"managerFilePatterns\": [\"/^versions.ini$/\"],\n      \"matchStrings\": [\n        \"# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?( registryUrl=(?<registryUrl>.*?))?\\\\s.*?_VERSION=(?<currentValue>.*)\\\\s\"\n      ],\n      \"versioningTemplate\": \"{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}\"\n    }\n  ]\n}\n```\n\nNow you may use comments in your `versions.ini` files to automatically update dependencies, which could look like this:\n\n```ini\n# renovate: datasource=gitlab-packages depName=gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js versioning=semver registryUrl=https://gitlab.com\nNKJS_VERSION=3.4.0\n\n```\n\nBy default, `gitlab-packages` uses the `docker` versioning scheme.\n","lib/modules/datasource/jenkins-plugins/readme.md":"The `jenkins-plugins` datasource supports lookups from the [Jenkins Update Center](https://updates.jenkins.io/) or custom registries.\n\nWhen you define a custom registry with the `registryUrl` config option, you must follow [Jenkins' update site layout](https://github.com/jenkins-infra/update-center2/blob/master/site/LAYOUT.md).\n\nThe `update-center.actual.json` and `plugin-versions.json` files must be in the `current` path, so Renovate can find them.\nFor example, the files could be put in the `https://custom.registry.renovatebot.com/current` directory.\n","lib/modules/datasource/unity3d-packages/readme.md":"This datasource finds Unity package updates from Unity package feeds.\n\nBy default, Renovate checks `https://packages.unity.com` for Unity packages.\n\nYou can override the default behavior with the `registryUrls` config option.\nFor example:\n\n```json\n{\n  \"packageRules\": [\n    {\n      \"matchDatasources\": [\"unity3d-packages\"],\n      \"registryUrls\": [\"https://package.openupm.com\"]\n    }\n  ]\n}\n```\n","lib/modules/versioning/unity3d-packages/readme.md":"Unity versioning follow [semantic versioning](https://docs.unity3d.com/Manual/upm-semver.html), followed optionally by `-exp.#` or `-pre.#`: <https://docs.unity3d.com/Manual/upm-lifecycle.html>\n\nExamples:\n\n- `0.1.2`\n- `1.2.3-exp.1`\n- `1.3.0-pre.1`\n- `1.4.0-preview.1`\n","tools/agents/hooks/readme.md":"# Claude Code hooks\n\nThis directory contains hook scripts that Claude Code invokes automatically at key points in a session.\n\n## Hooks\n\n### `sessionstart-check.ts` — SessionStart\n\nRuns once on session startup, resume, clear, or compact.\n\nInstalls tools and dependencies so the session has a working environment:\n\n1. `mise install` — installs language runtimes declared in `.tool-versions` / `mise.toml`. Failure is non-fatal (logs a warning and continues) so the session works even without `mise`.\n2. `pnpm install` — installs Node dependencies. Failure is fatal and blocks the session.\n\n### `cwdchanged-check.ts` — CwdChanged\n\nRuns on every working-directory change, including `EnterWorktree`.\n\nInstall tools and dependencies in the new cwd, so the session has a working environment even when switching to a different worktree or subdirectory.\n\n### `pretooluse-check.ts` — PreToolUse\n\nRuns before every tool call.\n\nBlocks tool invocations that use forbidden package managers or test runners (e.g. `npm`, `yarn`, `npx`, `jest` directly) and requires `pnpm` / `vitest` instead.\n\n### `stop-check.ts` — Stop\n\nRuns when Claude Code is about to stop.\n\nExecutes `pnpm check --all` against all files changed since the base branch, including untracked files that are not ignored. If the check fails, the stop is blocked and Claude is prompted to fix the issues before finishing. The block reason includes the check output, cut down to its start and its end when it is long, so Claude sees which checks failed and why. The check only blocks a stop once: when `stop_hook_active` shows Claude is already continuing because this hook blocked it before, the stop is let through without checking again.\n\nThe check writes its coverage report to `.cache/stop-hook/coverage` (`pnpm check --coverage-dir`), so it does not clash with a manual `pnpm check` or `pnpm vitest` that uses the default `coverage` directory at the same time. After a passed check the hook stores a fingerprint of the base commit (the merge base with `origin/main`), the changed files and their contents, and the deleted files in `.cache/stop-hook/fingerprint`, and skips the check on later stops while that fingerprint is unchanged. A failed check stores no fingerprint.\n"},"files":{"AGENTS.md":"# AGENTS.md\n\nThis file provides guidance for AI agents working in this repository.\n\n## What is Renovate?\n\nRenovate is an automated dependency update tool that scans repositories for dependency files, checks for newer versions via datasources, and creates pull requests to update them. It supports 90+ package managers and multiple hosting platforms (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo, Gerrit, etc.).\n\n## Development Documentation\n\nThe **./docs/development/** directory contains detailed documentation for developers, like style guides, testing guidelines, and configuration options.\n\nALWAYS READ ./docs/development/best-practices.md for guidance on code style.\n\n## Architecture\n\nRenovate is an automated dependency update tool. The runtime flow is:\n\n```mermaid\nflowchart TD\n    entry[\"lib/renovate.ts\\nEntry Point\"]\n    global[\"Global Worker\\nOrchestration & Autodiscovery\"]\n    init[\"Init\\nClone repo, read config\"]\n    extract[\"Extract\\nScan dependency files\"]\n    lookup[\"Lookup\\nFetch versions & compare\"]\n    update[\"Update\\nWrite changes, create PRs\"]\n    finalize[\"Finalize\\nPrune branches, update cache\"]\n\n    platform([Platform])\n    manager([Manager])\n    datasource([Datasource])\n    versioning([Versioning])\n\n    entry --> global\n    global --> init\n    init --> extract\n    extract --> lookup\n    lookup --> update\n    update --> finalize\n\n    global -. \"autodiscover repos\" .-> platform\n    init -. \"clone, read config\" .-> platform\n    extract -. \"parse dep files\" .-> manager\n    lookup -. \"fetch releases\" .-> datasource\n    lookup -. \"compare versions\" .-> versioning\n    update -. \"update dep files\" .-> manager\n    update -. \"create/update PRs\" .-> platform\n    finalize -. \"prune branches\" .-> platform\n    finalize -- \"next repository\" --> init\n```\n\n### Module System (`lib/modules/`)\n\nFour module categories, each with many implementations:\n\n- **manager/** — Detects and updates dependency files (npm, maven, dockerfile, go-mod, cargo, etc.). Each manager extracts dependencies from specific file types and knows how to update them.\n- **datasource/** — Fetches version/release information from registries (npm registry, Docker Hub, GitHub releases, PyPI, etc.).\n- **versioning/** — Parses and compares version strings per ecosystem (semver, docker, maven, pep440, etc.).\n- **platform/** — Interacts with Git hosting APIs (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo, Gerrit, etc.) for PRs, issues, and comments.\n\nEach module category has an `api.ts` barrel file at its root.\n\n### Other Key Directories\n\n- **lib/config/** — Configuration parsing, validation, defaults, preset resolution\n- **lib/util/** — Shared utilities (HTTP, git, caching, regex, template, etc.)\n- **lib/workers/global/** — Top-level orchestration, autodiscovery, config loading\n- **lib/workers/repository/** — Per-repository processing pipeline\n- **lib/constants/** — Shared constants\n- **tools/** — Build tooling, doc generation, schema generation, custom lint rules\n\n### Generated Files\n\nFiles matching `*.generated.ts` in `lib/` are auto-generated during build (`pnpm generate:*`). Do not edit these directly.\n\n## Raising issues/feature requests\n\n**Do not create GitHub Issues directly.** Issue creation is restricted to repository administrators. Creating an issue as a non-administrator will result in being blocked from the repository.\n\nInstead, use **GitHub Discussions**: https://github.com/renovatebot/renovate/discussions/new/choose\n\nTwo discussion categories are available:\n\n- **Request help** (`.github/DISCUSSION_TEMPLATE/request-help.yml`) - for bugs, questions, or unexpected behavior. Include a minimal reproduction and relevant logs where possible.\n- **Suggest an idea** (`.github/DISCUSSION_TEMPLATE/suggest-an-idea.yml`) - for feature requests or improvements.\n\n**Do not attempt** to create a Discussion body without following the template, as it may result in being blocked from the repository.\n\n**Security vulnerabilities must not be reported on GitHub.** See [`SECURITY.md`](./SECURITY.md) for more details.\n\n## Contributing Notes\n\n- PRs require 100% test coverage. Use `/* v8 ignore ... */` sparingly when tests wouldn't prove anything.\n- Do not force push PR branches.\n- Follow the PR template (`.github/pull_request_template.md`). Before running `gh pr create`, read that file in full and use its exact section structure for the PR body — do not substitute a generic Summary/Test plan format.\n- PRs should be raised as a draft PR, and only marked ready once the CLA has been signed, and the user has confirmed that the changes are ready to go\n\n### Commands\n\nUse `pnpm` for all commands (NOT npm/npx).\n\n- **Install dependencies:** `pnpm install`\n- **Lint / Type-check / Test / Autofix:** `pnpm check --all <paths>` for the changed files, `pnpm check --all` without a path for a full verification. It already runs lint, prettier, type-check and the tests of those files, so do not run `pnpm type-check`, `tsc`, a separate lint or extra `pnpm vitest` runs next to it.\n- **Run from source:** `pnpm start` or `node lib/renovate.ts`\n\nTests use Vitest (invoked via `pnpm vitest`). Test files use `.spec.ts` suffix and are co-located with source. Globals from `jest-extended` and `expect-more-jest` are available in tests.\n","CLAUDE.md":"AGENTS.md","lib/modules/datasource/gitlab-packages/readme.md":"[GitLab Packages API](https://docs.gitlab.com/ee/api/packages.html) supports looking up package versions from [all types of packages registry supported by GitLab](https://docs.gitlab.com/ee/user/packages/package_registry/index.html) and can be used in combination with [regex managers](../../manager/regex/index.md) to keep dependencies up-to-date which are not specifically supported by Renovate.\n\nTo specify which specific repository should be queried when looking up a package, the `packageName` should be formed with the project path first, then a `:` and finally the package name.\n\nAs an example, `gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js` would look for the`@gitlab-org/nk-js` packages in the generic packages repository of the `gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list` project.\n\nTo specify where to find a self-hosted GitLab instance, specify `registryUrl`.\nAn example would be `https://gitlab.company.com`.\n\nIf you are using a self-hosted GitLab instance, please note the following requirements:\n\n- If you are on the `Free` edition, this datasource requires at least GitLab 13.3\n- If you are on the `Premium` or the `Ultimate` edition, this datasource requires at least GitLab 11.8, but GitLab 12.9 or more is recommended if you have a lot of packages with different names in the same project\n\n**Usage Example**\n\nA real-world example for this specific datasource would be maintaining package versions in a config file.\nThis can be achieved by configuring a custom manager in `renovate.json` for files named `versions.ini`:\n\n```json\n{\n  \"customManagers\": [\n    {\n      \"customType\": \"regex\",\n      \"managerFilePatterns\": [\"/^versions.ini$/\"],\n      \"matchStrings\": [\n        \"# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?( registryUrl=(?<registryUrl>.*?))?\\\\s.*?_VERSION=(?<currentValue>.*)\\\\s\"\n      ],\n      \"versioningTemplate\": \"{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}\"\n    }\n  ]\n}\n```\n\nNow you may use comments in your `versions.ini` files to automatically update dependencies, which could look like this:\n\n```ini\n# renovate: datasource=gitlab-packages depName=gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js versioning=semver registryUrl=https://gitlab.com\nNKJS_VERSION=3.4.0\n\n```\n\nBy default, `gitlab-packages` uses the `docker` versioning scheme.\n","lib/modules/datasource/jenkins-plugins/readme.md":"The `jenkins-plugins` datasource supports lookups from the [Jenkins Update Center](https://updates.jenkins.io/) or custom registries.\n\nWhen you define a custom registry with the `registryUrl` config option, you must follow [Jenkins' update site layout](https://github.com/jenkins-infra/update-center2/blob/master/site/LAYOUT.md).\n\nThe `update-center.actual.json` and `plugin-versions.json` files must be in the `current` path, so Renovate can find them.\nFor example, the files could be put in the `https://custom.registry.renovatebot.com/current` directory.\n","lib/modules/datasource/unity3d-packages/readme.md":"This datasource finds Unity package updates from Unity package feeds.\n\nBy default, Renovate checks `https://packages.unity.com` for Unity packages.\n\nYou can override the default behavior with the `registryUrls` config option.\nFor example:\n\n```json\n{\n  \"packageRules\": [\n    {\n      \"matchDatasources\": [\"unity3d-packages\"],\n      \"registryUrls\": [\"https://package.openupm.com\"]\n    }\n  ]\n}\n```\n","lib/modules/versioning/unity3d-packages/readme.md":"Unity versioning follow [semantic versioning](https://docs.unity3d.com/Manual/upm-semver.html), followed optionally by `-exp.#` or `-pre.#`: <https://docs.unity3d.com/Manual/upm-lifecycle.html>\n\nExamples:\n\n- `0.1.2`\n- `1.2.3-exp.1`\n- `1.3.0-pre.1`\n- `1.4.0-preview.1`\n","tools/agents/hooks/readme.md":"# Claude Code hooks\n\nThis directory contains hook scripts that Claude Code invokes automatically at key points in a session.\n\n## Hooks\n\n### `sessionstart-check.ts` — SessionStart\n\nRuns once on session startup, resume, clear, or compact.\n\nInstalls tools and dependencies so the session has a working environment:\n\n1. `mise install` — installs language runtimes declared in `.tool-versions` / `mise.toml`. Failure is non-fatal (logs a warning and continues) so the session works even without `mise`.\n2. `pnpm install` — installs Node dependencies. Failure is fatal and blocks the session.\n\n### `cwdchanged-check.ts` — CwdChanged\n\nRuns on every working-directory change, including `EnterWorktree`.\n\nInstall tools and dependencies in the new cwd, so the session has a working environment even when switching to a different worktree or subdirectory.\n\n### `pretooluse-check.ts` — PreToolUse\n\nRuns before every tool call.\n\nBlocks tool invocations that use forbidden package managers or test runners (e.g. `npm`, `yarn`, `npx`, `jest` directly) and requires `pnpm` / `vitest` instead.\n\n### `stop-check.ts` — Stop\n\nRuns when Claude Code is about to stop.\n\nExecutes `pnpm check --all` against all files changed since the base branch, including untracked files that are not ignored. If the check fails, the stop is blocked and Claude is prompted to fix the issues before finishing. The block reason includes the check output, cut down to its start and its end when it is long, so Claude sees which checks failed and why. The check only blocks a stop once: when `stop_hook_active` shows Claude is already continuing because this hook blocked it before, the stop is let through without checking again.\n\nThe check writes its coverage report to `.cache/stop-hook/coverage` (`pnpm check --coverage-dir`), so it does not clash with a manual `pnpm check` or `pnpm vitest` that uses the default `coverage` directory at the same time. After a passed check the hook stores a fingerprint of the base commit (the merge base with `origin/main`), the changed files and their contents, and the deleted files in `.cache/stop-hook/fingerprint`, and skips the check on later stops while that fingerprint is unchanged. A failed check stores no fingerprint.\n"},"items":[{"name":"AGENTS.md","path":"AGENTS.md","rawUrl":"https://raw.githubusercontent.com/renovatebot/renovate/HEAD/AGENTS.md","title":"AI Agent Protocol & Instructions","category":"root-instruction","format":"markdown","content":"# AGENTS.md\n\nThis file provides guidance for AI agents working in this repository.\n\n## What is Renovate?\n\nRenovate is an automated dependency update tool that scans repositories for dependency files, checks for newer versions via datasources, and creates pull requests to update them. It supports 90+ package managers and multiple hosting platforms (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo, Gerrit, etc.).\n\n## Development Documentation\n\nThe **./docs/development/** directory contains detailed documentation for developers, like style guides, testing guidelines, and configuration options.\n\nALWAYS READ ./docs/development/best-practices.md for guidance on code style.\n\n## Architecture\n\nRenovate is an automated dependency update tool. The runtime flow is:\n\n```mermaid\nflowchart TD\n    entry[\"lib/renovate.ts\\nEntry Point\"]\n    global[\"Global Worker\\nOrchestration & Autodiscovery\"]\n    init[\"Init\\nClone repo, read config\"]\n    extract[\"Extract\\nScan dependency files\"]\n    lookup[\"Lookup\\nFetch versions & compare\"]\n    update[\"Update\\nWrite changes, create PRs\"]\n    finalize[\"Finalize\\nPrune branches, update cache\"]\n\n    platform([Platform])\n    manager([Manager])\n    datasource([Datasource])\n    versioning([Versioning])\n\n    entry --> global\n    global --> init\n    init --> extract\n    extract --> lookup\n    lookup --> update\n    update --> finalize\n\n    global -. \"autodiscover repos\" .-> platform\n    init -. \"clone, read config\" .-> platform\n    extract -. \"parse dep files\" .-> manager\n    lookup -. \"fetch releases\" .-> datasource\n    lookup -. \"compare versions\" .-> versioning\n    update -. \"update dep files\" .-> manager\n    update -. \"create/update PRs\" .-> platform\n    finalize -. \"prune branches\" .-> platform\n    finalize -- \"next repository\" --> init\n```\n\n### Module System (`lib/modules/`)\n\nFour module categories, each with many implementations:\n\n- **manager/** — Detects and updates dependency files (npm, maven, dockerfile, go-mod, cargo, etc.). Each manager extracts dependencies from specific file types and knows how to update them.\n- **datasource/** — Fetches version/release information from registries (npm registry, Docker Hub, GitHub releases, PyPI, etc.).\n- **versioning/** — Parses and compares version strings per ecosystem (semver, docker, maven, pep440, etc.).\n- **platform/** — Interacts with Git hosting APIs (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo, Gerrit, etc.) for PRs, issues, and comments.\n\nEach module category has an `api.ts` barrel file at its root.\n\n### Other Key Directories\n\n- **lib/config/** — Configuration parsing, validation, defaults, preset resolution\n- **lib/util/** — Shared utilities (HTTP, git, caching, regex, template, etc.)\n- **lib/workers/global/** — Top-level orchestration, autodiscovery, config loading\n- **lib/workers/repository/** — Per-repository processing pipeline\n- **lib/constants/** — Shared constants\n- **tools/** — Build tooling, doc generation, schema generation, custom lint rules\n\n### Generated Files\n\nFiles matching `*.generated.ts` in `lib/` are auto-generated during build (`pnpm generate:*`). Do not edit these directly.\n\n## Raising issues/feature requests\n\n**Do not create GitHub Issues directly.** Issue creation is restricted to repository administrators. Creating an issue as a non-administrator will result in being blocked from the repository.\n\nInstead, use **GitHub Discussions**: https://github.com/renovatebot/renovate/discussions/new/choose\n\nTwo discussion categories are available:\n\n- **Request help** (`.github/DISCUSSION_TEMPLATE/request-help.yml`) - for bugs, questions, or unexpected behavior. Include a minimal reproduction and relevant logs where possible.\n- **Suggest an idea** (`.github/DISCUSSION_TEMPLATE/suggest-an-idea.yml`) - for feature requests or improvements.\n\n**Do not attempt** to create a Discussion body without following the template, as it may result in being blocked from the repository.\n\n**Security vulnerabilities must not be reported on GitHub.** See [`SECURITY.md`](./SECURITY.md) for more details.\n\n## Contributing Notes\n\n- PRs require 100% test coverage. Use `/* v8 ignore ... */` sparingly when tests wouldn't prove anything.\n- Do not force push PR branches.\n- Follow the PR template (`.github/pull_request_template.md`). Before running `gh pr create`, read that file in full and use its exact section structure for the PR body — do not substitute a generic Summary/Test plan format.\n- PRs should be raised as a draft PR, and only marked ready once the CLA has been signed, and the user has confirmed that the changes are ready to go\n\n### Commands\n\nUse `pnpm` for all commands (NOT npm/npx).\n\n- **Install dependencies:** `pnpm install`\n- **Lint / Type-check / Test / Autofix:** `pnpm check --all <paths>` for the changed files, `pnpm check --all` without a path for a full verification. It already runs lint, prettier, type-check and the tests of those files, so do not run `pnpm type-check`, `tsc`, a separate lint or extra `pnpm vitest` runs next to it.\n- **Run from source:** `pnpm start` or `node lib/renovate.ts`\n\nTests use Vitest (invoked via `pnpm vitest`). Test files use `.spec.ts` suffix and are co-located with source. Globals from `jest-extended` and `expect-more-jest` are available in tests.\n","isInternal":false,"tokens":1230,"sizeBytes":5289},{"name":"CLAUDE.md","path":"CLAUDE.md","rawUrl":"https://raw.githubusercontent.com/renovatebot/renovate/HEAD/CLAUDE.md","title":"Claude Agent Guidelines & System Prompt","category":"claude-rule","format":"markdown","content":"AGENTS.md","isInternal":false,"tokens":3,"sizeBytes":9},{"name":"readme.md","path":"tools/agents/hooks/readme.md","rawUrl":"https://raw.githubusercontent.com/renovatebot/renovate/HEAD/tools/agents/hooks/readme.md","title":"Subagent: readme","category":"subagent-persona","format":"markdown","content":"# Claude Code hooks\n\nThis directory contains hook scripts that Claude Code invokes automatically at key points in a session.\n\n## Hooks\n\n### `sessionstart-check.ts` — SessionStart\n\nRuns once on session startup, resume, clear, or compact.\n\nInstalls tools and dependencies so the session has a working environment:\n\n1. `mise install` — installs language runtimes declared in `.tool-versions` / `mise.toml`. Failure is non-fatal (logs a warning and continues) so the session works even without `mise`.\n2. `pnpm install` — installs Node dependencies. Failure is fatal and blocks the session.\n\n### `cwdchanged-check.ts` — CwdChanged\n\nRuns on every working-directory change, including `EnterWorktree`.\n\nInstall tools and dependencies in the new cwd, so the session has a working environment even when switching to a different worktree or subdirectory.\n\n### `pretooluse-check.ts` — PreToolUse\n\nRuns before every tool call.\n\nBlocks tool invocations that use forbidden package managers or test runners (e.g. `npm`, `yarn`, `npx`, `jest` directly) and requires `pnpm` / `vitest` instead.\n\n### `stop-check.ts` — Stop\n\nRuns when Claude Code is about to stop.\n\nExecutes `pnpm check --all` against all files changed since the base branch, including untracked files that are not ignored. If the check fails, the stop is blocked and Claude is prompted to fix the issues before finishing. The block reason includes the check output, cut down to its start and its end when it is long, so Claude sees which checks failed and why. The check only blocks a stop once: when `stop_hook_active` shows Claude is already continuing because this hook blocked it before, the stop is let through without checking again.\n\nThe check writes its coverage report to `.cache/stop-hook/coverage` (`pnpm check --coverage-dir`), so it does not clash with a manual `pnpm check` or `pnpm vitest` that uses the default `coverage` directory at the same time. After a passed check the hook stores a fingerprint of the base commit (the merge base with `origin/main`), the changed files and their contents, and the deleted files in `.cache/stop-hook/fingerprint`, and skips the check on later stops while that fingerprint is unchanged. A failed check stores no fingerprint.\n","isInternal":false,"tokens":494,"sizeBytes":2239},{"name":"readme.md","path":"lib/modules/datasource/gitlab-packages/readme.md","rawUrl":"https://raw.githubusercontent.com/renovatebot/renovate/HEAD/lib/modules/datasource/gitlab-packages/readme.md","title":"gitlab-packages Documentation","category":"plugin-manifest","format":"markdown","content":"[GitLab Packages API](https://docs.gitlab.com/ee/api/packages.html) supports looking up package versions from [all types of packages registry supported by GitLab](https://docs.gitlab.com/ee/user/packages/package_registry/index.html) and can be used in combination with [regex managers](../../manager/regex/index.md) to keep dependencies up-to-date which are not specifically supported by Renovate.\n\nTo specify which specific repository should be queried when looking up a package, the `packageName` should be formed with the project path first, then a `:` and finally the package name.\n\nAs an example, `gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js` would look for the`@gitlab-org/nk-js` packages in the generic packages repository of the `gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list` project.\n\nTo specify where to find a self-hosted GitLab instance, specify `registryUrl`.\nAn example would be `https://gitlab.company.com`.\n\nIf you are using a self-hosted GitLab instance, please note the following requirements:\n\n- If you are on the `Free` edition, this datasource requires at least GitLab 13.3\n- If you are on the `Premium` or the `Ultimate` edition, this datasource requires at least GitLab 11.8, but GitLab 12.9 or more is recommended if you have a lot of packages with different names in the same project\n\n**Usage Example**\n\nA real-world example for this specific datasource would be maintaining package versions in a config file.\nThis can be achieved by configuring a custom manager in `renovate.json` for files named `versions.ini`:\n\n```json\n{\n  \"customManagers\": [\n    {\n      \"customType\": \"regex\",\n      \"managerFilePatterns\": [\"/^versions.ini$/\"],\n      \"matchStrings\": [\n        \"# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?( registryUrl=(?<registryUrl>.*?))?\\\\s.*?_VERSION=(?<currentValue>.*)\\\\s\"\n      ],\n      \"versioningTemplate\": \"{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}\"\n    }\n  ]\n}\n```\n\nNow you may use comments in your `versions.ini` files to automatically update dependencies, which could look like this:\n\n```ini\n# renovate: datasource=gitlab-packages depName=gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js versioning=semver registryUrl=https://gitlab.com\nNKJS_VERSION=3.4.0\n\n```\n\nBy default, `gitlab-packages` uses the `docker` versioning scheme.\n","isInternal":false,"tokens":595,"sizeBytes":2433},{"name":"readme.md","path":"lib/modules/datasource/jenkins-plugins/readme.md","rawUrl":"https://raw.githubusercontent.com/renovatebot/renovate/HEAD/lib/modules/datasource/jenkins-plugins/readme.md","title":"jenkins-plugins Documentation","category":"plugin-manifest","format":"markdown","content":"The `jenkins-plugins` datasource supports lookups from the [Jenkins Update Center](https://updates.jenkins.io/) or custom registries.\n\nWhen you define a custom registry with the `registryUrl` config option, you must follow [Jenkins' update site layout](https://github.com/jenkins-infra/update-center2/blob/master/site/LAYOUT.md).\n\nThe `update-center.actual.json` and `plugin-versions.json` files must be in the `current` path, so Renovate can find them.\nFor example, the files could be put in the `https://custom.registry.renovatebot.com/current` directory.\n","isInternal":false,"tokens":130,"sizeBytes":558},{"name":"readme.md","path":"lib/modules/datasource/unity3d-packages/readme.md","rawUrl":"https://raw.githubusercontent.com/renovatebot/renovate/HEAD/lib/modules/datasource/unity3d-packages/readme.md","title":"unity3d-packages Documentation","category":"plugin-manifest","format":"markdown","content":"This datasource finds Unity package updates from Unity package feeds.\n\nBy default, Renovate checks `https://packages.unity.com` for Unity packages.\n\nYou can override the default behavior with the `registryUrls` config option.\nFor example:\n\n```json\n{\n  \"packageRules\": [\n    {\n      \"matchDatasources\": [\"unity3d-packages\"],\n      \"registryUrls\": [\"https://package.openupm.com\"]\n    }\n  ]\n}\n```\n","isInternal":false,"tokens":93,"sizeBytes":394},{"name":"readme.md","path":"lib/modules/versioning/unity3d-packages/readme.md","rawUrl":"https://raw.githubusercontent.com/renovatebot/renovate/HEAD/lib/modules/versioning/unity3d-packages/readme.md","title":"unity3d-packages Documentation","category":"plugin-manifest","format":"markdown","content":"Unity versioning follow [semantic versioning](https://docs.unity3d.com/Manual/upm-semver.html), followed optionally by `-exp.#` or `-pre.#`: <https://docs.unity3d.com/Manual/upm-lifecycle.html>\n\nExamples:\n\n- `0.1.2`\n- `1.2.3-exp.1`\n- `1.3.0-pre.1`\n- `1.4.0-preview.1`\n","isInternal":false,"tokens":97,"sizeBytes":268}],"systemPromptSnippet":"<yakaai_skills repo=\"renovatebot/renovate\">\n<!-- File: AGENTS.md (Tokens: ~1230 | Category: root-instruction) -->\n# AGENTS.md\n\nThis file provides guidance for AI agents working in this repository.\n\n## What is Renovate?\n\nRenovate is an automated dependency update tool that scans repositories for dependency files, checks for newer versions via datasources, and creates pull requests to update them. It supports 90+ package managers and multiple hosting platforms (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo, Gerrit, etc.).\n\n## Development Documentation\n\nThe **./docs/development/** directory contains detailed documentation for developers, like style guides, testing guidelines, and configuration options.\n\nALWAYS READ ./docs/development/best-practices.md for guidance on code style.\n\n## Architecture\n\nRenovate is an automated dependency update tool. The runtime flow is:\n\n```mermaid\nflowchart TD\n    entry[\"lib/renovate.ts\\nEntry Point\"]\n    global[\"Global Worker\\nOrchestration & Autodiscovery\"]\n    init[\"Init\\nClone repo, read config\"]\n    extract[\"Extract\\nScan dependency files\"]\n    lookup[\"Lookup\\nFetch versions & compare\"]\n    update[\"Update\\nWrite changes, create PRs\"]\n    finalize[\"Finalize\\nPrune branches, update cache\"]\n\n    platform([Platform])\n    manager([Manager])\n    datasource([Datasource])\n    versioning([Versioning])\n\n    entry --> global\n    global --> init\n    init --> extract\n    extract --> lookup\n    lookup --> update\n    update --> finalize\n\n    global -. \"autodiscover repos\" .-> platform\n    init -. \"clone, read config\" .-> platform\n    extract -. \"parse dep files\" .-> manager\n    lookup -. \"fetch releases\" .-> datasource\n    lookup -. \"compare versions\" .-> versioning\n    update -. \"update dep files\" .-> manager\n    update -. \"create/update PRs\" .-> platform\n    finalize -. \"prune branches\" .-> platform\n    finalize -- \"next repository\" --> init\n```\n\n### Module System (`lib/modules/`)\n\nFour module categories, each with many implementations:\n\n- **manager/** — Detects and updates dependency files (npm, maven, dockerfile, go-mod, cargo, etc.). Each manager extracts dependencies from specific file types and knows how to update them.\n- **datasource/** — Fetches version/release information from registries (npm registry, Docker Hub, GitHub releases, PyPI, etc.).\n- **versioning/** — Parses and compares version strings per ecosystem (semver, docker, maven, pep440, etc.).\n- **platform/** — Interacts with Git hosting APIs (GitHub, GitLab, Bitbucket, Azure DevOps, Gitea, Forgejo, Gerrit, etc.) for PRs, issues, and comments.\n\nEach module category has an `api.ts` barrel file at its root.\n\n### Other Key Directories\n\n- **lib/config/** — Configuration parsing, validation, defaults, preset resolution\n- **lib/util/** — Shared utilities (HTTP, git, caching, regex, template, etc.)\n- **lib/workers/global/** — Top-level orchestration, autodiscovery, config loading\n- **lib/workers/repository/** — Per-repository processing pipeline\n- **lib/constants/** — Shared constants\n- **tools/** — Build tooling, doc generation, schema generation, custom lint rules\n\n### Generated Files\n\nFiles matching `*.generated.ts` in `lib/` are auto-generated during build (`pnpm generate:*`). Do not edit these directly.\n\n## Raising issues/feature requests\n\n**Do not create GitHub Issues directly.** Issue creation is restricted to repository administrators. Creating an issue as a non-administrator will result in being blocked from the repository.\n\nInstead, use **GitHub Discussions**: https://github.com/renovatebot/renovate/discussions/new/choose\n\nTwo discussion categories are available:\n\n- **Request help** (`.github/DISCUSSION_TEMPLATE/request-help.yml`) - for bugs, questions, or unexpected behavior. Include a minimal reproduction and relevant logs where possible.\n- **Suggest an idea** (`.github/DISCUSSION_TEMPLATE/suggest-an-idea.yml`) - for feature requests or improvements.\n\n**Do not attempt** to create a Discussion body without following the template, as it may result in being blocked from the repository.\n\n**Security vulnerabilities must not be reported on GitHub.** See [`SECURITY.md`](./SECURITY.md) for more details.\n\n## Contributing Notes\n\n- PRs require 100% test coverage. Use `/* v8 ignore ... */` sparingly when tests wouldn't prove anything.\n- Do not force push PR branches.\n- Follow the PR template (`.github/pull_request_template.md`). Before running `gh pr create`, read that file in full and use its exact section structure for the PR body — do not substitute a generic Summary/Test plan format.\n- PRs should be raised as a draft PR, and only marked ready once the CLA has been signed, and the user has confirmed that the changes are ready to go\n\n### Commands\n\nUse `pnpm` for all commands (NOT npm/npx).\n\n- **Install dependencies:** `pnpm install`\n- **Lint / Type-check / Test / Autofix:** `pnpm check --all <paths>` for the changed files, `pnpm check --all` without a path for a full verification. It already runs lint, prettier, type-check and the tests of those files, so do not run `pnpm type-check`, `tsc`, a separate lint or extra `pnpm vitest` runs next to it.\n- **Run from source:** `pnpm start` or `node lib/renovate.ts`\n\nTests use Vitest (invoked via `pnpm vitest`). Test files use `.spec.ts` suffix and are co-located with source. Globals from `jest-extended` and `expect-more-jest` are available in tests.\n\n<!-- File: CLAUDE.md (Tokens: ~3 | Category: claude-rule) -->\nAGENTS.md\n\n<!-- File: tools/agents/hooks/readme.md (Tokens: ~494 | Category: subagent-persona) -->\n# Claude Code hooks\n\nThis directory contains hook scripts that Claude Code invokes automatically at key points in a session.\n\n## Hooks\n\n### `sessionstart-check.ts` — SessionStart\n\nRuns once on session startup, resume, clear, or compact.\n\nInstalls tools and dependencies so the session has a working environment:\n\n1. `mise install` — installs language runtimes declared in `.tool-versions` / `mise.toml`. Failure is non-fatal (logs a warning and continues) so the session works even without `mise`.\n2. `pnpm install` — installs Node dependencies. Failure is fatal and blocks the session.\n\n### `cwdchanged-check.ts` — CwdChanged\n\nRuns on every working-directory change, including `EnterWorktree`.\n\nInstall tools and dependencies in the new cwd, so the session has a working environment even when switching to a different worktree or subdirectory.\n\n### `pretooluse-check.ts` — PreToolUse\n\nRuns before every tool call.\n\nBlocks tool invocations that use forbidden package managers or test runners (e.g. `npm`, `yarn`, `npx`, `jest` directly) and requires `pnpm` / `vitest` instead.\n\n### `stop-check.ts` — Stop\n\nRuns when Claude Code is about to stop.\n\nExecutes `pnpm check --all` against all files changed since the base branch, including untracked files that are not ignored. If the check fails, the stop is blocked and Claude is prompted to fix the issues before finishing. The block reason includes the check output, cut down to its start and its end when it is long, so Claude sees which checks failed and why. The check only blocks a stop once: when `stop_hook_active` shows Claude is already continuing because this hook blocked it before, the stop is let through without checking again.\n\nThe check writes its coverage report to `.cache/stop-hook/coverage` (`pnpm check --coverage-dir`), so it does not clash with a manual `pnpm check` or `pnpm vitest` that uses the default `coverage` directory at the same time. After a passed check the hook stores a fingerprint of the base commit (the merge base with `origin/main`), the changed files and their contents, and the deleted files in `.cache/stop-hook/fingerprint`, and skips the check on later stops while that fingerprint is unchanged. A failed check stores no fingerprint.\n\n<!-- File: lib/modules/datasource/gitlab-packages/readme.md (Tokens: ~595 | Category: plugin-manifest) -->\n[GitLab Packages API](https://docs.gitlab.com/ee/api/packages.html) supports looking up package versions from [all types of packages registry supported by GitLab](https://docs.gitlab.com/ee/user/packages/package_registry/index.html) and can be used in combination with [regex managers](../../manager/regex/index.md) to keep dependencies up-to-date which are not specifically supported by Renovate.\n\nTo specify which specific repository should be queried when looking up a package, the `packageName` should be formed with the project path first, then a `:` and finally the package name.\n\nAs an example, `gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js` would look for the`@gitlab-org/nk-js` packages in the generic packages repository of the `gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list` project.\n\nTo specify where to find a self-hosted GitLab instance, specify `registryUrl`.\nAn example would be `https://gitlab.company.com`.\n\nIf you are using a self-hosted GitLab instance, please note the following requirements:\n\n- If you are on the `Free` edition, this datasource requires at least GitLab 13.3\n- If you are on the `Premium` or the `Ultimate` edition, this datasource requires at least GitLab 11.8, but GitLab 12.9 or more is recommended if you have a lot of packages with different names in the same project\n\n**Usage Example**\n\nA real-world example for this specific datasource would be maintaining package versions in a config file.\nThis can be achieved by configuring a custom manager in `renovate.json` for files named `versions.ini`:\n\n```json\n{\n  \"customManagers\": [\n    {\n      \"customType\": \"regex\",\n      \"managerFilePatterns\": [\"/^versions.ini$/\"],\n      \"matchStrings\": [\n        \"# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?( registryUrl=(?<registryUrl>.*?))?\\\\s.*?_VERSION=(?<currentValue>.*)\\\\s\"\n      ],\n      \"versioningTemplate\": \"{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}\"\n    }\n  ]\n}\n```\n\nNow you may use comments in your `versions.ini` files to automatically update dependencies, which could look like this:\n\n```ini\n# renovate: datasource=gitlab-packages depName=gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js versioning=semver registryUrl=https://gitlab.com\nNKJS_VERSION=3.4.0\n\n```\n\nBy default, `gitlab-packages` uses the `docker` versioning scheme.\n\n<!-- File: lib/modules/datasource/jenkins-plugins/readme.md (Tokens: ~130 | Category: plugin-manifest) -->\nThe `jenkins-plugins` datasource supports lookups from the [Jenkins Update Center](https://updates.jenkins.io/) or custom registries.\n\nWhen you define a custom registry with the `registryUrl` config option, you must follow [Jenkins' update site layout](https://github.com/jenkins-infra/update-center2/blob/master/site/LAYOUT.md).\n\nThe `update-center.actual.json` and `plugin-versions.json` files must be in the `current` path, so Renovate can find them.\nFor example, the files could be put in the `https://custom.registry.renovatebot.com/current` directory.\n\n<!-- File: lib/modules/datasource/unity3d-packages/readme.md (Tokens: ~93 | Category: plugin-manifest) -->\nThis datasource finds Unity package updates from Unity package feeds.\n\nBy default, Renovate checks `https://packages.unity.com` for Unity packages.\n\nYou can override the default behavior with the `registryUrls` config option.\nFor example:\n\n```json\n{\n  \"packageRules\": [\n    {\n      \"matchDatasources\": [\"unity3d-packages\"],\n      \"registryUrls\": [\"https://package.openupm.com\"]\n    }\n  ]\n}\n```\n\n<!-- File: lib/modules/versioning/unity3d-packages/readme.md (Tokens: ~97 | Category: plugin-manifest) -->\nUnity versioning follow [semantic versioning](https://docs.unity3d.com/Manual/upm-semver.html), followed optionally by `-exp.#` or `-pre.#`: <https://docs.unity3d.com/Manual/upm-lifecycle.html>\n\nExamples:\n\n- `0.1.2`\n- `1.2.3-exp.1`\n- `1.3.0-pre.1`\n- `1.4.0-preview.1`\n</yakaai_skills>"}