Analyze test coverage and identify gaps with actionable recommendations
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Prepare and execute a Python package release with verification steps. Use for releasing Python packages with uv and ruff.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
설치하기 전에 에이전트에게 전달되는 지시 내용을 확인할 수 있습니다.
Execute a complete pre-release workflow for Python packages using uv and ruff. This command automates version calculation, changelog updates, and tag creation.
$ARGUMENTS - Optional version override (e.g., 1.0.0). If not provided, version is calculated from changelog entries.Execute these 9 steps in order. Fail fast: Stop immediately if any verification step fails.
Run these checks and stop if any fail:
# Check current branch
git branch --show-current
main branch. If not, stop and report: "Release must be run from the main branch. Currently on: {branch}"# Check for uncommitted changes
git status --porcelain
# Pull latest changes
git pull origin main
Execute the test suite:
uv run pytest
Execute linting checks:
uv run ruff check
uv run ruff format --check
Build the package:
uv build
All verification checks have passed. Before calculating the version, offer to run the changelog-agent to ensure the [Unreleased] section is up-to-date.
Use AskUserQuestion:
Would you like to run the changelog-agent to update CHANGELOG.md before proceeding?
This will analyze git commits since the last release and suggest new changelog entries.
Options:
If user selects "Yes":
Use the Task tool to spawn the changelog-agent:
changelog-managerIf user selects "No":
Continue to Step 6 (Calculate Version) without running the changelog-agent.
Read CHANGELOG.md and parse its structure. Look for:
## [Unreleased] section and its subsections## [0.1.0]) to get the current versionCount entries under [Unreleased] by subsection:
### Added - New features### Changed - Changes to existing functionality### Deprecated - Features marked for removal### Removed - Removed features (breaking change)### Fixed - Bug fixes### Security - Security fixesApply semantic versioning rules to the current version (MAJOR.MINOR.PATCH):
| Condition | Bump Type | Example |
|---|---|---|
### Removed present AND current >= 1.0.0 | MAJOR | 1.2.3 → 2.0.0 |
### Removed present AND current < 1.0.0 | MINOR | 0.2.3 → 0.3.0 |
### Added or ### Changed present | MINOR | 0.1.0 → 0.2.0 |
Only ### Fixed, ### Security, or ### Deprecated | PATCH | 0.1.0 → 0.1.1 |
$ARGUMENTS as the version instead of calculatingUse AskUserQuestion to confirm the version:
Based on changelog analysis:
- Found: {count} Added, {count} Changed, {count} Fixed, {count} Removed entries
- Current version: {current}
- Suggested version: {suggested} ({bump_type} bump)
Confirm version or provide override:
Options:
Read pyproject.toml and extract the repository URL from [project.urls]:
Repository, repository, Source, source, Homepage, homepageIf no repository URL found, warn but continue (comparison links will be omitted).
Transform the changelog:
Before:
## [Unreleased]
### Added
- New feature X
## [0.1.0] - 2024-01-15
### Added
- Initial release
[Unreleased]: https://github.com/user/repo/compare/v0.1.0...HEAD
[0.1.0]: https://github.com/user/repo/releases/tag/v0.1.0
After (releasing 0.2.0):
## [Unreleased]
## [0.2.0] - {today's date YYYY-MM-DD}
### Added
- New feature X
## [0.1.0] - 2024-01-15
### Added
- Initial release
[Unreleased]: https://github.com/user/repo/compare/v0.2.0...HEAD
[0.2.0]: https://github.com/user/repo/compare/v0.1.0...v0.2.0
[0.1.0]: https://github.com/user/repo/releases/tag/v0.1.0
Use the Edit tool to update CHANGELOG.md with the transformed content.
Stage and commit the changelog update:
git add CHANGELOG.md
git commit -m "docs: update changelog for v{version}"
git push origin main
Report: "Changelog committed and pushed"
Create an annotated tag and push it:
git tag -a v{version} -m "Release v{version}"
git push origin v{version}
Report success with details:
Release v{version} completed successfully!
- Changelog updated: CHANGELOG.md
- Tag created: v{version}
- Tag URL: {repository_url}/releases/tag/v{version}
Next steps:
- GitHub/GitLab will create a release from the tag
- Publish to PyPI if configured in CI
If any step fails after Step 6 (version confirmation):
git checkout CHANGELOG.md - Revert changelog changesgit tag -d v{version} - Delete local tag if createdgit push origin :refs/tags/v{version} - Delete remote tag if pushed아직 리뷰가 없습니다. 사용해 본 소감을 남겨 주세요.
로그인 없이 쓸 수 있습니다. 사용 후기, 질문, 작동하지 않은 환경 등을 편하게 남겨 주세요.
아직 댓글이 없습니다. 첫 댓글을 남겨 보세요.
Analyze test coverage and identify gaps with actionable recommendations
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Analyze an existing spec for inconsistencies, missing information, ambiguities, and structure issues. Use when user says "analyze spec", "review spec", "spec quality check", "validate requirements", "audit spec", or "check spec quality".
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Provides architectural pattern knowledge for designing feature implementations including MVC, event-driven, microservices, and CQRS patterns. Use when designing system architecture or choosing implementation patterns.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Executes diagnostic investigation tasks to test debugging hypotheses. Runs tests, traces execution, checks git history, and reports evidence. (converted from agent)
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Systematic, hypothesis-driven debugging workflow with triage-based track routing. Use when asked to "fix this bug", "debug this", "why is this failing", "this is broken", "investigate this error", "track down this issue", or any debugging situation. Supports --deep flag to force full investigation.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.
Systematic, hypothesis-driven debugging workflow with triage-based track routing. Use for debugging, fixing bugs, and investigating errors.
한국어 요약은 준비 중입니다. 원문 설명을 표시하고 있습니다.