skillshare-changelog
- Repo stars 1,897
- Author updated Live
- Author repo skillshare
- Domain
- Other
- Compatible agents
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- Trust score
- 88 / 100 · community maintained
- Author / version / license
- @runkids · no license declared
- Token usage
- Lean
- Setup complexity
- Plug-and-play
- External API key
- Not required
- Operating systems
- Unspecified (assume cross-platform)
- Runtime requirements
- No special requirements
- Permissions
-
- Read-only
- Write / modify
- Network behavior
- Local-only
- Install commands
- 26 variants
Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.
Heads up: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skillshare-changelog
description: >- Generate a CHANGELOG.md entry for a release. $ARGUMENTS specifies the tag version (e.g., v0.1…
category: other
runtime: no special runtime
---
# skillshare-changelog output preview
## PART A: Task fit
- Use case: >- Generate a CHANGELOG.md entry for a release. $ARGUMENTS specifies the tag version (e.g., v0.16.0) or omit to auto-detect via git describe --tags --abbrev=0. LATEST_TAG=$(git describe --tags --abbrev=0) runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more..
- Inputs: target material, constraints, expected output, and acceptance criteria.
- Evidence boundary: follow “Workflow / Step 1: Determine Version Range / Step 2: Collect Commits” and do not present inference as author intent.
## PART B: Execution result
- **01** The card summarizes the use case; runtime output centers on “>- Generate a CHANGELOG.md entry for a release. $ARGUMENTS specifies the tag version (e.g., v0.16.0) or omit to auto-detect via git describe --tags --abbrev=0. LATEST_TAG=$(git describe --tags --abbrev=0) runs entirely locally. Works with Claude Code, Cursor, Cline and 23 more.”.
- **02** When the source has headings, the agent prioritizes “Workflow / Step 1: Determine Version Range / Step 2: Collect Commits” so the result follows the author’s structure.
- **03** Typical output includes task judgment, concrete steps, required commands or file edits, validation, and follow-up options.
- **04** Risk context follows the fingerprint: read files, write/modify files; mostly runs locally; usually needs no extra API key.
## Running Rules
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding scope.
- Return the result, validation criteria, and next iteration options. The source mentions slash commands such as `/release`; use them first when your agent supports command triggers.
Name target files or source material, expected output, forbidden changes, and whether network or shell access is allowed. Permission fingerprint: read files, write/modify files.
Start with a small task and check whether the result follows “Workflow / Step 1: Determine Version Range / Step 2: Collect Commits”. Inspect diffs, logs, previews, or tests before expanding scope.
Confirm the final output includes a concrete result, evidence, and next action. If it stays generic, tighten inputs, boundaries, and acceptance criteria.
---
name: skillshare-changelog
description: >- Generate a CHANGELOG.md entry for a release. $ARGUMENTS specifies the tag version (e.g., v0.1…
category: other
source: runkids/skillshare
---
# skillshare-changelog
## When to use
- >- Generate a CHANGELOG.md entry for a release. $ARGUMENTS specifies the tag version (e.g., v0.16.0) or omit to auto-d…
- Use it when the task has clear inputs, repeatable steps, and validation criteria.
## What to provide
- Target material, scope, expected result, and forbidden changes.
- Whether network, commands, file writes, or external services are allowed.
## Execution rules
- Organize steps around “Workflow / Step 1: Determine Version Range / Step 2: Collect Commits” and keep inference separate from source facts.
- read files, write/modify files; mostly runs locally; usually needs no extra API key.
- Validate with a small sample before expanding the task.
## Output requirements
- Return the deliverable, key evidence, validation method, and next action.
- Mark missing information as unknown; do not invent commands, platforms, or dependencies. The author source anchors workflow facts; repository files anchor sources and commands; Fluxly only adds fit, limitations, and quality judgment.
skill "skillshare-changelog" {
input -> user goal + target files + boundaries + acceptance criteria
context -> Workflow / Step 1: Determine Version Range / Step 2: Collect Commits
rules -> SKILL.md triggers / order / output contract
runtime -> no special runtime | read files, write/modify files | mostly runs locally
guardrails -> usually needs no extra API key + small-sample validation + diff/log review
output -> copyable result + checklist + next iteration
} Generate a CHANGELOG.md entry for a release. $ARGUMENTS specifies the tag version (e.g., v0.16.0) or omit to auto-detect via git describe --tags --abbrev=0.
Scope: This skill updates CHANGELOG.md and syncs the website changelog (website/src/pages/changelog.md). It does NOT generate RELEASE_NOTES, update version numbers, or handle the full release workflow — use /release for that.
Workflow
Step 1: Determine Version Range
# Auto-detect latest tag
LATEST_TAG=$(git describe --tags --abbrev=0)
# Find previous tag
PREV_TAG=$(git describe --tags --abbrev=0 "${LATEST_TAG}^")
echo "Generating changelog: $PREV_TAG → $LATEST_TAG"
Step 2: Collect Commits
git log "${PREV_TAG}..${LATEST_TAG}" --oneline --no-merges
Step 3: Categorize Changes
Group commits by conventional commit type:
| Prefix | Category |
|---|---|
feat |
New Features |
fix |
Bug Fixes |
refactor |
Refactoring |
docs |
Documentation |
perf |
Performance |
test |
Tests |
chore |
Maintenance |
Step 4: Read Existing Entries for Style Reference
Before writing, read the most recent 2-3 entries in CHANGELOG.md to match the established tone and structure. The style evolves over time — always match the latest entries, not a hardcoded template.
Step 5: Write User-Facing Entry
Write from the user's perspective. Only include changes users will notice or care about.
Include:
- New features with usage examples (CLI commands, code blocks)
- Bug fixes that affected user-visible behavior
- Breaking changes (renames, removed flags, scope changes)
- Performance improvements users would notice
Exclude:
- Internal test changes (smoke tests, test refactoring)
- Implementation details (error propagation, internal structs)
- Dev toolchain changes (Makefile cleanup, CI tweaks)
- Pure documentation adjustments
Wording guidelines:
- Don't use "first-class", "recommended" for non-default options
- Be factual: "Added X" / "Fixed Y" / "Renamed A to B"
- Include CLI example when introducing a new feature
- Use em-dash (
—) to separate feature name from description - Group related features under
####sub-headings when there are 2+ distinct areas
Step 6: Update CHANGELOG.md
Read existing CHANGELOG.md and insert new entry at the top, after the header. Match the style of the most recent entries exactly.
Structural conventions (based on actual entries):
## [X.Y.Z] - YYYY-MM-DD
### New Features
#### Feature Area Name
- **Feature name** — description with `inline code` for commands and flags
```bash
skillshare command --flag # usage example
Additional context as sub-bullets or continuation text
Another Feature Area
- Feature name — description
Bug Fixes
- Fixed specific user-visible behavior — with context on what changed
- Fixed another issue
Performance
- Improvement name — description of what got faster
Breaking Changes
- Renamed
old-nametonew-name
Key style points:
- Version numbers use `[X.Y.Z]` without `v` prefix in the heading
- Feature bullets use `**bold name** — em-dash description` format
- Code blocks use `bash` language tag for CLI examples
- Bug fixes describe the symptom, not the implementation
- Only include sections that have content (skip empty Performance, Breaking Changes, etc.)
### Step 7: Sync Website Changelog
The website has its own changelog page at `website/src/pages/changelog.md`. After updating `CHANGELOG.md`, sync the new entry to the website version.
**Differences between the two files**:
- Website file has MDX frontmatter (`title`, `description`) and an intro paragraph — preserve these, don't overwrite
- Website file has a `---` separator after the intro, before the first version entry
- The release entries themselves are identical in content
**How to sync**: Read the website changelog, then insert the same new entry after the `---` separator (line after intro paragraph), before the first existing version entry. Do NOT replace the entire file — only insert the new entry block.
## Rules
- **User perspective** — write for users, not developers
- **No fabricated links** — never invent URLs or references
- **Verify features exist** — grep source before claiming a feature was added
- **No internal noise** — exclude test-only, CI-only, or refactor-only changes
- **Conventional format** — follow existing CHANGELOG.md style exactly
- **Always sync both** — `CHANGELOG.md` and `website/src/pages/changelog.md` must have identical release entries
Decide Fit First
Design Intent
How To Use It
Boundaries And Review