用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/XRPLF/xrpl-py --skill batch-deps-upgrade命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
基于 SOC 职业分类
正在显示 SKILL.md
| name | batch-deps-upgrade |
| description | Batch all open Dependabot dependency upgrade PRs into a single PR |
| disable-model-invocation | true |
Batch all open Dependabot dependency upgrade PRs into a single PR for this repository.
Run: gh pr list --repo XRPLF/xrpl-py --label dependencies --state open --limit 500 --json number,title,headRefName,body,url
Parse each PR to extract package names and versions. Dependabot PRs come in two formats:
bump <pkg> from <old> to <new> — parse from titlebump <pkg1> and <pkg2> with no versions — parse from PR body, which contains a structured list of package updates with version rangesIf any PR can't be parsed from either title or body, flag it for manual review. Build a table of all proposed upgrades. Report the table to the user before proceeding.
deps/batch-deps-upgrade-YYYY-QN (use current year and quarter)pyproject.toml constraints and run poetry show <pkg> to check if any other dependency pins a version range that would block the upgrade. Mark conflicts as Skipped (dependency conflict: pyproject.toml under [tool.poetry.dependencies] or [tool.poetry.group.dev.dependencies]): update the version constraint in pyproject.toml to the new version using caret (^<new_version>), then run poetry update <pkg>. Always update pyproject.toml for direct deps — even if the current constraint already allows the new version — so the pinned minimum stays current.pyproject.toml): run poetry update <pkg> to update within the existing constraint rangepoetry lock to regenerate poetry.lock. Do NOT delete poetry.lock and regenerate from scratch.poetry install to sync the virtual environment.pyproject.toml and poetry.lock against main to classify each Dependabot PR as:
## [Unreleased] in CHANGELOG.md.Run the full validation suite across all Python versions from the CI matrix. Repeat until everything passes.
Read each workflow file under .github/workflows/ to determine the Python versions used:
.github/workflows/unit_test.yml — the unit-test job uses a matrix of Python versions; the lint-and-type-check job uses a single Python version (not a matrix).github/workflows/integration_test.yml — the integration-test job uses a matrix of Python versions.github/workflows/faucet_test.yml — the faucet-test job uses a matrix of Python versionsExtract the exact Python versions from each workflow's matrix.python-version array (or the PYTHON_VERSION env var for lint). These versions are the source of truth for validation.
To switch Python versions for testing, use pyenv and poetry:
pyenv install <version> # install if not already present
pyenv local <version> # set the local Python version
poetry env use python<version> # point poetry to the correct interpreter
poetry install # reinstall deps for this interpreter
Replace <version> with the target version (e.g. 3.10, 3.11, 3.12, 3.13, 3.14). After running all tests for one version, repeat these steps to switch to the next.
Run validation in parallel across all Python versions from the unit test matrix to speed things up. For each Python version, create a separate working directory (e.g. using git worktree or by spawning parallel agents) so that each version's virtual environment does not interfere with the others.
For each Python version, run the following in order:
Lint and type-check (only on the single lint Python version from the lint-and-type-check job):
poetry run poe lint
poetry run mypy --strict --implicit-reexport xrpl
Unit tests:
poetry run poe test_unit
poetry run coverage report --fail-under=85
Integration tests (requires a single shared xrpld Docker container — start it once before running integration tests for any Python version):
docker rm -f xrpld-service 2>/dev/null || truedocker run \
--detach \
--publish 5005:5005 \
--publish 6006:6006 \
--volume "$PWD/.ci-config/:/etc/xrpld/" \
--name xrpld-service \
rippleci/xrpld:develop --standalone
SECONDS=0
until nc -z localhost 6006 || [ $SECONDS -gt 120 ]; do sleep 2; done
if ! nc -z localhost 6006; then
echo "Error: xrpld did not start within 120s"
docker logs xrpld-service
exit 1
fi
poetry run poe test_integration
poetry run coverage report --fail-under=70
docker logs xrpld-service && docker stop xrpld-serviceFaucet tests:
poetry run poe test_faucet
Collect results from all parallel runs. All Python versions must pass.
If any step fails, attempt to fix the breaking change with code modifications before rolling back. Common patterns:
Only roll back and mark as Skipped if:
If a failure is traced to a specific dependency upgrade, revert that upgrade in pyproject.toml, re-run poetry lock && poetry install, mark it as Skipped, and re-run validation until green.
After all upgrades are applied and validation passes, generate the following outputs:
Write .claude/skills/batch-deps-upgrade/code-changes.md documenting every non-pyproject.toml source code change, explaining what broke, why, and the minimal fix applied.
Write .claude/skills/batch-deps-upgrade/pr-description.md following the repo's PR template (.github/pull_request_template.md):
CHANGELOG.md entry was added in Step 2.7.No if the major version number did not change. Otherwise Yes plus a link for each major version crossed. For example, 1.x → 3.x yields Yes ([v2](url), [v3](url)). Each link should point to the package's release notes or changelog for that major version. Verify each link returns HTTP 200 and has meaningful content (e.g., curl -sL -o /dev/null -w "%{http_code}" <url>); if a package doesn't publish per-version GitHub releases, fall back to the CHANGELOG file or the closest valid release tag.