[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6HPRWEXNWHQRQVSASZ9GZJ7":3,"skill-same:01M6HPRWEXNWHQRQVSASZ9GZJ7":71},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":37,"linkOnly":38,"markdownContent":39,"markdownBody":40,"frontMatter":41,"refName":43,"commitSha":44,"skillDirectory":45,"forksCount":46,"repositoryHtmlUrl":47,"repositoryHomepageUrl":48,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":6,"updatedAt":51,"install":52,"resources":64},"01M6HPRWEXNWHQRQVSASZ9GZJ7","triage-dependabot-prs",null,"Triage open Dependabot PRs on apache\u002Ftomee - close, file TOMEE Jira issues, squash merge. Use when the user asks about dependabot or dependency bump PRs.","apache\u002Ftomee","apache","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F47359?v=4","01M6AC83E6K4FDKK7HZ8WNMQKE","The Apache Software Foundation","01M6HPRS4MN11036NBDQ97S6QV",480,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fapache\u002Ftomee\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftriage-dependabot-prs\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,9,34,35,36],"triage dependabot prs","dependabot","triage","user","true","about","jira issues","close","dependency bump","bump","dependency","use","squash","open","file","issues","jira","merge","2026-11-10 10:12:30",false,"---\nname: triage-dependabot-prs\ndisable-model-invocation: true\ndescription: Triage open Dependabot PRs on apache\u002Ftomee - close, file TOMEE Jira issues, squash merge. Use when the user asks about dependabot or dependency bump PRs.\n---\n\n# TomEE Dependabot\n\nRun the phases in order. Phases 2 and 3 end at a **gate**: show the user the result and wait for an explicit go-ahead. All writes to GitHub or Jira (close, rename, merge, create, edit, transition) happen in phase 4.\n\nRun from a TomEE checkout. `origin` means the remote for `apache\u002Ftomee` (substitute its name if it differs); fetch it first. Pass `-R apache\u002Ftomee` to every `gh` call.\n\n## Jira access\n\n**Reads** use the public REST API, no login needed:\n\n```sh\ncurl -s https:\u002F\u002Fissues.apache.org\u002Fjira\u002Frest\u002Fapi\u002F2\u002Fproject\u002FTOMEE\u002Fversions\ncurl -s -G https:\u002F\u002Fissues.apache.org\u002Fjira\u002Frest\u002Fapi\u002F2\u002Fsearch \\\n  --data-urlencode 'jql=project = TOMEE AND summary ~ \"Tomcat\" ORDER BY created DESC' \\\n  --data-urlencode 'fields=summary,issuetype,fixVersions,status' --data-urlencode maxResults=20\n```\n\n**Writes** go through a Jira MCP server (checked in phase 1). The user picks its name, so find it by its tools (issue create, edit, transition, current-user profile), not by server or tool name. If none is configured, offer to help set up [mcp-atlassian](https:\u002F\u002Fgithub.com\u002Fsooperset\u002Fmcp-atlassian) against ASF Jira (`https:\u002F\u002Fissues.apache.org\u002Fjira`, Server\u002FData Center), following its current docs. The user enters credentials into their config themselves, never into the chat. Without a working server, phase 4 does the GitHub side and lists the Jira writes for the user to do by hand.\n\n## Jakarta EE line guardrail\n\nEach branch ships one Jakarta EE version, and each EE implementation has a release line bound to it. A bump onto another line compiles and passes CI but ships a component built for the wrong spec. **Merge only bumps that stay on the branch's line**; close the rest with a comment naming the line, whatever CI says.\n\nThe project version in `git show origin\u002F\u003Cbranch>:pom.xml` gives the EE version (TomEE 11 = EE 11, TomEE 10 = EE 10). Lines as of TomEE 11.0.0 \u002F 10.3.0:\n\n| Component | TomEE 11 (main) | TomEE 10 (tomee-10.x) |\n|---|---|---|\n| Tomcat | 11.0.x | 10.1.x |\n| MyFaces | 4.1.x | 4.0.x |\n| Mojarra (`org.glassfish:jakarta.faces`) | 4.1.x | 4.0.x |\n| ActiveMQ | 6.3.x | 6.3.x |\n\nActiveMQ is not bound to the EE version: 6.2 and 6.3 both build against Jakarta Messaging 3.1 on Java 17, and the modules TomEE ships (broker, client, jdbc-store, openwire-legacy, ra) need only `jakarta.jms-api`, `jakarta.annotation-api` and `jakarta.resource-api`, which TomEE provides at its own EE level. 6.3's EE 11 dependencies come only from the web console and HTTP transport, which TomEE does not ship. tomee-10.x is on 6.3 because CVE-2026-74761 has no 6.2.x fix (TOMEE-4721). For a new ActiveMQ minor on either branch, compare `jakarta-jms-api-version` and `javaVersion` in the new `activemq-parent` pom, and the non-test dependencies of those five modules, with the branch's platform.\n\nFor a component not in the table, read its spec version off its release notes or project page (Tomcat: https:\u002F\u002Ftomcat.apache.org\u002Fwhichversion.html) and compare it with what the branch's platform lists.\n\nThe ignore list in `.github\u002Fdependabot.yml` on `main` (it configures both branches) covers these groups, but is only a first filter; the guardrail is the check.\n\n**CXF-aligned libraries** (santuario, woodstox, opensaml): close; the CXF upgrade brings them. **Spec APIs and MicroProfile implementations** get a spec review.\n\n### Spec review\n\nVerdict per PR: **same spec** (handle like any other PR) or **spec moves** (close; the comment names old and new spec version).\n\n**Jakarta spec APIs** (`jakarta.*:*`): the major of `version.jakartaee-api` in the branch's root `pom.xml` is the EE version. Look up the component spec version that platform lists at `https:\u002F\u002Fjakarta.ee\u002Fspecifications\u002Fplatform\u002F\u003CN>\u002F` (the `jakarta-ee-spec-reader` skill does this). Same spec only for a service release of that spec version (`jakarta.faces-api` 4.1.2 → 4.1.3 on EE 11); a different major or minor is a spec move.\n\n**MicroProfile spec APIs** (`org.eclipse.microprofile*`): the root `pom.xml` pins each spec in `version.microprofile.\u003Cspec>`. Same spec only for a patch of that exact version (`4.0.1` → `4.0.2`).\n\n**MicroProfile implementations** (`io.smallrye*`, micrometer, opentelemetry, opentracing), pinned in `version.microprofile.impl.\u003Cspec>`:\n\n1. Read the branch's spec version, `version.microprofile.\u003Cspec>` on `origin\u002F\u003Cbranch>`.\n2. Read the spec version the *new* implementation targets from its parent pom on Maven Central (`io\u002Fsmallrye\u002F\u003Cproject>\u002Fsmallrye-\u003Cproject>-parent`):\n\n   ```sh\n   curl -s https:\u002F\u002Frepo.maven.apache.org\u002Fmaven2\u002Fio\u002Fsmallrye\u002Fconfig\u002Fsmallrye-config-parent\u002F$V\u002Fsmallrye-config-parent-$V.pom \\\n     | grep -iE 'microprofile[^\u003C]*>[0-9]'\n   ```\n\n   If the parent has no such property, use the `org.eclipse.microprofile.*` dependency version in the implementation's own pom.\n3. Equal major.minor is same spec, anything else a spec move. SmallRye OpenTelemetry 2.7.0 → 2.15.1 moves MP Telemetry 1.1 → 2.1 (spec move on a branch pinned to 1.1); SmallRye Config 3.18.2 → 4.0.0 stays on MP Config 3.1 (same spec).\n4. For a new implementation major, check the Java baseline (`maven.compiler.release` in the root `pom.xml`). Byte 8 of a class file is 61 for Java 17, 65 for Java 21; above the baseline is a spec move.\n\n   ```sh\n   curl -s -o impl.jar \u003Cjar url> && unzip -p impl.jar \u003Csome .class> | head -c 8 | od -An -tu1\n   ```\n\nA same-spec new major can still break TomEE's integration code, which CI only compiles: list it at the gate as a merge candidate flagged with the new major, for the user to decide.\n\n## 1. Collect\n\n```sh\ngh pr list -R apache\u002Ftomee --author app\u002Fdependabot --state open --limit 200 \\\n  --json number,baseRefName,title,files,statusCheckRollup\n```\n\nFrom the versions endpoint, take each branch's unreleased fix version: `released: false` and matching the branch's project version (e.g. `11.0.0` for main, `10.3.0` for tomee-10.x; not `JakartaEE API 11.0.0`).\n\nLook for a Jira MCP server among the available tools and call its current-user profile tool to confirm a login to `issues.apache.org`; if missing, offer the setup above now so it doesn't block phase 4.\n\nDone when every open PR has its branch, changed files and CI state, each branch has its fix version, and Jira write access is known.\n\n## 2. Classify\n\nPut every PR in exactly one class:\n\n- **Build**: Maven plugins, plugin tooling such as `maven-plugin-annotations`, the `org.apache:apache` parent pom.\n- **Shipped**: the artifact appears in a BOM of that branch, so it lands in a distribution.\n- **Misc**: everything else (test-only libraries, TCK modules, examples, `utils\u002F` integrations).\n\n```sh\ngit grep -c \"\u003CartifactId>$ARTIFACT\u003C\u002FartifactId>\" origin\u002F$BRANCH -- 'boms\u002F*\u002Fpom.xml'\n```\n\nFor a PR that bumps a version *property* (`version.activemq`, `tomcat.version`), trace the property to its artifacts in the root `pom.xml` first.\n\nFlag on top of the class:\n\n- guardrail breaks, and the spec review verdict for every spec API and MicroProfile implementation PR;\n- pre-releases and new majors (`-beta`, `-M`, `-rc`, `X.0.0`), with their prerequisites checked (the core Maven plugins' 4.x line needs Maven 4; the build runs Maven 3, so it fails the first `install`);\n- a pom comment pinning the old version on purpose (e.g. the rest-client TCK pins old Jetty);\n- a failing check: read `gh run view \u003Cid> --log-failed -R apache\u002Ftomee` and report the actual error.\n\nCI runs `clean install -DskipTests -Pstyle,rat`: green means it compiles and passes style and license checks, not tests or TCKs. Say so when a bump's risk is runtime behaviour.\n\n**Gate:** tables per class (PR, branch, change, flags).\n\n## 3. Plan Jira\n\nOnly shipped dependencies with precedent get an issue: search for earlier issues on each (`project = TOMEE AND summary ~ \"\u003Cname>\" ORDER BY created DESC`). A dependency with past `Dependency upgrade` issues gets one; build and misc PRs never do, even with a stray precedent (Hibernate has one by accident).\n\nOne issue per dependency and target version: when both branches bump to the same version, one issue carries both fix versions. Look for an issue on the dependency in the branch's unreleased fix version:\n\n- **Exists**: retitle it to the new version (add the other branch's fix version if needed); leave its assignee alone.\n- **None**: create one. Type `Dependency upgrade`, summary `\u003CName> \u003Cversion>` (e.g. `Tomcat 11.0.26`, `Apache ActiveMQ 6.2.10`, `MyFaces 4.0.4`), the unreleased fix version of each branch it covers, assigned to the user running the skill (from the MCP profile lookup in phase 1, or ask).\n\n**Gate:** every PR with its disposition: close (with reason), merge with issue (retitled or new, with the planned summary), or merge without issue.\n\n## 4. Execute\n\nEvery comment and issue body carries the agent disclosure from `AGENTS.md`.\n\n1. Close: `gh pr close \u003CPR> -R apache\u002Ftomee --comment \"\u003Creason: error, pinned version, or EE line>\"`. Closing is the whole response; ignore-list changes are a separate decision for the user.\n2. For each PR with an issue, in order:\n   1. Create or retitle the issue (MCP).\n   2. `gh pr edit \u003CPR> -R apache\u002Ftomee --title \"TOMEE-XXXX - \u003CDependabot title>\"`\n   3. `gh pr merge \u003CPR> -R apache\u002Ftomee --squash --subject \"TOMEE-XXXX - \u003CDependabot title> (#PR)\"`\n   4. Transition the issue to Resolved, resolution Fixed, unless it already is (MCP). Closed happens at release.\n3. PRs without an issue: `gh pr merge \u003CPR> -R apache\u002Ftomee --squash` (subject: Dependabot's title).\n\nEach merge can make Dependabot rebase other PRs on that branch. Before every merge, confirm the PR is still mergeable with passing checks (`gh pr view \u003CPR> -R apache\u002Ftomee --json mergeable,statusCheckRollup`); skip and report any that is not.\n\nDone when every planned PR is closed or merged and every issue is Resolved. Report the result per PR, including anything skipped and why.\n","# TomEE Dependabot\n\nRun the phases in order. Phases 2 and 3 end at a **gate**: show the user the result and wait for an explicit go-ahead. All writes to GitHub or Jira (close, rename, merge, create, edit, transition) happen in phase 4.\n\nRun from a TomEE checkout. `origin` means the remote for `apache\u002Ftomee` (substitute its name if it differs); fetch it first. Pass `-R apache\u002Ftomee` to every `gh` call.\n\n## Jira access\n\n**Reads** use the public REST API, no login needed:\n\n```sh\ncurl -s https:\u002F\u002Fissues.apache.org\u002Fjira\u002Frest\u002Fapi\u002F2\u002Fproject\u002FTOMEE\u002Fversions\ncurl -s -G https:\u002F\u002Fissues.apache.org\u002Fjira\u002Frest\u002Fapi\u002F2\u002Fsearch \\\n  --data-urlencode 'jql=project = TOMEE AND summary ~ \"Tomcat\" ORDER BY created DESC' \\\n  --data-urlencode 'fields=summary,issuetype,fixVersions,status' --data-urlencode maxResults=20\n```\n\n**Writes** go through a Jira MCP server (checked in phase 1). The user picks its name, so find it by its tools (issue create, edit, transition, current-user profile), not by server or tool name. If none is configured, offer to help set up [mcp-atlassian](https:\u002F\u002Fgithub.com\u002Fsooperset\u002Fmcp-atlassian) against ASF Jira (`https:\u002F\u002Fissues.apache.org\u002Fjira`, Server\u002FData Center), following its current docs. The user enters credentials into their config themselves, never into the chat. Without a working server, phase 4 does the GitHub side and lists the Jira writes for the user to do by hand.\n\n## Jakarta EE line guardrail\n\nEach branch ships one Jakarta EE version, and each EE implementation has a release line bound to it. A bump onto another line compiles and passes CI but ships a component built for the wrong spec. **Merge only bumps that stay on the branch's line**; close the rest with a comment naming the line, whatever CI says.\n\nThe project version in `git show origin\u002F\u003Cbranch>:pom.xml` gives the EE version (TomEE 11 = EE 11, TomEE 10 = EE 10). Lines as of TomEE 11.0.0 \u002F 10.3.0:\n\n| Component | TomEE 11 (main) | TomEE 10 (tomee-10.x) |\n|---|---|---|\n| Tomcat | 11.0.x | 10.1.x |\n| MyFaces | 4.1.x | 4.0.x |\n| Mojarra (`org.glassfish:jakarta.faces`) | 4.1.x | 4.0.x |\n| ActiveMQ | 6.3.x | 6.3.x |\n\nActiveMQ is not bound to the EE version: 6.2 and 6.3 both build against Jakarta Messaging 3.1 on Java 17, and the modules TomEE ships (broker, client, jdbc-store, openwire-legacy, ra) need only `jakarta.jms-api`, `jakarta.annotation-api` and `jakarta.resource-api`, which TomEE provides at its own EE level. 6.3's EE 11 dependencies come only from the web console and HTTP transport, which TomEE does not ship. tomee-10.x is on 6.3 because CVE-2026-74761 has no 6.2.x fix (TOMEE-4721). For a new ActiveMQ minor on either branch, compare `jakarta-jms-api-version` and `javaVersion` in the new `activemq-parent` pom, and the non-test dependencies of those five modules, with the branch's platform.\n\nFor a component not in the table, read its spec version off its release notes or project page (Tomcat: https:\u002F\u002Ftomcat.apache.org\u002Fwhichversion.html) and compare it with what the branch's platform lists.\n\nThe ignore list in `.github\u002Fdependabot.yml` on `main` (it configures both branches) covers these groups, but is only a first filter; the guardrail is the check.\n\n**CXF-aligned libraries** (santuario, woodstox, opensaml): close; the CXF upgrade brings them. **Spec APIs and MicroProfile implementations** get a spec review.\n\n### Spec review\n\nVerdict per PR: **same spec** (handle like any other PR) or **spec moves** (close; the comment names old and new spec version).\n\n**Jakarta spec APIs** (`jakarta.*:*`): the major of `version.jakartaee-api` in the branch's root `pom.xml` is the EE version. Look up the component spec version that platform lists at `https:\u002F\u002Fjakarta.ee\u002Fspecifications\u002Fplatform\u002F\u003CN>\u002F` (the `jakarta-ee-spec-reader` skill does this). Same spec only for a service release of that spec version (`jakarta.faces-api` 4.1.2 → 4.1.3 on EE 11); a different major or minor is a spec move.\n\n**MicroProfile spec APIs** (`org.eclipse.microprofile*`): the root `pom.xml` pins each spec in `version.microprofile.\u003Cspec>`. Same spec only for a patch of that exact version (`4.0.1` → `4.0.2`).\n\n**MicroProfile implementations** (`io.smallrye*`, micrometer, opentelemetry, opentracing), pinned in `version.microprofile.impl.\u003Cspec>`:\n\n1. Read the branch's spec version, `version.microprofile.\u003Cspec>` on `origin\u002F\u003Cbranch>`.\n2. Read the spec version the *new* implementation targets from its parent pom on Maven Central (`io\u002Fsmallrye\u002F\u003Cproject>\u002Fsmallrye-\u003Cproject>-parent`):\n\n   ```sh\n   curl -s https:\u002F\u002Frepo.maven.apache.org\u002Fmaven2\u002Fio\u002Fsmallrye\u002Fconfig\u002Fsmallrye-config-parent\u002F$V\u002Fsmallrye-config-parent-$V.pom \\\n     | grep -iE 'microprofile[^\u003C]*>[0-9]'\n   ```\n\n   If the parent has no such property, use the `org.eclipse.microprofile.*` dependency version in the implementation's own pom.\n3. Equal major.minor is same spec, anything else a spec move. SmallRye OpenTelemetry 2.7.0 → 2.15.1 moves MP Telemetry 1.1 → 2.1 (spec move on a branch pinned to 1.1); SmallRye Config 3.18.2 → 4.0.0 stays on MP Config 3.1 (same spec).\n4. For a new implementation major, check the Java baseline (`maven.compiler.release` in the root `pom.xml`). Byte 8 of a class file is 61 for Java 17, 65 for Java 21; above the baseline is a spec move.\n\n   ```sh\n   curl -s -o impl.jar \u003Cjar url> && unzip -p impl.jar \u003Csome .class> | head -c 8 | od -An -tu1\n   ```\n\nA same-spec new major can still break TomEE's integration code, which CI only compiles: list it at the gate as a merge candidate flagged with the new major, for the user to decide.\n\n## 1. Collect\n\n```sh\ngh pr list -R apache\u002Ftomee --author app\u002Fdependabot --state open --limit 200 \\\n  --json number,baseRefName,title,files,statusCheckRollup\n```\n\nFrom the versions endpoint, take each branch's unreleased fix version: `released: false` and matching the branch's project version (e.g. `11.0.0` for main, `10.3.0` for tomee-10.x; not `JakartaEE API 11.0.0`).\n\nLook for a Jira MCP server among the available tools and call its current-user profile tool to confirm a login to `issues.apache.org`; if missing, offer the setup above now so it doesn't block phase 4.\n\nDone when every open PR has its branch, changed files and CI state, each branch has its fix version, and Jira write access is known.\n\n## 2. Classify\n\nPut every PR in exactly one class:\n\n- **Build**: Maven plugins, plugin tooling such as `maven-plugin-annotations`, the `org.apache:apache` parent pom.\n- **Shipped**: the artifact appears in a BOM of that branch, so it lands in a distribution.\n- **Misc**: everything else (test-only libraries, TCK modules, examples, `utils\u002F` integrations).\n\n```sh\ngit grep -c \"\u003CartifactId>$ARTIFACT\u003C\u002FartifactId>\" origin\u002F$BRANCH -- 'boms\u002F*\u002Fpom.xml'\n```\n\nFor a PR that bumps a version *property* (`version.activemq`, `tomcat.version`), trace the property to its artifacts in the root `pom.xml` first.\n\nFlag on top of the class:\n\n- guardrail breaks, and the spec review verdict for every spec API and MicroProfile implementation PR;\n- pre-releases and new majors (`-beta`, `-M`, `-rc`, `X.0.0`), with their prerequisites checked (the core Maven plugins' 4.x line needs Maven 4; the build runs Maven 3, so it fails the first `install`);\n- a pom comment pinning the old version on purpose (e.g. the rest-client TCK pins old Jetty);\n- a failing check: read `gh run view \u003Cid> --log-failed -R apache\u002Ftomee` and report the actual error.\n\nCI runs `clean install -DskipTests -Pstyle,rat`: green means it compiles and passes style and license checks, not tests or TCKs. Say so when a bump's risk is runtime behaviour.\n\n**Gate:** tables per class (PR, branch, change, flags).\n\n## 3. Plan Jira\n\nOnly shipped dependencies with precedent get an issue: search for earlier issues on each (`project = TOMEE AND summary ~ \"\u003Cname>\" ORDER BY created DESC`). A dependency with past `Dependency upgrade` issues gets one; build and misc PRs never do, even with a stray precedent (Hibernate has one by accident).\n\nOne issue per dependency and target version: when both branches bump to the same version, one issue carries both fix versions. Look for an issue on the dependency in the branch's unreleased fix version:\n\n- **Exists**: retitle it to the new version (add the other branch's fix version if needed); leave its assignee alone.\n- **None**: create one. Type `Dependency upgrade`, summary `\u003CName> \u003Cversion>` (e.g. `Tomcat 11.0.26`, `Apache ActiveMQ 6.2.10`, `MyFaces 4.0.4`), the unreleased fix version of each branch it covers, assigned to the user running the skill (from the MCP profile lookup in phase 1, or ask).\n\n**Gate:** every PR with its disposition: close (with reason), merge with issue (retitled or new, with the planned summary), or merge without issue.\n\n## 4. Execute\n\nEvery comment and issue body carries the agent disclosure from `AGENTS.md`.\n\n1. Close: `gh pr close \u003CPR> -R apache\u002Ftomee --comment \"\u003Creason: error, pinned version, or EE line>\"`. Closing is the whole response; ignore-list changes are a separate decision for the user.\n2. For each PR with an issue, in order:\n   1. Create or retitle the issue (MCP).\n   2. `gh pr edit \u003CPR> -R apache\u002Ftomee --title \"TOMEE-XXXX - \u003CDependabot title>\"`\n   3. `gh pr merge \u003CPR> -R apache\u002Ftomee --squash --subject \"TOMEE-XXXX - \u003CDependabot title> (#PR)\"`\n   4. Transition the issue to Resolved, resolution Fixed, unless it already is (MCP). Closed happens at release.\n3. PRs without an issue: `gh pr merge \u003CPR> -R apache\u002Ftomee --squash` (subject: Dependabot's title).\n\nEach merge can make Dependabot rebase other PRs on that branch. Before every merge, confirm the PR is still mergeable with passing checks (`gh pr view \u003CPR> -R apache\u002Ftomee --json mergeable,statusCheckRollup`); skip and report any that is not.\n\nDone when every planned PR is closed or merged and every issue is Resolved. Report the result per PR, including anything skipped and why.\n",{"name":5,"description":7,"disable-model-invocation":42},true,"main","86f2cc160b58c38bbffa6b638599ce0d027d6d35",".agents\u002Fskills\u002Ftriage-dependabot-prs",696,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftomee","https:\u002F\u002Ftomee.apache.org\u002F","https:\u002F\u002Fgithub.com\u002Fapache","https:\u002F\u002Fwww.apache.org\u002F","2026-11-10 22:01:22",{"source":8,"skillName":5,"commands":53,"prompt":63,"zipAvailable":42},[54,57,60],{"tool":55,"command":56},"npx","npx skills add apache\u002Ftomee --skill triage-dependabot-prs",{"tool":58,"command":59},"bunx","bunx skills add apache\u002Ftomee --skill triage-dependabot-prs",{"tool":61,"command":62},"pnpm","pnpm dlx skills add apache\u002Ftomee --skill triage-dependabot-prs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fapache\u002Ftomee\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftriage-dependabot-prs\u002FSKILL.md",[65],{"path":66,"resourceType":67,"resourceTypeDesc":68,"sizeBytes":69,"sourceHtmlUrl":70},"agents\u002Fopenai.yaml","REFERENCE","参考文档",43,"https:\u002F\u002Fgithub.com\u002Fapache\u002Ftomee\u002Fblob\u002Fmain\u002F.agents\u002Fskills\u002Ftriage-dependabot-prs\u002Fagents\u002Fopenai.yaml",[]]