@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
Format
The ChangeLog file is a Markdown formatted file named CHANGELOG.md,
and contains sections with headers in the style N.M.K (YYYY-MM-DD).
Each ChangeLog entry is always formatted as <prefix/>: <summary/>
where the is one of the following tags and their usual related
changes:
- `FEATURE`: new functionality or configuration
- `IMPROVEMENT`: improved functionality or configuration
- `BUGFIX`: corrected functionality or configuration
- `UPDATE`: updated functionality or configuration
- `CLEANUP`: cleaned up functionality or configuration
- `REFACTOR`: refactored functionality or configuration
The is not longer than about 60-80 characters. The
ChangeLog entries for a single product release version are also always
grouped and sorted according to the above list.
Processing
The ChangeLog file CHANGELOG.md is located in the current
directory or one of the parent directories of the current project.
Locate and read this file. Store its relative path in .
You MUST NOT output anything, except the result with the
following :
You MUST NOT output anything, except introduce the current
operation with an output based on the following :
To update to entries of the most recent ChangeLog section, consult
the Git commits plus the currently already staged changes in the Git
index, but ignore the Git stash and still unstaged changes.
For finding the corresponding Git commits, first determine the
correct baseline Git tag. Take the N.M.K from the first (most
recent) level-2 header in the ChangeLog file and check whether a
corresponding Git tag already exists with the command git tag --list N.M.K. If this command produces no output, the first section is
still in-progress/untagged, so use the N.M.K from the second
level-2 header as the baseline tag instead. If this command does
produce output, the first section is already released/tagged, so use
the N.M.K from the first level-2 header as the baseline tag. Then
check all Git commits between HEAD and this baseline tag with the
command git log N.M.K..HEAD --numstat --pretty=format:'%h: %s'.
For finding the corresponding staged Git changes in the Git
index, use the command git diff --cached --numstat, but silently
skip already existing changes to the CHANGELOG.md file itself. If
still no corresponding ChangeLog entry exists for these staged
Git changes, derive a meaningful one from a git diff --cached
command.
You MUST NOT output anything, except introduce the current
operation with an output based on the following :
Without immediately modifying the CHANGELOG.md file, complete
the entries in the first (most recent) section only, by adding the
corresponding (most recent) Git commits and staged changes only.
For each Git commit, reduce the Git commit messages to a single
short sentence, not longer than 60-80 characters.
If a is too short or especially is not comprehensible
enough because of too little context information, add some essential
context, especially references to the class/module/package, etc.
For this, if necessary, read the related source files with a
corresponding git show command to get a better understanding of
this context.
You MUST NOT output anything, except introduce the current
operation with an output based on the following :
Without immediately modifying the CHANGELOG.md file, consolidate
the entries in the first (most recent) section only, by summarizing
and merging closely related entries. Perform the entry consolidation
per group only.
Without immediately modifying the CHANGELOG.md file, sort the
entries in the first (most recent) section only. Instead of the
chronological commit order, group the entries by the es.
You MUST NOT output anything, except introduce the current
operation with an output based on the following :
Finally, update the CHANGELOG.md file with the completed,
consolidated and sorted ChangeLog entries. Also, update the date
YYYY-MM-DD in the N.M.K (YYYY-MM-DD) header of the first (most
recent) section.
You MUST NOT output any further summary or give any further
explanations.
1---2name: ase-meta-changelog3description: Update changes entries in CHANGELOG.md files4---5
6@${CLAUDE_SKILL_DIR}/../../meta/ase-control.md
7@${CLAUDE_SKILL_DIR}/../../meta/ase-skill.md
8@${CLAUDE_SKILL_DIR}/../../meta/ase-getopt.md
9
10<skill name="ase-meta-changelog">
11Update ChangeLog Entries
12</skill>
13
14<expand name="getopt" arg1="ase-meta-changelog">
15 $ARGUMENTS
16</expand>
17
18<objective>
19Help to complete, consolidate and sort *ChangeLog* entries of the most
20recent *ChangeLog* section, based on underlying *Git* commits and staged
21changes.
22</objective>
23
24Format
25------
26
27The *ChangeLog* file is a Markdown formatted file named `CHANGELOG.md`,
28and contains sections with headers in the style `N.M.K (YYYY-MM-DD)`.
29
30Each *ChangeLog* entry is always formatted as `<prefix/>: <summary/>`
31where the <prefix/> is one of the following tags and their usual related
32changes:
33
34 - `FEATURE`: new functionality or configuration
35 - `IMPROVEMENT`: improved functionality or configuration
36 - `BUGFIX`: corrected functionality or configuration
37 - `UPDATE`: updated functionality or configuration
38 - `CLEANUP`: cleaned up functionality or configuration
39 - `REFACTOR`: refactored functionality or configuration
40
41The <summary/> is not longer than about 60-80 characters. The
42*ChangeLog* entries for a single product release version are also always
43grouped and sorted according to the above <prefix/> list.
44
45Processing
46----------
47
48<flow>
49
501. <step id="STEP 1: Locate and read ChangeLog entries">
51
52 The *ChangeLog* file `CHANGELOG.md` is located in the *current*
53 directory or one of the *parent* directories of the current project.
54 Locate and read this file. Store its relative path in <filename/>.
55
56 You *MUST* *NOT* output anything, except the result with the
57 following <template/>:
58
59 <template>
60 <ase-tpl-bullet-normal/> **CHANGELOG FILE:** `<filename/>`
61 </template>
62
63 </step>
64
652. <step id="STEP 2: Determine artifact changes">
66
67 You *MUST* *NOT* output anything, except introduce the current
68 operation with an output based on the following <template/>:
69
70 <template>
71 <ase-tpl-bullet-normal/> **DETERMINE ARTIFACT CHANGES:**
72 </template>
73
74 To update to entries of the most recent *ChangeLog* section, consult
75 the Git *commits* plus the currently already staged changes in the Git
76 *index*, but *ignore* the Git *stash* and still unstaged changes.
77
78 For finding the corresponding Git *commits*, first determine the
79 correct baseline Git tag. Take the `N.M.K` from the *first* (most
80 recent) level-2 header in the *ChangeLog* file and check whether a
81 corresponding Git tag already exists with the command `git tag --list
82 N.M.K`. If this command produces *no* output, the first section is
83 still in-progress/untagged, so use the `N.M.K` from the *second*
84 level-2 header as the baseline tag instead. If this command *does*
85 produce output, the first section is already released/tagged, so use
86 the `N.M.K` from the *first* level-2 header as the baseline tag. Then
87 check all Git commits between `HEAD` and this baseline tag with the
88 command `git log N.M.K..HEAD --numstat --pretty=format:'%h: %s'`.
89
90 For finding the corresponding staged Git *changes* in the Git
91 *index*, use the command `git diff --cached --numstat`, but silently
92 skip already existing changes to the `CHANGELOG.md` file itself. If
93 still no corresponding *ChangeLog* entry exists for these staged
94 Git *changes*, derive a meaningful one from a `git diff --cached`
95 command.
96
97 </step>
98
993. <step id="STEP 3: Complete ChangeLog entries">
100
101 You *MUST* *NOT* output anything, except introduce the current
102 operation with an output based on the following <template/>:
103
104 <template>
105 <ase-tpl-bullet-normal/> **COMPLETE ENTRIES:**
106 </template>
107
108 Without immediately modifying the `CHANGELOG.md` file, *complete*
109 the entries in the first (most recent) section only, by adding the
110 corresponding (most recent) Git *commits* and *staged* changes only.
111
112 For each Git commit, reduce the Git commit messages to a single
113 short <summary/> sentence, not longer than 60-80 characters.
114
115 If a <summary/> is too short or especially is not comprehensible
116 enough because of too little context information, add some essential
117 context, especially references to the class/module/package, etc.
118 For this, if necessary, read the related source files with a
119 corresponding `git show` command to get a better understanding of
120 this context.
121
122 </step>
123
1244. <step id="STEP 4: Consolidate and sort ChangeLog entries">
125
126 You *MUST* *NOT* output anything, except introduce the current
127 operation with an output based on the following <template/>:
128
129 <template>
130 <ase-tpl-bullet-normal/> **CONSOLIDATE ENTRIES:**
131 </template>
132
133 Without immediately modifying the `CHANGELOG.md` file, *consolidate*
134 the entries in the first (most recent) section only, by summarizing
135 and merging closely related entries. Perform the entry consolidation
136 per <prefix/> group only.
137
138 Without immediately modifying the `CHANGELOG.md` file, *sort* the
139 entries in the first (most recent) section only. Instead of the
140 chronological commit order, group the entries by the <prefix/>es.
141
142 </step>
143
1445. <step id="STEP 5: Write modified ChangeLog entries">
145
146 You *MUST* *NOT* output anything, except introduce the current
147 operation with an output based on the following <template/>:
148
149 <template>
150 <ase-tpl-bullet-signal/> **UPDATING CHANGELOG:**
151 </template>
152
153 Finally, *update* the `CHANGELOG.md` file with the completed,
154 consolidated and sorted *ChangeLog* entries. Also, update the date
155 `YYYY-MM-DD` in the `N.M.K (YYYY-MM-DD)` header of the *first* (most
156 recent) section.
157
158 You *MUST* *NOT* output any further summary or give any further
159 explanations.
160
161 </step>
162
163</flow>
164
majiayu000