nowledge-conowledge-co/con-terminal/skills/changelog-release-notes/SKILL.md

changelog-release-notes

Skill651 starsChanged 7 days agoMITView on GitHub

Maintain Con's CHANGELOG.md and release notes. Use when updating changelog entries, preparing a beta/dev release, reviewing PR release-note coverage, or ensuring contributor PR credit is present.

2 other projects use a version of this.

Adopted by

Most recently taken up by

megandmartin/agent-skills-repotheir own version, first seen Jul 24, 2026
kweaver-ai/skillstheir own version, first seen Mar 11, 2026

Other versions2 projects use a version of this.
Word for word · 0
None found.
Edited · 0
None found.
Wrote their own version · 2
megandmartin/agent-skills-repo★ 3same name
kweaver-ai/skills★ 0same 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 repository8 other files it gives its agents.
- AGENTS.mdAGENTS.md
- con-cli-e2eSkill
- con-terminalSkill
- gpui-cache-awareSkill
- native-surface-coverageSkill
- releaseSkill
- terminal-agent-benchmarkSkill
- terminal-agent-improvement-loopSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 7 are distinctive, and 6 are very specific to this project.

≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
6
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Use this skill whenever CHANGELOG.md, PR release notes, or release summaries are touched.
line 8
Distinctive:
Verify the latest released beta before choosing a heading:
line 13
Very specific:
Put pending work under the next beta only.
line 17
Distinctive:
Every PR-derived changelog bullet must end with PR and author credit:
line 25
Distinctive:
Keep shipped historical sections stable.
line 29
Distinctive:
Write for users first: describe the visible behavior or benefit, not the internal implementation unless it explains a risk or platform …
line 34
Very specific:
Use Added, Changed, and Fixed sections.
line 36
Distinctive:
Do not mention "workspace restore" or other baseline continuity as novelty unless the user-facing behavior truly changed.
line 39
Very specific:
Use ordinary commits for changelog/date bookkeeping, without [skip ci].
line 49
Very specific:
After a release, check the latest shipped headings against gh release list --json tagName,publishedAt.
line 53
Distinctive:
If a bullet combines multiple PRs, include all relevant PR/author credits.
line 56
Very specific:
Run python3 scripts/docs/validate-manifest.py when docs routing may be affected.
line 62
Distinctive:
Run git diff --check before committing.
line 64

≈ “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.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Changelog Release Notes

Use this skill whenever CHANGELOG.md, PR release notes, or release summaries are touched.

Workflow

Verify the latest released beta before choosing a heading:
- git fetch --tags origin
- git tag --sort=-v:refname | rg '^v[0-9]+\\.[0-9]+\\.[0-9]+-beta\\.' | head
- gh release view <tag> when GitHub release state matters
Put pending work under the next beta only. If the latest shipped beta is v0.1.0-beta.63, the top unreleased heading is v0.1.0-beta.64; do not create beta.65 until beta.64 is tagged and released.
Gather PR and author context for every entry:
- gh pr view <number> --json number,title,author,url,mergedAt
- for merged work, git log <latest-tag>..HEAD --merges --oneline helps find the included PRs
Every PR-derived changelog bullet must end with PR and author credit:
- _(PR [#149](https://github.com/nowledge-co/con-terminal/pull/149) by [@sundy-li](https://github.com/sundy-li))_
Credit contributors exactly by GitHub login. Preserve external contributor credit even when follow-up commits refine the same feature.
Keep shipped historical sections stable. Only edit old sections to correct a factual mistake, missing credit, or broken link.

Writing Rules

Write for users first: describe the visible behavior or benefit, not the internal implementation unless it explains a risk or platform boundary.
Use Added, Changed, and Fixed sections. Group bullets under concise audience/platform labels such as macOS, Windows, Linux, Panes, or Developer Experience.
Do not mention "workspace restore" or other baseline continuity as novelty unless the user-facing behavior truly changed. Default expected behavior should read as polish or reliability, not marketing.
For an authorized release, date the changelog during preparation using the current Asia/Shanghai date, before merging/tagging. This optimistic date keeps the website from showing Unreleased during successful publication. Do not add a second date-only bookkeeping commit after release. If publication is delayed to another day, correct the date when resuming. Dates are editorial intent; release/draft status and artifact gates remain the delivery authority.
Ordinary feature PRs without release authorization may remain Unreleased.
Use ordinary commits for changelog/date bookkeeping, without [skip ci]. Workflow path filters skip native tests/builds for documentation-only changes while preserving metadata checks and public docs updates. See docs/impl/build-system.md.
After a release, check the latest shipped headings against gh release list --json tagName,publishedAt; use the release date in Asia/Shanghai, matching the existing changelog convention. Do not leave shipped headings undated.
If a bullet combines multiple PRs, include all relevant PR/author credits.

Validation

Confirm the heading matches the latest shipped beta plus one.
Confirm every new PR-derived bullet has PR [#...] and by [@...].
Run python3 scripts/docs/validate-manifest.py when docs routing may be affected.
Run git diff --check before committing.

Download now (ZIP)

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

What did you use it for? e.g. Reviewing pull requests in a Rails app

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.

Check your setup, free