ship-notes
Skill1 starsChanged 15 days agoMITView on GitHub
Write changelog or release notes from the real commit range. Use when the user asks for a changelog, release notes, version summary, or what shipped. Match this repo's existing notes format. Do not invent commits or user-facing claims the diff does not support.
2 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- rpraharaj/ai-sdlcedited, first seen Nov 1, 2026
- jeana-adhoc/claude-skillstheir own version, first seen Jun 26, 2026
Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 1
- rpraharaj/ai-sdlc★ 024% same
Wrote their own version · 1
- jeana-adhoc/claude-skills★ 1same name
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository34 other files it gives its agents.
- AGENTS.mdAGENTS.md
- templates/AGENTS.mdAGENTS.md
- commitSkill
- cut-releaseSkill
- data-changeSkill
- debugSkill
- engineering-barSkill
- explain-codeSkill
- explore-codebaseSkill
- fix-ciSkill
- handoffSkill
- implement-changeSkill
- incident-triageSkill
- lean-reviewSkill
- open-prSkill
- performanceSkill
- production-passSkill
- ready-to-mergeSkill
- record-decisionSkill
- refactor-safelySkill
- resolve-conflictsSkill
- revert-changeSkill
- review-changeSkill
- security-passSkill
- shape-workSkill
- start-projectSkill
- upgrade-depsSkill
- verify-uiSkill
- write-architectureSkill
- write-designSkill
- write-dev-tasksSkill
- write-docsSkill
- write-prdSkill
- write-testsSkill
The file
We split this skill into the rules it gives an agent
12 rules. About 0 are common, 8 are distinctive, and 4 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈8
Distinctive · estimate
This author's own choices. Worth a look.
4
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 14
Read AGENTS.md if present.
- Very specific: line 18
Default: since the last version tag (git describe --tags --abbrev=0 if tags exist) to HEAD.
- Distinctive: line 25
If this is not a git repo or the range is empty, stop.
- Distinctive: line 29
Use the first that exists and already has entries:
- Very specific: line 44
Call out breaking changes and migrations the operator must run.
- Very specific: line 46
Do not claim performance or security wins unless the commits or a measured performance / security-pass note say so.
- Distinctive: line 48
If the repo uses fragments, add one fragment per user-facing change in that tool's naming scheme.
- Distinctive: line 52
Only if the user asked to bump:
- Distinctive: line 54
Follow this repo's versioning (semver if that is what tags look like: breaking → major, feature → minor, fix → patch)
- Distinctive: line 55
Update the authoritative version sources and derived lockfiles/manifests this repo's tooling requires, plus the changelog heading.
- Distinctive: line 56
Do not tag or publish unless the user asked
- Very specific: line 65
Do not commit, tag, or publish unless asked.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Ship notes
Describe what actually shipped. Source of truth is the commit range (and the diff if the messages are vague). Do not invent features, metrics, or migrations.
Read AGENTS.md if present.
Range
Default: since the last version tag (git describe --tags --abbrev=0 if tags exist) to HEAD. If the user named a tag, PR, or date, use that.
git log --oneline <from>..HEAD
git diff --stat <from>..HEADIf this is not a git repo or the range is empty, stop.
Detect the format
Use the first that exists and already has entries:
CHANGELOG.md/CHANGES.md/HISTORY.mdchangelog/fragments (keep a changelog, towncrier, or this repo's equivalent)- GitHub/GitLab release body style if that is what the user asked for and no file exists
- Otherwise write Keep a Changelog-style sections in the reply only: Added / Changed / Fixed / Removed / Security / Migration
Match heading level, date style, and version prefix (v1.2.3 vs 1.2.3) from the last entry. Do not switch the file to a new format.
Version number: from the user's ask, or from this repo's version field (package.json, pyproject.toml, Cargo.toml, VERSION, latest tag). If you cannot tell, ask or use Unreleased.
Write
- User-facing first. Group by kind, not by commit hash.
- One line per change. Merge "fix typo" and chore-only commits into nothing, or a single Internal line if this repo records those.
- Call out breaking changes and migrations the operator must run. Those come from
data-changeplans and the diff, not from guesswork. - Omit attribution boilerplate such as "generated by." Mention agents or models when they describe the actual product change.
- Do not claim performance or security wins unless the commits or a measured
performance/security-passnote say so.
If the repo uses fragments, add one fragment per user-facing change in that tool's naming scheme. Do not also rewrite the rolled-up file unless the user asked to cut a release.
Optional version bump
Only if the user asked to bump:
- Follow this repo's versioning (semver if that is what tags look like: breaking → major, feature → minor, fix → patch)
- Update the authoritative version sources and derived lockfiles/manifests this repo's tooling requires, plus the changelog heading; respect independent package versions
- Do not tag or publish unless the user asked
Done
- Range (
from→HEAD) - Path edited or the notes in the reply
- Breaking / migration callouts
- Whether you bumped a version (and to what)
Do not commit, tag, or publish unless asked. Next is usually commit (notes only or notes + bump). If they asked to tag, publish, or deploy, continue with cut-release.
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.