Manages changelogs as Markdown fragments compiled into CHANGES.md at release time.
npx skills add https://github.com/dahlia/logtape --skill sacho
Please help me install this Agent Skill. Skill: sacho Source: https://github.com/dahlia/logtape/tree/main/.agents/skills/sacho Command: npx skills add https://github.com/dahlia/logtape --skill sacho
Maintaining user-facing release notes is tedious and error-prone: entries get forgotten, merge conflicts pile up in a single CHANGES.md file, and auto-generated notes from commit messages read poorly for end users. This Skill guides maintainers through adopting and operating Sacho, a changelog manager that stores one small Markdown fragment per change under changes.d/ and compiles them into a dated CHANGES.md section at release time.
sacho add, sacho fmt, sacho preview, and sacho check, keeping each entry in the same commit series as its code change.sacho release, publish notes via sacho show piped to GitHub Releases, and forward-port bugfix releases across maintenance branches with sacho carry.sacho check into CI or pre-commit hooks so commits touching configured paths require a fragment, with a Changelog: none trailer as an explicit opt-out.sacho add fix-timeout, write a user-facing entry starting with a past-tense verb, and let CI verify the fragment exists before merge; at release time one command compiles all fragments into the new version section.Ask the assistant to check whether this repository has a sacho.toml or changes.d/ directory, then run sacho init to adopt Sacho or sacho add to write a changelog fragment for your latest change.
High-intent search queries and answers about installing and using this skill.
Run `sacho add <topic-name>` to create a fragment under changes.d/, write a user-facing entry starting with a past-tense verb like Added or Fixed, then run `sacho fmt`, `sacho preview`, and `sacho check`. Name the file after the change itself, not an issue or PR number.
Set the version with `sacho next 1.2.0`, review the output of `sacho preview`, then run `sacho release --next 1.3.0`. The release command stamps a dated section in CHANGES.md, deletes the consumed fragments, and records the next version.
No. Sacho never generates entries from commit messages, and the skill explicitly instructs against doing so. A changelog entry must be written for users, describing what changed on the public surface and what to do when upgrading.
Configure `[check].paths` in sacho.toml with the globs whose changes require a fragment, then run `sacho check --base origin/main` in CI. A commit with no user-visible effect can opt out using a `Changelog: none` trailer in its message.
If you merge before releasing, the fragment travels with the merge and each branch consumes its own copy. If you merge an already-released tag, run `sacho carry 1.1.5` to decompile that section back into fragments for the receiving branch's next release.
Failures fall into three layers: fragment validity and formatting, drift between CHANGES.md and the fragments, and missing-fragment coverage for changed paths. Run `sacho check --fix` for mechanical repairs, or write the missing entry or add a `Changelog: none` exemption.
vfarcicCreate semantic version release tags from changelog.d fragments.
kuboonAutomate Deno package releases to JSR with Git tags and GitHub Actions.
HomericIntelligenceRun Mojo format, markdownlint, and pre-commit hooks for code quality checks.
leifericfGenerates changelog entries from commit messages for project releases.