Skyvern/.claude/skills/bump-version/SKILL.md
Marc Kelechava 3b9a5659f6
bump version 1.0.23 (#4952)
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
2026-03-02 15:07:44 -08:00

4.1 KiB

name description argument-hint disable-model-invocation
bump-version Bump Skyvern OSS version, build Python and TypeScript SDKs with Fern, and create release PR. Use when releasing a new version or when the user asks to bump version.
version
true

Bump Version Skill

Automate the complete OSS version bump and release workflow for Skyvern.

What this does

  1. Validates and updates version in pyproject.toml
  2. Builds Python SDK with Fern
  3. Builds TypeScript SDK with Fern
  4. Creates commit with all changes
  5. Optionally runs SDK tests
  6. Pushes branch and creates PR

Version argument

The version can be provided as an argument or you'll be prompted:

  • If $ARGUMENTS is provided, use it as the new version
  • If not provided, ask user for the new version number
  • Validate it follows semver format: MAJOR.MINOR.PATCH (e.g., 1.0.14, 1.1.0, 2.0.0)

Semver guidance:

  • PATCH: Bug fixes, backwards compatible (e.g., 1.0.13 → 1.0.14)
  • MINOR: New features, backwards compatible (e.g., 1.0.13 → 1.1.0)
  • MAJOR: Breaking changes (e.g., 1.0.13 → 2.0.0)

Step-by-step process

1. Get and validate version

  • Read current version from pyproject.toml line 3
  • Determine new version from $ARGUMENTS or prompt user
  • Validate semver format using regex: ^\d+\.\d+\.\d+$
  • Confirm with user: "Bumping version from {current} to {new}. Continue?"

2. Create feature branch

git checkout -b bump-version-$ARGUMENTS

Branch naming: bump-version-{version} (e.g., bump-version-1.0.14)

3. Update pyproject.toml

Update line 3 in pyproject.toml:

version = "{new_version}"

Use the Edit tool to make this single-line change.

4. Build Python SDK

bash scripts/fern_build_python_sdk.sh
  • Wait for completion
  • Check output for errors
  • Fern reads version from pyproject.toml

5. Build TypeScript SDK

bash scripts/fern_build_ts_sdk.sh
  • Wait for completion
  • Check output for errors
  • Verify skyvern-ts/client/package.json version matches new version

6. Review changes

git status
git diff --stat

Show user:

  • Number of files changed
  • Which files were modified
  • Summary of changes

7. Commit changes

git add .
git commit -m "Bump version to {version}

- Update version in pyproject.toml
- Regenerate Python SDK with Fern
- Regenerate TypeScript SDK with Fern

Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>"

8. Verify SDKs (optional)

Ask user: "Would you like to run SDK tests to verify nothing broke?"

If yes:

  • Python SDK tests: pytest tests/sdk/python_sdk/
  • Note that TypeScript tests require manual Chrome setup (see tests/sdk/README.md)
  • Display test results
  • If tests fail, STOP and report errors - do not proceed to push

If no:

  • Skip to push step

9. Push and create PR

Ask user: "Ready to push and create PR?"

If yes:

git push -u origin bump-version-{version}

gh pr create --title "Bump version to {version}" --body "## Summary
Bump Skyvern OSS version to {version}

## Changes
- Updated version in \`pyproject.toml\`
- Regenerated Python SDK with Fern
- Regenerated TypeScript SDK with Fern

## Deployment
After merge, GitHub will automatically:
- Deploy Python package to PyPI (version change in \`pyproject.toml\`)
- Deploy TypeScript package to NPM (version change in \`package.json\`)

## Testing
- [ ] Python SDK tests passed locally
- [ ] TypeScript SDK tests passed locally (if applicable)

🤖 Generated with [Claude Code](https://claude.com/claude-code)"

Display the PR URL to the user.

Important notes

  • Single PR: All changes (version bump, SDK generation, commit) happen in one PR
  • Fern sync: Fern reads version from pyproject.toml and syncs to package.json
  • Testing: SDK tests require .env with SKYVERN_API_KEY
  • Deployment: Automatic on PR merge via GitHub Actions
  • No force push: Never use --force when pushing

Error handling

If any step fails:

  1. Display the error message clearly
  2. Explain what went wrong
  3. Ask user how to proceed (fix, skip, or abort)
  4. Do not continue to next steps if critical operations fail