Is project-change-log safe to install?

SaferSkills independently audited project-change-log (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.

CategoryWeightCategory scoreContribution

Securityprompt, exec, net, exfil, eval

35%

100

35.0 pts

Supply chainhash, typosquat, maintainer, lockfile

20%

100

20.0 pts

Maintenancestaleness, pinning, CI

15%

100

15.0 pts

TransparencySKILL.md, perms, README

15%

100

15.0 pts

Communityinstalls, verify, response

15%

100

15.0 pts

Findings & checks · 0 flagged

Securityscore 100 · 0 findings

✓—All security checks passedNo findings in this category for the latest scan.pass

Supply chainscore 100 · 0 findings

✓—All supply chain checks passedNo findings in this category for the latest scan.pass

Maintenancescore 100 · 0 findings

✓—All maintenance checks passedNo findings in this category for the latest scan.pass

Transparencyscore 100 · 0 findings

✓—All transparency checks passedNo findings in this category for the latest scan.pass

Communityscore 100 · 0 findings

✓—All community checks passedNo findings in this category for the latest scan.pass

The primary manifest — the file an agent reads to learn what this artifact does.

.claude/skills/project-change-log/SKILL.md · 1 file

.claude/skills/project-change-log/SKILL.md3.9 KB · Markdown

Project Change Log

Automatically maintain a CHANGELOG.md file following the Keep a Changelog standard.

When to Use

After creating a commit
When /commit command is executed
When user asks to update changelog
When releasing a new version

Changelog Format

The standard format is CHANGELOG.md in the project root, following Keep a Changelog:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/),
and this project adheres to [Semantic Versioning](https://semver.org/).

## [Unreleased]

### Added
- New feature description

### Changed
- Change description

### Fixed
- Bug fix description

## [1.0.0] - 2026-01-04

### Added
- Initial release features

Change Categories

Category	Description
Added	New features
Changed	Changes in existing functionality
Deprecated	Soon-to-be removed features
Removed	Removed features
Fixed	Bug fixes
Security	Vulnerability fixes

Process

1. Detect Changelog

Check if CHANGELOG.md exists in project root:

If exists: Read current content
If not: Create with template

2. Analyze Commit

Extract from the commit:

Type: feat, fix, docs, etc.
Scope: Affected area
Description: What changed
Date: Current date (YYYY-MM-DD)
Author: From git config

3. Map Commit Type to Category

Commit Type	Changelog Category
`feat`	Added
`fix`	Fixed
`docs`	Changed
`style`	Changed
`refactor`	Changed
`perf`	Changed
`test`	Changed
`build`	Changed
`ci`	Changed
`chore`	Changed
`security`	Security
`deprecate`	Deprecated
`remove`	Removed

4. Update Changelog

Add entry under [Unreleased] section in appropriate category:

## [Unreleased]

### Added
- New entry here with description

5. Version Release

When releasing a version:

Move [Unreleased] content to new version section
Add version number and date
Create new empty [Unreleased] section

Entry Format

Each entry should be:

One line per change
Start with capital letter
No period at end
Include scope if relevant: **scope**: description

Examples:

### Added
- **auth**: OAuth2 login with Google and GitHub
- User profile settings page
- Dark mode toggle

### Fixed
- **api**: Handle null response in user endpoint
- Memory leak in websocket connections

Template

Initial CHANGELOG.md template:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/),
and this project adheres to [Semantic Versioning](https://semver.org/).

## [Unreleased]

### Added

### Changed

### Fixed

Integration with Commit

After each commit:

Parse commit message for type and description
Determine changelog category
Add entry under [Unreleased]
Stage CHANGELOG.md (do not create separate commit)

Examples

Example 1: Feature Commit

Commit: feat(auth): add OAuth2 login support

Changelog Entry:

### Added
- **auth**: OAuth2 login support

Example 2: Bug Fix

Commit: fix(api): handle null response in user endpoint

Changelog Entry:

### Fixed
- **api**: Handle null response in user endpoint

Example 3: Version Release

Before:

## [Unreleased]

### Added
- Feature A
- Feature B

### Fixed
- Bug fix X

After releasing v1.2.0:

## [Unreleased]

## [1.2.0] - 2026-01-04

### Added
- Feature A
- Feature B

### Fixed
- Bug fix X

project-change-log— agent skill

Is project-change-log safe to install?

Project Change Log

When to Use

Changelog Format

Change Categories

Process

1. Detect Changelog

2. Analyze Commit

3. Map Commit Type to Category

4. Update Changelog

5. Version Release

Entry Format

Template

Integration with Commit

Examples

Example 1: Feature Commit

Example 2: Bug Fix

Example 3: Version Release

Audit the pieces. Scan the whole. Decide.