Changelog

Skill tuliosousapro/SaaS-blueprint/skills/changelog

BRAINIAC - SaaS Blueprint, NOT an APP. It's a comprehensive playbook and operating system designed for building, launching, and scaling a SaaS APP covering from MVP to Mass Scale. It is structured as a chronological and functional roadmap, containing over 80 specialized directories, each with its own PLAYBOOK.md.

Install

npx -y skills add tuliosousapro/SaaS-blueprint --skill changelog

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Generates and maintains changelogs following Keep a Changelog format. Use when updating release notes, finishing tasks, or tagging versions. For version bumps, see semantic-versioning.

SKILL.md

2.6 KB, as published. Nobody here has run it

Changelog Skill

When to Use

After completing a sprint or shipping a feature.
Before tagging a release or pushing to main.
When the user asks "what changed?" or "update the changelog".

Reference

Keep a Changelog v1.1.0

Instructions

1. Locate or Create CHANGELOG.md

Check project root for CHANGELOG.md.
If missing, create it with the header:

# Changelog

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

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

## [Unreleased]

2. Gather Changes

Scan recent work using:

git log --oneline since last tagged version.
tasks/todo.md completed items.
User description of what was shipped.

3. Categorize Changes

Every change goes into exactly one category:

Category	When to Use
Added	New features, new files, new capabilities
Changed	Modifications to existing functionality
Deprecated	Features that will be removed in future versions
Removed	Features that were removed
Fixed	Bug fixes
Security	Vulnerability patches

4. Determine New Version

Automatically invoke the semantic-versioning skill.
Use the categorized changes to determine if the next version should be Major, Minor, or Patch.
Ensure the version is updated in both CHANGELOG.md and .github/repository-metadata.json.

5. Write Entry

## [X.Y.Z] - YYYY-MM-DD

### Added
- Brief description of what was added

### Changed
- Brief description of what changed

### Fixed
- Brief description of what was fixed

6. Rules

Most recent version at the top.
Always include the date in ISO format (YYYY-MM-DD).
One line per change, starting with a verb.
Group related changes under the same category.
Keep an [Unreleased] section at the top for ongoing work.
Never delete old entries.
Synchronization: Always ensure the version number matches between CHANGELOG.md and .github/repository-metadata.json.

Quality Gates

Every entry has a date.
No empty categories (remove the heading if nothing to list).
Entries are human-readable (not git commit hashes).
Version Integrity: The new version strictly follows SemVer logic and is synchronized across the workspace.