git-flow-release
Release
Communication
- Communicate with the developer in Japanese.
- Write commit messages and tag messages in English.
Prerequisites
Before starting the release process, verify:
- All changes are committed (
git statusshould show a clean working tree). - You are on the target branch (
mainunless the user specifies otherwise).
This repository does not have mandatory lint/test commands; do not run Node/bun/turbo checks here.
Version Format
Use calendar-based versioning with v prefix for git tags:
- Git tag:
vYYYY.MM.DD.N(e.g.,v2026.02.04.1)
Components:
- YYYY: 4-digit year (e.g., 2026)
- MM: 2-digit month (e.g., 02)
- DD: 2-digit day (e.g., 04)
- N: Daily release number starting from 1, incrementing for each subsequent release on the same day
Version Determination
-
Determine today's date in
YYYY.MM.DD:today=$(date +%Y.%m.%d) -
Check existing tags for today:
git tag --list "v${today}.*" -
Choose the next
N:- If no tags exist for today, use
N=1→vYYYY.MM.DD.1 - If tags exist for today (e.g.,
vYYYY.MM.DD.1), incrementN(e.g.,vYYYY.MM.DD.2)
- If no tags exist for today, use
Release Workflow (tag-based)
Execute the following steps in order:
-
Determine version
- Decide
YYYY.MM.DD.Nand prepare short release notes (bullet list)
- Decide
-
Commit changes (if needed)
git add -A git commit -m "chore: prepare release vYYYY.MM.DD.N" -
Create annotated tag
git tag -a vYYYY.MM.DD.N -m "Release vYYYY.MM.DD.N" -
Push main with tags
git push origin main --tags -
(Optional) Create a GitHub Release
If
ghis available and the user requests it:gh release create vYYYY.MM.DD.N --generate-notes
Git-flow (optional)
Only use this section if git-flow is configured for the repository (a develop branch exists and git flow init has been run).
-
Start release
git flow release start YYYY.MM.DD.N -
Finish release (macOS/BSD safe path)
Always finish without tagging and add the tag manually (avoids getopt errors with
-m).git flow release finish -n YYYY.MM.DD.N git switch main git tag -a vYYYY.MM.DD.N -m "Release vYYYY.MM.DD.N" -
Push branches and tags
git push origin develop git push origin main --tags
Post-release Report
After completing all steps, report:
- The released version number (e.g.,
2026.02.04.1) - The tag name created (e.g.,
v2026.02.04.1) - Confirmation that the tag was pushed
- (If created) Confirmation that the GitHub Release was published
Error Handling
- If tagging fails because there are no commits yet, create the initial commit first.
- If
git flowis not installed, inform the user and suggest installing it. - If merge conflicts occur during
git flow release finish, stop and report the conflict details. - If push fails, check remote status and report the issue.
More from iktakahiro/python-fastapi-ddd-skill
python-fastapi-ddd-skill
Guides FastAPI backend design using Domain-Driven Design (DDD) and Onion Architecture in Python. Use when structuring a FastAPI app (routes/handlers, Pydantic schemas, Depends-based DI), modeling domain Entities/Value Objects, defining repository interfaces, implementing SQLAlchemy infrastructure adapters, or writing use cases, based on the dddpy reference.
32python-fastapi-ddd-testing-skill
Guides unit testing for Python DDD + Onion Architecture apps (Domain Entities/Value Objects and UseCases) using pytest and repository mocks, based on the dddpy reference. Use when adding tests, choosing what to mock, or structuring test folders for a DDD FastAPI project.
17python-fastapi-ddd-presentation-skill
Guides the FastAPI Presentation layer in a Python DDD + Onion Architecture app (route handler structure, Pydantic request/response schemas, mapping Domain exceptions to HTTP errors, and OpenAPI error documentation), based on the dddpy reference. Use when adding/refactoring endpoints that call UseCases and convert primitives ↔ Value Objects/Entities.
9commit
Prepare and create git commits in this repository using Conventional Commits; use when the user asks to commit or split commits for a task.
4