How do I install the Jj Changelog skill?

Run npx skillmds@latest add majiayu000/jj-changelog in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Jj Changelog safe to use?

This skill has not completed SkillMD's automated safety review yet. Independent scanners report: SkillSpector: PASS, Skill Scanner: PASS. Capability flags: docs only. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Jj Changelog?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Jj Changelog free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Jj Changelog?

majiayu000 (@majiayu000) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Jj Changelog by majiayu000 — Agent Skill

Name: Jj Changelog
Rating: 4.2 (5 reviews)
Author: majiayu000

Jj Changelog

Proactively use to generate or update a CHANGELOG.md file from Jujutsu commit history. Use when you need to create release notes, document changes between tags, or update the project changelog. Emphasizes breaking changes, new features, and user-facing bug fixes.

majiayu000 Updated Sep 9, 2026 567 repo stars

File contents

Jujutsu Changelog Generator

Generate or update a CHANGELOG.md file from Jujutsu history, emphasizing user-facing changes.

Standard Operating Procedure

Gather commit history using the changes.sh script in this directory:
```
./changes.sh
```

Categorize each commit based on its description using conventional commit prefixes or semantic analysis:

Category	Prefixes/Keywords	Emphasis
Breaking Changes	`BREAKING:`, `!:`, `breaking change`	HIGH - Always at top
New Features	`feat:`, `feature:`, `add:`	HIGH - User-facing
Bug Fixes (User)	`fix:` affecting user-facing behavior	MEDIUM
Performance	`perf:`	MEDIUM - If user-visible
Bug Fixes (Internal)	`fix:` for internal/dev issues	LOW
Refactoring	`refactor:`	LOW
Documentation	`docs:`	LOW
Tests	`test:`	LOW
Chores	`chore:`, `ci:`, `build:`	LOW

Format the CHANGELOG.md with this structure:

# Changelog

All notable changes to this project are documented in this file.

## [version/tag] - YYYY-MM-DD

### Breaking Changes

- **BREAKING**: Detailed/full description of breaking change
  - Detailed/full migration steps if applicable

### New Features

- **Feature**: Description of new feature

### Bug Fixes

- **Fix**: Description of user-facing bug fix

### Other Changes

<details>
<summary>Internal improvements and maintenance</summary>

- Refactored X for better maintainability
- Fixed internal issue with Y
- Updated dependencies

</details>

Formatting rules:
- Breaking changes MUST be at the top of each version section
- Breaking changes MUST include migration guidance when possible
- User-facing features and fixes get full descriptions
- Internal changes go in a collapsible <details> section
- Empty sections should be omitted
- Use imperative mood ("Add feature" not "Added feature")
- Link to issues/PRs if referenced in commit messages
Write the changelog:
- If CHANGELOG.md exists, update it (prepend new versions)
- If it doesn't exist, create it
- Preserve any manual edits in existing entries

Example Output

# Changelog

## [v2.1.0] - 2024-12-01

### Breaking Changes

- **BREAKING**: Removed deprecated `legacy_api()` function
  - Migrate to `new_api()` which provides the same functionality

### New Features

- **Feature**: Add support for custom output formats
- **Feature**: New `--verbose` flag for detailed logging

### Bug Fixes

- **Fix**: Resolve crash when input file is empty
- **Fix**: Correct timezone handling in date parsing

### Other Changes

<details>
<summary>Internal improvements and maintenance</summary>

- Refactored configuration loading for clarity
- Fixed flaky test in CI pipeline
- Updated pytest to 8.0

</details>

## [v2.0.0] - 2024-11-15

...

Notes

If commits don't follow conventional commits, use best judgment to categorize
When uncertain if a change is user-facing, err on the side of including it in the main sections
Commits with empty descriptions should be skipped
Multiple commits can be consolidated if they address the same feature/fix

---name: jj-changelogdescription: Proactively use to generate or update a CHANGELOG.md file from Jujutsu commit history. Use when you need to create release notes, document changes between tags, or update the project changelog. Emphasizes breaking changes, new features, and user-facing bug fixes.--- # Jujutsu Changelog Generator Generate or update a CHANGELOG.md file from Jujutsu history, emphasizing user-facing changes. ## Standard Operating Procedure 1. **Gather commit history** using the `changes.sh` script in this directory: ```bash ./changes.sh ``` 2. **Categorize each commit** based on its description using conventional commit prefixes or semantic analysis: | Category | Prefixes/Keywords | Emphasis | |----------|-------------------|----------| | Breaking Changes | `BREAKING:`, `!:`, `breaking change` | **HIGH** - Always at top | | New Features | `feat:`, `feature:`, `add:` | **HIGH** - User-facing | | Bug Fixes (User) | `fix:` affecting user-facing behavior | **MEDIUM** | | Performance | `perf:` | **MEDIUM** - If user-visible | | Bug Fixes (Internal) | `fix:` for internal/dev issues | LOW | | Refactoring | `refactor:` | LOW | | Documentation | `docs:` | LOW | | Tests | `test:` | LOW | | Chores | `chore:`, `ci:`, `build:` | LOW | 3. **Format the CHANGELOG.md** with this structure: ```markdown # Changelog All notable changes to this project are documented in this file. ## [version/tag] - YYYY-MM-DD ### Breaking Changes - **BREAKING**: Detailed/full description of breaking change - Detailed/full migration steps if applicable ### New Features - **Feature**: Description of new feature ### Bug Fixes - **Fix**: Description of user-facing bug fix ### Other Changes <details> <summary>Internal improvements and maintenance</summary> - Refactored X for better maintainability - Fixed internal issue with Y - Updated dependencies </details> ``` 4. **Formatting rules**: - Breaking changes MUST be at the top of each version section - Breaking changes MUST include migration guidance when possible - User-facing features and fixes get full descriptions - Internal changes go in a collapsible `<details>` section - Empty sections should be omitted - Use imperative mood ("Add feature" not "Added feature") - Link to issues/PRs if referenced in commit messages 5. **Write the changelog**: - If CHANGELOG.md exists, update it (prepend new versions) - If it doesn't exist, create it - Preserve any manual edits in existing entries ## Example Output ```markdown # Changelog ## [v2.1.0] - 2024-12-01 ### Breaking Changes - **BREAKING**: Removed deprecated `legacy_api()` function - Migrate to `new_api()` which provides the same functionality ### New Features - **Feature**: Add support for custom output formats - **Feature**: New `--verbose` flag for detailed logging ### Bug Fixes - **Fix**: Resolve crash when input file is empty - **Fix**: Correct timezone handling in date parsing ### Other Changes <details> <summary>Internal improvements and maintenance</summary> - Refactored configuration loading for clarity - Fixed flaky test in CI pipeline - Updated pytest to 8.0 </details> ## [v2.0.0] - 2024-11-15 ... ``` ## Notes - If commits don't follow conventional commits, use best judgment to categorize - When uncertain if a change is user-facing, err on the side of including it in the main sections - Commits with empty descriptions should be skipped - Multiple commits can be consolidated if they address the same feature/fix

Frequently asked questions