pflow-changelog

If changelog-context.sh or changelog-commit-push.sh fails (non-zero exit or an error field in its JSON) print ⚠️ <error.message> and stop.

Steps

Get context: .agents/skills/pflow-changelog/scripts/changelog-context.sh. It returns JSON {feature:{title,version}, tasks:[…], commits:"…"} or {error:{…}}.
Analyze the context (tasks + commit messages). Summarize what was done in product terms — no tech internals, no process/dev meta. Then compose a changelog entry using the format below and prepend it to the existing CHANGELOG.md (create the file if absent, starting with the standard header: # Changelog\n\nAll notable changes to this project will be documented in this file.).
Commit and push: .agents/skills/pflow-changelog/scripts/changelog-commit-push.sh. It prints {commit_hash, branch_name, push_status} or {…, error:{…}}. If error is present, print ⚠️ <error.message> and stop.

Reply exactly:

✅ Changelog updated for <feature_title> (<feature_version>).

Changelog format (Keep a Changelog)

Each version entry follows this structure:

## [<version>] - YYYY-MM-DD

### Added
- for new features.

### Changed
- for changes in existing functionality.

### Deprecated
- for soon-to-be removed features.

### Removed
- for now-removed features.

### Fixed
- for any bug fixes.

### Security
- in case of vulnerabilities.

Rules:

Use today's date (ISO 8601: YYYY-MM-DD).
Omit empty sections (e.g., skip ### Deprecated if nothing was deprecated).
Group changes under the most fitting category. Prefer ### Added / ### Changed / ### Fixed.
One bullet per notable change, concise, user-facing.
The changelog is for people, not machines. Focus on what changed and why from the user's perspective.

About this skill

Steps

Changelog format (Keep a Changelog)