Writing Guidelines
rohitg00/pro-workflow
Apply clear-writing standards to any prose the agent produces - READMEs, docs, UI copy, error messages, commit and PR text, release notes.
Style rules for adding CHANGELOG.md entries: short, user-facing bullets grouped by command under the beta section, each linking the command's docs page.
Install Changelog Style Rules
$ npx skills add hardisgroupcom/sfdx-hardis --skill changelog -a claude-codeProject install by default; add -g for ~/.claude/skills/.
$ gh skill install hardisgroupcom/sfdx-hardis changelog --agent claude-codeProject scope by default; add --scope user for a personal install. Needs GitHub CLI 2.90.0 or later (public preview).
$ git clone --depth 1 https://github.com/hardisgroupcom/sfdx-hardis.git skills-src && mkdir -p .claude/skills && cp -r skills-src/.claude/skills/changelog .claude/skills/changelog && rm -rf skills-srcUse ~/.claude/skills/ instead of .claude/skills for a personal install. The folder must contain SKILL.md.
Claude Code skills documentation · loads skills from .claude/skills/
Install the "changelog" agent skill from https://github.com/hardisgroupcom/sfdx-hardis/tree/main/.claude/skills/changelog into .claude/skills/changelog/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "changelog", then confirm the skill loads.Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$skill-installer install https://github.com/hardisgroupcom/sfdx-hardis/tree/main/.claude/skills/changelogType this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
$ npx skills add hardisgroupcom/sfdx-hardis --skill changelog -a codexProject install goes to .agents/skills/; add -g for ~/.codex/skills/.
$ gh skill install hardisgroupcom/sfdx-hardis changelog --agent codexProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/hardisgroupcom/sfdx-hardis.git skills-src && mkdir -p .agents/skills && cp -r skills-src/.claude/skills/changelog .agents/skills/changelog && rm -rf skills-srcUse ~/.agents/skills/ instead of .agents/skills for a personal install.
Codex skills documentation · loads skills from .agents/skills/
Install the "changelog" agent skill from https://github.com/hardisgroupcom/sfdx-hardis/tree/main/.claude/skills/changelog into .agents/skills/changelog/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "changelog", then confirm the skill loads.Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add hardisgroupcom/sfdx-hardis --skill changelog -a cursorProject install goes to .agents/skills/; add -g for ~/.cursor/skills/.
$ gh skill install hardisgroupcom/sfdx-hardis changelog --agent cursorProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/hardisgroupcom/sfdx-hardis.git skills-src && mkdir -p .cursor/skills && cp -r skills-src/.claude/skills/changelog .cursor/skills/changelog && rm -rf skills-srcUse ~/.cursor/skills/ instead of .cursor/skills for a personal install.
Cursor skills documentation · loads skills from .cursor/skills/, .agents/skills/, .claude/skills/, .codex/skills/
Install the "changelog" agent skill from https://github.com/hardisgroupcom/sfdx-hardis/tree/main/.claude/skills/changelog into .cursor/skills/changelog/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "changelog", then confirm the skill loads.Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gemini skills install https://github.com/hardisgroupcom/sfdx-hardis.git --path .claude/skills/changelog--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
$ npx skills add hardisgroupcom/sfdx-hardis --skill changelog -a gemini-cliProject install goes to .agents/skills/; add -g for ~/.gemini/skills/.
$ gh skill install hardisgroupcom/sfdx-hardis changelog --agent gemini-cliProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/hardisgroupcom/sfdx-hardis.git skills-src && mkdir -p .gemini/skills && cp -r skills-src/.claude/skills/changelog .gemini/skills/changelog && rm -rf skills-srcUse ~/.gemini/skills/ instead of .gemini/skills for a personal install, then run /skills reload.
Gemini CLI skills documentation · loads skills from .gemini/skills/, .agents/skills/
Install the "changelog" agent skill from https://github.com/hardisgroupcom/sfdx-hardis/tree/main/.claude/skills/changelog into .gemini/skills/changelog/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "changelog", then confirm the skill loads.Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ gh skill install hardisgroupcom/sfdx-hardis changelogInstalls for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
$ npx skills add hardisgroupcom/sfdx-hardis --skill changelog -a github-copilotProject install goes to .agents/skills/; add -g for ~/.copilot/skills/.
$ git clone --depth 1 https://github.com/hardisgroupcom/sfdx-hardis.git skills-src && mkdir -p .github/skills && cp -r skills-src/.claude/skills/changelog .github/skills/changelog && rm -rf skills-srcUse ~/.copilot/skills/ instead of .github/skills for a personal install. Commit .github/skills so cloud agent and code review can use it.
GitHub Copilot skills documentation · loads skills from .github/skills/, .claude/skills/, .agents/skills/
Install the "changelog" agent skill from https://github.com/hardisgroupcom/sfdx-hardis/tree/main/.claude/skills/changelog into .github/skills/changelog/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "changelog", then confirm the skill loads.GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
$ npx skills add hardisgroupcom/sfdx-hardis --skill changelog -a opencodeOpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
$ gh skill install hardisgroupcom/sfdx-hardis changelog --agent opencodeProject scope by default (.agents/skills/); add --scope user for a personal install.
$ git clone --depth 1 https://github.com/hardisgroupcom/sfdx-hardis.git skills-src && mkdir -p .opencode/skills && cp -r skills-src/.claude/skills/changelog .opencode/skills/changelog && rm -rf skills-srcUse ~/.config/opencode/skills/ instead of .opencode/skills for a personal install.
OpenCode skills documentation · loads skills from .opencode/skills/, .claude/skills/, .agents/skills/
Install the "changelog" agent skill from https://github.com/hardisgroupcom/sfdx-hardis/tree/main/.claude/skills/changelog into .opencode/skills/changelog/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "changelog", then confirm the skill loads.OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
- Skill name
changelog- GitHub stars
- 402
- Token cost
- ~1.4k tokens
- SKILL.md length
- 696 words
- Files
- 1
- Skills in repo
- 21
- Repo updated
- First seen
- Licence
- AGPL-3.0
At a glance
Style rules for adding CHANGELOG.md entries: short, user-facing bullets grouped by command under the beta section, each linking the command's docs page.
- Adding an entry to CHANGELOG.md for a new feature
- SKILL.md covers Rules, Pattern and Keep the Pull Request…
- Calls gh; reaches sfdx-hardis.cloudity.com
- Rewriting a developer-style changelog line for end users
What it does
Entries are read by end users such as Salesforce admins, developers and ops people deciding whether to upgrade, so they are not internal dev notes. The rules say to keep each change to one short bullet, ideally one sentence, to describe visible behavior rather than implementation, and to leave out file paths, function names, i18n keys, internal flags and refactor mechanics unless the user is directly affected.
An entry that applies to a command links it in the standard doc-link format. Updates are grouped by command: a command appears at most once per section, with nested bullets when it has several changes, and a feature that spans several commands gets one top-level bullet with its own doc link. Grouping uses bullets, never new headers. New entries go under the top beta section, and version sections are left to releases. The excerpt is cut off after these rules.
When your agent uses it
- Adding an entry to CHANGELOG.md for a new feature
- Rewriting a developer-style changelog line for end users
- Grouping several changes to one command under a single bullet
Example prompts
- “Add a changelog entry for the new option on the backup command.”
- “Rewrite this changelog line so it describes behavior users can see.”
- “Merge my three new entries for the same command into one bullet with nested changes.”
What it can do on your machine
Read from SKILL.md and the folder at commit 33d4de0. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
gh
From the folder's file list and the shell code blocks in SKILL.md.
Network
Hosts in commands or code, which the agent is likely to contact:
sfdx-hardis.cloudity.com
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Changelog Style Rules loads about 1.4k tokens when it runs. Until then it costs about 34 tokens; SKILL.md has 696 words of instructions outside code blocks.
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
SKILL.md
The full file from hardisgroupcom/sfdx-hardis at commit 33d4de0, republished under its AGPL-3.0 licence (© hardisgroupcom). 696 words, ~1,351 tokens.
Download SKILL.mdSave it as
.claude/skills/changelog/SKILL.md (or your agent's skills folder).- 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
welcomeToDocumentationi18n 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>. - The same goes for a feature. Changes to one feature that spans several commands (promotion branches, backpromote, monitoring, the VS Code DevOps Pipeline...) share one top-level bullet with the feature's doc link, and each change is a nested bullet that links the command it touches. Before adding an entry, read the whole beta section: if its command or its feature already has a line, add to that line (turning it into a group if needed) instead of writing a new one.
- Group with bullets, never with a header. The command link is a top-level bullet and its changes are nested bullets under it. Never open a
###(or any other) header for a command, however many changes it has. - Add entries under
## [beta] (main)at the top of the file. Do not create version sections - releases set those. - Sibling repositories have their own changelog, and a change made there from here updates it.
../vscode-sfdx-hardis/CHANGELOG.mdtakes its entries under## Unreleased.../sfdx-hardis-training/CHANGELOG.mdhas no versions and no## Unreleased: an entry goes under the## YYYY-MM-DDheading of the day it is written, and when that heading does not exist yet, it is added at the top. Always in the Pull Request of that repository, with the same style rules.
Show full SKILL.md (291 more words)Show less
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>.Several changes to the same feature, across its commands:
- [Promotion branches](https://sfdx-hardis.cloudity.com/salesforce-devops-promotion-branches/) (Beta):
- New `someProperty` property: <what it lets the user do>.
- [hardis:project:promotion:create](https://sfdx-hardis.cloudity.com/hardis/project/promotion/create/): <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.
Never do this, even when a command has many changes:
### [hardis:topic:action](https://sfdx-hardis.cloudity.com/hardis/topic/action/)
- <change>.
- <change>.Keep the Pull Request description in sync
A CHANGELOG entry is rarely the only thing a change owes its readers. Whenever you add work to a Pull Request that is already open, update its description in the same pass:
- The description must describe what the PR contains now, not what it contained when it was opened. A reviewer reads the description first, and a stale one sends them looking for things that moved or are no longer there.
- Do it as part of finishing the work, not as a follow-up: a PR whose scope grew silently is the one that gets reviewed against the wrong expectations.
- Mention what changed and, when a decision was made during the work (a default that flipped, an option that was dropped, a finding that turned out to be wrong), say so. Those are what a reviewer needs and cannot see from the diff.
- Always edit the description with the REST API, never
gh pr edit:gh api -X PATCH repos/<owner>/<repo>/pulls/<number> -F body=@<file.md>gh pr editfails with aprojectCardsGraphQL error on repositories that still have Projects (classic), and it fails silently enough to look like it worked: it prints the error but leaves the description untouched. Write the body to a file and PATCH it.
The same applies to the PR title when the scope no longer matches it.
© hardisgroupcom, AGPL-3.0. Rendered from Markdown: HTML in the file is shown as text, images as links, and headings moved down two levels. Raw file
Files
Just SKILL.md in .claude/skills/changelog of hardisgroupcom/sfdx-hardis.
Open the folder on GitHubat commit 33d4de0
Compare with similar skills
Changelog Style Rules next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
| Skill | Stars | Used in | Tokens | Auto-check | Licence | Repo updated |
|---|---|---|---|---|---|---|
| Changelog Style Rules this skillhardisgroupcom/sfdx-hardis | 402 | — | ~1.4k | Automated safety check: Pass | AGPL-3.0 | |
| Writing Guidelinesrohitg00/pro-workflow | 2.9k | — | ~593 | Automated safety check: Pass | None | |
| Simple Englishropensci/ckanr | 104 | 3 repos | ~2k | Automated safety check: Pass | MIT | |
| Changelog Entrycertinia/debug-log-analyzer | 114 | — | ~1.9k | Automated safety check: Pass | Custom licence | |
| Plain EnglishFallout-build/Fallout | 167 | — | ~2k | Automated safety check: Pass | Custom licence | |
| Nbj Write Clearlydaniel-p-green/nbj-write-clearly | 117 | — | ~1.1k | Automated safety check: Pass | MIT |
Similar skills
Simple English
ropensci/ckanr
Write or rewrite text in plain, layman-readable English in the spirit of ASD-STE100 Simplified Technical English: short sentences, active voice, simple tenses, one word one meaning, condition before…
Changelog Entry
certinia/debug-log-analyzer
Write, review or trim CHANGELOG.md entries. An agent skill from certinia/debug-log-analyzer.
Plain English
Fallout-build/Fallout
Write clear, plain English for developer-facing prose aimed at an international audience.
Nbj Write Clearly
daniel-p-green/nbj-write-clearly
Drafts, revises, and audits reader-first technical and product documentation.
Technical Writing
citypaul/.dotfiles
Writing developer-facing prose that can be skimmed first and trusted enough to finish — READMEs, guides, tutorials, reference docs, proposals, PR descriptions, release notes.
More from hardisgroupcom/sfdx-hardis
All 21 skills in this reposfdx-hardis Training End-to-End Test
hardisgroupcom/sfdx-hardis
Walks the sfdx-hardis training course end to end as a learner would, against a real Developer Edition org and fork, fixing broken steps and screenshots that no longer match.
Promotion Branches E2E Test
hardisgroupcom/sfdx-hardis
Runs a full end-to-end test of sfdx-hardis promotion branches and backpromote against real Salesforce orgs and a throwaway repository, then writes a report.
sfdx-hardis Architecture Guide
hardisgroupcom/sfdx-hardis
Explains how the sfdx-hardis Salesforce CLI plugin is built: its TypeScript and Oclif stack, command layout, agent-mode flag and provider classes for git, notifications and AI.
Documentation
hardisgroupcom/sfdx-hardis
Documentation standards for sfdx-hardis commands (description format with Command Behavior and Technical explanations sections, MkDocs site, build:doc).
Fix Jscpd
hardisgroupcom/sfdx-hardis
Decision framework for fixing jscpd (copy-paste detector) errors.
I18n Usage
hardisgroupcom/sfdx-hardis
Code examples and patterns for using i18n translations in sfdx-hardis source code (uxLog, uxLogTable, prompts, markers).
Related
Works with
Categories
Questions about Changelog Style Rules
What does Changelog Style Rules do?
Style rules for adding CHANGELOG.md entries: short, user-facing bullets grouped by command under the beta section, each linking the command's docs page. Entries are read by end users such as Salesforce admins, developers and ops people deciding whether to upgrade, so they are not internal dev notes. The rules say to keep each change to one short bullet, ideally one sentence, to describe visible behavior rather than implementation, and to leave out file paths, function names, i18n keys, internal flags and refactor mechanics unless the user is directly affected.
When should I use Changelog Style Rules?
Changelog Style Rules fits situations like: adding an entry to CHANGELOG.md for a new feature; rewriting a developer-style changelog line for end users; grouping several changes to one command under a single bullet.
How do I install Changelog Style Rules in Claude Code?
Run `npx skills add hardisgroupcom/sfdx-hardis --skill changelog -a claude-code`. Or copy the skill folder (.claude/skills/changelog in hardisgroupcom/sfdx-hardis) into .claude/skills/changelog in your project. Claude Code loads it when a task matches its description.
How do I install Changelog Style Rules in Codex?
Run `npx skills add hardisgroupcom/sfdx-hardis --skill changelog -a codex`. Or copy the skill folder (.claude/skills/changelog in hardisgroupcom/sfdx-hardis) into .agents/skills/changelog in your project. Codex loads it when a task matches its description.
Can I use Changelog Style Rules in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add hardisgroupcom/sfdx-hardis --skill changelog -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/changelog, .gemini/skills/changelog, .github/skills/changelog and .opencode/skills/changelog in your project.
What does Changelog Style Rules need to run?
Going by SKILL.md and its folder, Changelog Style Rules needs the command-line tools its instructions call (gh).
Does Changelog Style Rules access the network?
SKILL.md names 1 domain. In commands or code: sfdx-hardis.cloudity.com; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.
Is Changelog Style Rules safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Changelog Style Rules use?
Changelog Style Rules is published under the AGPL-3.0 licence (the repository's licence). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Changelog Style Rules use?
About 1.4k tokens (SKILL.md is roughly 5.4k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full.
What are the alternatives to Changelog Style Rules?
Skills that share tags, products or a category with Changelog Style Rules: Writing Guidelines (rohitg00/pro-workflow, 2.9k stars), Simple English (ropensci/ckanr, 104 stars), Changelog Entry (certinia/debug-log-analyzer, 114 stars) and Plain English (Fallout-build/Fallout, 167 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Changelog Style Rules?
hardisgroupcom (a GitHub organization) maintains it in hardisgroupcom/sfdx-hardis, which has 402 GitHub stars. The repository holds 21 skills in this directory. The repository was last updated on October 9, 2026.
Source: hardisgroupcom/sfdx-hardis on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.