تشغيل أي مهارة في Manus بنقرة واحدة

changelog

النجوم٣٥٩

التفرعات٩٨

آخر تحديث٢١ يونيو ٢٠٢٦ في ١٩:١٥

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

التثبيت

التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.

تشغيل في Manus

المصدر

hardisgroupcom

hardisgroupcom/sfdx-hardis

فتح مستودع GitHub عرض مستودعات المنشئ

تنزيل

تشغيل في Manus

المهن ذات الصلةSOC

استنادا إلى تصنيف SOC المهني

مطوّرو البرمجياتمهن الحاسوب والرياضيات·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.

المزيد من هذا المستودع

نفس المستودع

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.