메뉴
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 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| 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.md entries are read by end users (Salesforce admins, devs, ops) deciding whether to upgrade. They are not internal dev notes.
welcomeToDocumentation i18n key now teases what is browsable..."[hardis:topic:action](https://sfdx-hardis.cloudity.com/hardis/topic/action/).[command](url): <change>.## [beta] (main) at the top of the file. Do not create version sections - releases set those.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.
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.
Gather requirements by asking clarifying questions until the problem is fully understood. First step of the contribution workflow.
Design the solution and write a technical specification based on requirements analysis. Second step of the contribution workflow, use after /analyze.
Handle CVE/vulnerability reports from security linters (trivy, osv-scanner, etc.). Tries to upgrade first; ignores only when safe and justified.
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.
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.