메뉴
Create and publish releases for the LogTape project. Use when releasing a new version, creating a patch release, or creating a major/minor release. Handles Sacho changelog compilation, version bumping, tagging, and branch management.
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
SOC 직업 분류 기준
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/dahlia/logtape --skill release명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
| name | release |
| description | Create and publish releases for the LogTape project. Use when releasing a new version, creating a patch release, or creating a major/minor release. Handles Sacho changelog compilation, version bumping, tagging, and branch management. |
LogTape uses Sacho to keep unreleased changelog entries in changes.d/ and compile them into CHANGES.md. Never edit the materialized unreleased region of CHANGES.md by hand. Edit the fragments and let Sacho update the changelog.
There are two types of releases: patch releases from X.Y-maintenance
branches, and major/minor releases from main. The Sacho release guide
describes the underlying changelog lifecycle.
Before starting any release:
Read and follow AI_POLICY.md. Every AI-assisted commit must include an
Assisted-by: AGENT_NAME:MODEL_VERSION trailer.
Verify the branch, worktree, and remote:
git status --short --branch
git remote -v
All GitHub operations must target dahlia/logtape. Use the actual remote
name in commands below; do not assume it is origin.
Ensure the branch is up to date and that the release version in changes.d/next.txt matches the package versions. If the next version has not been prepared yet, set both through the repository task and commit that change before releasing:
mise run bump-version 1.2.3
Do not call sacho next and mise run update-versions separately. The
task keeps the Sacho next-version file and package versions together.
Review the release notes as a user would, then run the full test suite:
sacho preview
sacho check
mise run test
Edit the source fragments to combine duplicate entries, remove development
history, and describe public behavior. Run sacho fmt after editing a
fragment and repeat the preview and checks.
Patch releases such as 1.2.3 are created from the matching
X.Y-maintenance branch.
Check out and update the maintenance branch:
git checkout 1.2-maintenance
git pull
Complete the prerequisite review and checks above.
Compile the fragments into the released changelog section:
sacho release 1.2.3
mise run fmt
sacho release dates the new CHANGES.md section, removes the consumed
fragments, and removes changes.d/next.txt. Review all three parts of the
diff. Do not replace this command with a manual edit to CHANGES.md.
Run mise run check, then commit the changelog, deleted fragments, and
deleted next-version file together. Use Release 1.2.3 as the subject
and include the AI disclosure trailer when applicable.
Create the tag without a v prefix. Always pass -m so a signed tag does
not open an editor:
git tag -m "LogTape 1.2.3" 1.2.3
Use the repository task to create the next Sacho region and update every package version:
mise run bump-version 1.2.4
sacho check
mise run check
Review and commit changes.d/next.txt, the materialized CHANGES.md region,
and all package version changes together. Use Version bump as the subject,
retain the existing [ci skip] body, and include the AI disclosure trailer
when applicable.
Push the tag and maintenance branch to the verified remote:
git push origin 1.2.3 1.2-maintenance
Replace origin with the remote name found during the prerequisite check.
Forward-port a patch release through newer maintenance branches and finally to
main.
When possible, merge the maintenance branch before releasing it. The unconsumed fragments then travel with the code and require no Sacho-specific work.
When merging an already released tag, the release commit contains a frozen changelog section but no fragments. The Sacho merge driver places the frozen section in CHANGES.md and preserves the receiving branch's changes.d/next.txt.
Check out the newer branch and merge the released tag:
git checkout 1.3-maintenance
git merge 1.2.3
If this branch's next release should repeat the patch notes, first check that no edited carried-from-1.2.3.md fragment already exists, then run:
sacho carry 1.2.3
sacho carry recreates package-scoped fragments from the frozen section.
Edit them if the later branch exposes different behavior. Re-running the
command overwrites existing carried fragments.
Resolve code conflicts. Do not copy entries into CHANGES.md by hand. Fix fragments instead, then run:
sacho fmt
sacho preview
sacho check
mise run test
Complete the merge and release the newer branch's patch version. Continue through each newer maintenance branch.
Merge the last released tag into main, resolve conflicts, and run the same
checks. Do not run sacho carry for this merge: LogTape does not duplicate
patch-release notes in the next major/minor release.
Major and minor releases such as 1.3.0 and 2.0.0 are created from main with
patch version 0.
Check out and update main, then complete the prerequisite review and
checks.
Compile, format, and review the release:
sacho release 1.3.0
mise run fmt
mise run check
Commit the release changes with subject Release 1.3.0, including the AI
disclosure trailer when applicable, then create the tag:
git tag -m "LogTape 1.3.0" 1.3.0
Start the next minor cycle on main:
mise run bump-version 1.4.0
sacho check
mise run check
Commit the next-version file, materialized changelog region, and package version changes together as the version bump.
Push main and the release tag to the verified remote:
git push origin 1.3.0 main
Create the maintenance branch from the release tag, not from the version-bump
commit on main:
git branch 1.3-maintenance 1.3.0
git checkout 1.3-maintenance
mise run bump-version 1.3.1
sacho check
mise run check
Commit the first patch cycle's next-version file, materialized changelog region, and package version changes together, then push the branch:
git push origin 1.3-maintenance
When release notes must be published manually, render only the frozen release section:
sacho show 1.3.0 --skip-heading --no-word-wrap \
--output-file release-notes.md
sacho show never compiles current fragments. Use the generated file as the
release notes, then remove it if it is only a temporary publishing artifact.
X.Y.Z where Z > 0, such as 1.2.3X.Y.0, such as 1.3.0X.0.0, such as 2.0.0X.Y-maintenance, such as 1.2-maintenancev prefix, such as 1.2.3LogTape X.Y.ZHelp a maintainer adopt and operate Sacho, the opinionated changelog manager that keeps user-facing release notes as one small Markdown fragment per change under changes.d/ and compiles them into CHANGES.md at release time. Use this skill whenever a repository has a sacho.toml, a changes.d/ directory, or a CHANGES.md built from fragments; whenever the user wants to add Sacho to a project, write or edit a changelog entry for a change they just made, cut a release, publish release notes, or wire `sacho check` into CI or a pre-commit hook; whenever forward-porting a bugfix release across maintenance branches or resolving a changelog merge conflict; and whenever `sacho check` or the changelog merge driver reports a problem. Also use it any time the user mentions Sacho, changes.d fragments, or asks how to write a changelog entry for users instead of generating one from commit messages.
Use this skill when writing any code that uses LogTape for logging in JavaScript or TypeScript. Covers getting loggers, the structured message syntax, configuration, library author rules, context, lazy evaluation, testing, and common mistakes to avoid. Trigger whenever the user is adding logging to a project, debugging log output, or integrating LogTape with a framework.