/release
Bump the version and publish to PyPI + npm.
$ npx -y skills add Lap-Platform/LAP --agent claude-codeHow it fires
How this command gets triggered: by you, by Claude, or both.
- Fires itselfClaude auto-loads it when your prompt matches the work.
- You can call itInvoke it directly when you want it.
- Slash command
/release
Context preview
What this command does when you run it.
Bump the version and publish to PyPI + npm.
Command definition
release.mdRelease a new version of LAP
Bump the version and publish to PyPI + npm.
Arguments
- $ARGUMENTS: The new version number (e.g. "0.5.0"). If empty, ask the user.
Steps
1. **Validate version**: Ensure the version argument is a valid semver string (X.Y.Z). If not provided or invalid, ask the user for the version number.
2. **Run tests first**: Run `PYTHONUTF8=1 python -m pytest tests/ -q --timeout=30` from the project root. If any tests fail, STOP and report the failures. Do not proceed with a broken build.
3. **Bump version in all files**:
- `lap/__init__.py` -- update `__version__`
- `pyproject.toml` -- update `version`
- `sdks/typescript/package.json` -- update `version`
4. **Update CHANGELOG.md**: Add a new `## [X.Y.Z] - YYYY-MM-DD` section at the top (below the header). Ask the user for a summary of changes, or generate one from recent git log if the user says to auto-generate.
5. **Update README.md**: Review the changelog for this release. If it includes new features, new commands, new IDE support, or changed behavior that users need to know about, update README.md accordingly (Quick Start, Use as an Agent Skill, Ecosystem table, badges, etc.). If the release is only bug fixes or internal changes, skip this step.
6. **Commit**: Stage all changed files and commit with message: `chore: bump to vX.Y.Z with changelog`
7. **Push**: Push to origin/main.
8. **Create GitHub Release**: Run `gh release create vX.Y.Z --title "vX.Y.Z" --notes-file CHANGELOG_SECTION` where CHANGELOG_SECTION contains only the new version's changelog section.
9. **Monitor publish workflows**: After the release is created, poll the two workflow runs:
- `Publish to PyPI`
- `Publish to npm`
Use `gh run list --limit 4` to find the run IDs, then use `gh run watch <run-id>` to monitor each. Report the final status of each workflow to the user (success/failure). If a workflow fails, show the failure logs using `gh run view <run-id> --log-failed`.
Important
- Never skip tests before releasing
- All three version files must be in sync
- The GitHub release triggers the publish workflows via `on: release: types: [published]`
- Do not publish manually -- always use the GitHub Actions workflows
Read more
Release a new version of LAP
Bump the version and publish to PyPI + npm.
Arguments
- $ARGUMENTS: The new version number (e.g. "0.5.0"). If empty, ask the user.
Steps
1. **Validate version**: Ensure the version argument is a valid semver string (X.Y.Z). If not provided or invalid, ask the user for the version number.
2. **Run tests first**: Run `PYTHONUTF8=1 python -m pytest tests/ -q --timeout=30` from the project root. If any tests fail, STOP and report the failures. Do not proceed with a broken build.
3. **Bump version in all files**:
- `lap/__init__.py` -- update `__version__`
- `pyproject.toml` -- update `version`
- `sdks/typescript/package.json` -- update `version`
4. **Update CHANGELOG.md**: Add a new `## [X.Y.Z] - YYYY-MM-DD` section at the top (below the header). Ask the user for a summary of changes, or generate one from recent git log if the user says to auto-generate.
5. **Update README.md**: Review the changelog for this release. If it includes new features, new commands, new IDE support, or changed behavior that users need to know about, update README.md accordingly (Quick Start, Use as an Agent Skill, Ecosystem table, badges, etc.). If the release is only bug fixes or internal changes, skip this step.
6. **Commit**: Stage all changed files and commit with message: `chore: bump to vX.Y.Z with changelog`
7. **Push**: Push to origin/main.
8. **Create GitHub Release**: Run `gh release create vX.Y.Z --title "vX.Y.Z" --notes-file CHANGELOG_SECTION` where CHANGELOG_SECTION contains only the new version's changelog section.
9. **Monitor publish workflows**: After the release is created, poll the two workflow runs:
- `Publish to PyPI`
- `Publish to npm`
Use `gh run list --limit 4` to find the run IDs, then use `gh run watch <run-id>` to monitor each. Report the final status of each workflow to the user (success/failure). If a workflow fails, show the failure logs using `gh run view <run-id> --log-failed`.
Important
- Never skip tests before releasing
- All three version files must be in sync
- The GitHub release triggers the publish workflows via `on: release: types: [published]`
- Do not publish manually -- always use the GitHub Actions workflows
Agent-Native API specs. Verified, compressed, ready to install. Without API documentation, LLM agents hallucinate endpoints, invent parameters, and guess auth flows -- scoring just 0.399 accuracy in blind tests. LAP fixes this.