ase-repo-changelog

@${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...

`<change-type/> [<artifact-kind/>]: <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 one or more of the following artifact tags, classifying which kind of artifact the change primarily touches. If multiple artifact kinds apply, comma-separate them (e.g. [arch, code]):

-   `spec`:  requirement/specification artifacts
-   `arch`:  architecture/design artifacts
-   `code`:  source code artifacts
-   `docs`:  documentation artifacts
-   `infr`:  infrastructure/build/tooling artifacts
-   `othr`:  any other artifacts

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

1. 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 :

2. You MUST NOT output anything, except introduce the current operation with an output based on the following :

   To update the 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 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 and insert a new, still-unreleased level-2 section (next patch version, current date) above it, which then becomes the first (most recent) section all subsequent steps operate on - the already released section MUST NOT be modified. 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 no second level-2 header exists (very first, still untagged release), skip the baseline tag and check all Git commits with the command git log HEAD --numstat --pretty=format:'%h: %s' instead. 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'.