一键导入
using-trusted-maven-dependencies
Use when updating a Maven project to source its dependencies from a trusted Maven repository instead of Maven Central.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
菜单
Use when updating a Maven project to source its dependencies from a trusted Maven repository instead of Maven Central.
用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Use when needing to understand Konflux architecture, design decisions, service responsibilities, APIs, build/test/release workflows, or how Konflux components fit together.
Use when needing to know which Red Hat team owns a Konflux-related repository (konflux-ci, hermetoproject, conforma orgs), which JIRA project or component to file issues against, or how the Red Hat Konflux engineering organization maps to the codebase.
Use to trigger component builds, releases or get a component or application status
Use when tracing Konflux builds from image references, finding build logs from artifacts, or verifying source commits for container images - extracts provenance attestations to navigate from images back to builds and source code
Use when GitHub PR or branch has failing checks and you need to find Konflux pipeline information (cluster, namespace, PipelineRun name). Teaches gh CLI commands to identify Konflux checks (filter out Prow/SonarCloud), extract PipelineRun URLs from builds and integration tests, and parse URLs for kubectl debugging.
Use when Konflux pipelines fail, are stuck, timeout, or show errors like ImagePullBackOff. Covers PipelineRun failures, TaskRun issues (Pending, Failed, stuck Running), build errors, and systematic debugging of Tekton pipeline problems using kubectl and logs.
| name | using-trusted-maven-dependencies |
| description | Use when updating a Maven project to source its dependencies from a trusted Maven repository instead of Maven Central. |
| allowed-tools | Bash(grep*), Read(/tmp/use-trusted-maven-dependencies/**), Bash(mkdir -p /tmp/use-trusted-maven-dependencies*), Bash(rm /tmp/use-trusted-maven-dependencies/*), Bash(mvn help:effective-pom*), WebFetch |
Update a Maven project to use dependencies from a trusted Maven repository. These repositories may publish rebuilds of publicly available dependencies in a secured environment, and may include security patches absent from public repositories like Maven Central.
This skill will add the provided Maven repository as a source for code dependencies as well as Maven plugins. This ensures your Maven build maximizes the security of its entire supply chain.
The following information will be provided by the user, and should be retained by the agent while it is executing this skill:
repository.idrepository.urlrebuild.suffixThe following XML blocks are referenced throughout this skill. Items in ${} blocks are input
variables that will be provided by the user:
<!-- In <repositories> -->
<repository>
<id>${repository.id}</id>
<url>${repository.url}</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
<!-- In <pluginRepositories> -->
<pluginRepository>
<id>${repository.id}</id>
<url>${repository.url}</url>
<releases>
<enabled>true</enabled>
</releases>
<snapshots>
<enabled>false</enabled>
</snapshots>
</pluginRepository>
Follow these steps in order. Do not skip steps.
Ask the user to provide the following information:
repository.id): This is an identifier for the Maven repository, which should be a single kebab-case ID with alphanumeric characters.repository.url): This is a valid HTTP URL to the root of the Maven repository. This url SHOULD use HTTPS.rebuild.suffix): This is a suffix applied to rebuilt dependency versions. This can be a regular expression.Print "Checking if the trusted repository is enabled..."
Run:
mkdir -p /tmp/use-trusted-maven-dependencies
mvn help:effective-pom -Doutput=/tmp/use-trusted-maven-dependencies/effective-pom.xml -q
Inspect /tmp/use-trusted-maven-dependencies/effective-pom.xml:
<repositories> contains an entry with <id>${repository.id}</id>, print "${repository.id} repository enabled."<pluginRepositories> contains an entry with <id>${repository.id}</id>, print "${repository.id} plugin repository enabled."Delete /tmp/use-trusted-maven-dependencies/effective-pom.xml.
If both are present, skip to step 3. Otherwise proceed to step 2.
pom.xmlPrint "Adding repository ${repository.id} to project pom.xml"
Find the project root pom.xml (ignore files under src/ or target/). Add the <repository> block from the template above to <repositories>, and the <pluginRepository> block to <pluginRepositories>, creating each element if absent. Be sure to replace the input variables with values provided by the user.
Validate the modified pom.xml for well-formed XML and fix any syntax errors.
Scan all project pom.xml files (excluding those under src/ or target/) for versions declared in:
<dependency> elements (both inside <dependencyManagement> and standalone <dependencies>)<plugin> elements (including nested <dependency> elements within plugins)For each artifact, use WebFetch to check the trusted repository for a rebuild. Fetch the
maven-metadata.xml at:
${repository.url}<groupId/as/path>/<artifactId>/maven-metadata.xml
Rebuilds share the same groupId, artifactId, and base <version>. Trusted rebuilds will have a
suffix appended to the version that matches the ${rebuild.suffix} regular expression. The suffix
is separated from the base version by a hyphen (-), period (.), or plus sign (+). For example,
given base version 1.4.2 and suffix pattern rebuild-[\d]+, any of these are valid rebuild versions:
1.4.2-rebuild-00011.4.2.rebuild-00011.4.2+rebuild-0001If multiple rebuilds exist, select the highest version as reported in the repository's maven-metadata.xml file.
Version properties: If a version is set via a Maven property, update the property value in
<properties> rather than the <version> element. For example:
<!-- Before -->
<my.lib.version>1.2.3</my.lib.version>
<!-- After -->
<my.lib.version>1.2.3-redhat-00001</my.lib.version>
When replacing versions, you MUST ensure that the replaced version has an equivalent base version. DO NOT
upgrade or downgrade the base version during this process. For SemVer artifacts this means MAJOR.MINOR.PATCH
must match exactly. For non-SemVer artifacts (e.g., 31.1-jre), the entire base version string before the
rebuild suffix must match.
Allowed replacement
Using rebuild.suffix = myorg-[\d]*
<!-- Before -->
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.8.2</version>
<!-- After -->
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.8.2.myorg-00002</version>
Not allowed replacement (downgrade)
Using rebuild.suffix = myorg-[\d]*
<!-- Before -->
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.9.3</version>
<!-- After -->
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.8.2.myorg-00002</version>
Not allowed replacement (upgrade)
Using rebuild.suffix = myorg-[\d]*
<!-- Before -->
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.8.1</version>
<!-- After -->
<groupId>org.junit.jupiter</groupId>
<artifactId>junit-jupiter-api</artifactId>
<version>5.8.2.myorg-00002</version>
For each replaced version, print:
Replaced <groupId>:<artifactId>:<version> with trusted version <trustedVersion>
Maven, pom.xml, trusted repository, Maven Central, dependency management, pluginRepositories, security patches, artifact rebuilds, supply chain security, version replacement, effective POM, maven-metadata.xml, rebuild suffix, semver, Konflux, Java, build dependencies