Run any Skill in Manus with one click

changelog

Stars359

Forks98

UpdatedJune 21, 2026 at 19:15

Style rules for updating CHANGELOG.md entries. Use whenever the user asks to update, add to, or write entries in CHANGELOG.md.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

hardisgroupcom

hardisgroupcom/sfdx-hardis

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	changelog
description	Style rules for updating CHANGELOG.md entries. Use whenever the user asks to update, add to, or write entries in CHANGELOG.md.
user-invocable	false

CHANGELOG Style

CHANGELOG.md entries are read by end users (Salesforce admins, devs, ops) deciding whether to upgrade. They are not internal dev notes.

Rules

Stay concise. One short bullet per change. One sentence is the target. No paragraphs.
Write for end users, not developers. Describe the user-visible behavior or capability, not the implementation.
- YES: "More engaging intro on the generated documentation home page."
- NO: "The welcomeToDocumentation i18n key now teases what is browsable..."
- NO: "Translated to all 9 locales (de, en, es, fr, it, ja, nl, pl, pt-BR)." (mention only if it is the change itself, e.g. "Added German translations")
Skip implementation details unless they directly affect the user: file paths, function names, i18n keys, internal flags, refactor mechanics.
Link the command when the entry applies to a specific command, using the standard format [hardis:topic:action](https://sfdx-hardis.cloudity.com/hardis/topic/action/).
Always group updates by command. A command must appear at most once in a section. If it already has an entry (or you are adding several changes to the same command), write the command link once and put each change as a nested bullet under it - never repeat the same command link on multiple top-level lines. A single change stays on one line: [command](url): <change>.
Add entries under ## [beta] (main) at the top of the file. Do not create version sections - releases set those.

Pattern

Single change for a command:

- [hardis:topic:action](https://sfdx-hardis.cloudity.com/hardis/topic/action/): <one short sentence about user-visible change>.
- <Site / generic change>: <one short sentence>.

Multiple changes for the same command - group them under one command link:

- [hardis:topic:action](https://sfdx-hardis.cloudity.com/hardis/topic/action/):
  - <one short sentence about the first user-visible change>.
  - <one short sentence about the second user-visible change>.

Each nested bullet must be end-user relevant (a new flag, a new channel, a new default, a fixed behavior). Never use sub-bullets to list affected files or locales.

More from this repository

same repository

uxlog-usage

hardisgroupcom/sfdx-hardis

How to pick the correct uxLog level (action, log, warning, error, success, other), the matching chalk color, the options object (sensitive, alwaysVisible), VS Code UI suppression, and uxLogTable. Use when adding or modifying any uxLog call.

2026-07-07359

analyze

hardisgroupcom/sfdx-hardis

Gather requirements by asking clarifying questions until the problem is fully understood. First step of the contribution workflow.

2026-06-14359

design

hardisgroupcom/sfdx-hardis

Design the solution and write a technical specification based on requirements analysis. Second step of the contribution workflow, use after /analyze.

2026-06-13359

fix-security-issue

hardisgroupcom/sfdx-hardis

Handle CVE/vulnerability reports from security linters (trivy, osv-scanner, etc.). Tries to upgrade first; ignores only when safe and justified.

2026-06-13359

implement

hardisgroupcom/sfdx-hardis

Implement a feature, bug fix, or code change in sfdx-hardis. Use whenever the user asks to add a feature, fix a bug, implement something, or make a code change - with or without a prior /design phase.

2026-06-13359

pr-watch-fix

hardisgroupcom/sfdx-hardis

Watch the GitHub PR for the current branch, wait for CI to finish, and autonomously fix failing jobs by reading logs, editing sources, and pushing. Stops cleanly when stuck.

2026-06-13359

CHANGELOG Style

CHANGELOG.md entries are read by end users (Salesforce admins, devs, ops) deciding whether to upgrade. They are not internal dev notes.

Rules

Stay concise. One short bullet per change. One sentence is the target. No paragraphs.

Write for end users, not developers. Describe the user-visible behavior or capability, not the implementation.

YES: "More engaging intro on the generated documentation home page."
NO: "The welcomeToDocumentation i18n key now teases what is browsable..."
NO: "Translated to all 9 locales (de, en, es, fr, it, ja, nl, pl, pt-BR)." (mention only if it is the change itself, e.g. "Added German translations")

Skip implementation details unless they directly affect the user: file paths, function names, i18n keys, internal flags, refactor mechanics.

Link the command when the entry applies to a specific command, using the standard format [hardis:topic:action](https://sfdx-hardis.cloudity.com/hardis/topic/action/).

Always group updates by command. A command must appear at most once in a section. If it already has an entry (or you are adding several changes to the same command), write the command link once and put each change as a nested bullet under it - never repeat the same command link on multiple top-level lines. A single change stays on one line: [command](url): <change>.

Add entries under ## [beta] (main) at the top of the file. Do not create version sections - releases set those.

Pattern

Single change for a command:

- [hardis:topic:action](https://sfdx-hardis.cloudity.com/hardis/topic/action/): <one short sentence about user-visible change>. - <Site / generic change>: <one short sentence>.

Multiple changes for the same command - group them under one command link:

- [hardis:topic:action](https://sfdx-hardis.cloudity.com/hardis/topic/action/): - <one short sentence about the first user-visible change>. - <one short sentence about the second user-visible change>.

Each nested bullet must be end-user relevant (a new flag, a new channel, a new default, a fixed behavior). Never use sub-bullets to list affected files or locales.