Write Alpha Piscium Changelog

Write Alpha Piscium Changelog

Read agent_inputs/prompts/prompt_changelog.txt before starting. Follow this skill for release boundaries, output paths, and the review workflow. Let explicit user instructions override defaults.

Resolve the release

Require the target version. Accept optional explicit target and since revisions; explicit revisions always win.

Classify the version case-insensitively:

• Treat a version containing Alpha as alpha.
• Treat a version containing Beta as beta.
• Treat every other version as stable, including Hotfix.

Name alpha versions canonically as X.Y.Z-Alpha-<sha8>:

• Require the user to supply the X.Y.Z release stem; accept either X.Y.Z-Alpha or the full canonical version as input.
• Resolve the target commit first, then set <sha8> to the first eight lowercase hexadecimal characters of the full target commit ID.
• The suffix always identifies the target commit. Never use the base or since commit in the alpha version name.
• Normalize the output label to Alpha. When the input ends at X.Y.Z-Alpha, append the computed target suffix automatically.
• When an input suffix does not match the resolved target, stop before writing files, report both commits, and ask to use the canonical name. Do not silently preserve or rewrite a mismatched full version.

For example, if the range is 16fb7f14..HEAD and HEAD resolves to bc8f4db9..., use 1.10.0-Alpha-bc8f4db9, not 1.10.0-Alpha-16fb7f14.

Resolve the target in this order:

1. Use an explicit target revision.
2. Use an existing v<version> or <version> tag.
3. For alpha, use the trailing canonical eight-character hexadecimal commit suffix.
4. For an untagged stable or beta draft, use HEAD.

If alpha has no explicit target, resolvable tag, or commit suffix, stop and ask for the target revision.

Resolve the base as follows:

• Use an explicit since revision when supplied.
• For stable, select the nearest reachable tag whose name contains neither Alpha nor Beta. This includes hotfix tags.
• For beta, select the nearest reachable stable or beta tag and exclude alpha tags.
• For alpha, require an explicit since version or revision. Do not infer it from alpha files or tag dates.

For automatic selection, consider only tags whose peeled commits are ancestors of the target, exclude a tag resolving to the target itself, and choose the candidate with the smallest positive commit count in candidate..target. Do not choose by version-string order, tag date, or commit timestamp.

Resolve version-like revisions by trying the value as written, its optional v-prefixed form, and any trailing commit suffix. Verify both revisions with git rev-parse, then require git merge-base --is-ancestor <base> <target> to succeed. Use the exact range <base>..<target>: exclude the base, include the target, and exclude uncommitted worktree changes.

Use git --no-pager for commands that may page.

Select output files

Use these paths:

• Stable, beta, and hotfix English: changelogs/<version>.md
• Alpha English: changelogs/alpha/<version>.md
• Simplified Chinese: insert .sc before .md beside the English file, for example changelogs/1.0.0.sc.md

Create changelogs/alpha/ when needed. Preserve the existing rule that ignores this directory; do not edit changelogs/.gitignore.

Use this title in both languages:

# Alpha Piscium v<version>

Gather evidence

Inspect all of the following before drafting:

• The reverse chronological release range with commit subjects and bodies
• The net diff stat and changed paths for <base>..<target>
• Patches for ambiguous or user-visible commits
• Existing English prerelease changelogs whose resolvable release commits fall inside the range
• Changelog text supplied by the user

Treat earlier changelogs as editorial input, not ground truth. Verify every retained claim against the final target. Do not use Chinese files as source material for the English draft.

Do not let an unrelated dirty worktree block history-based drafting. Preserve all unrelated changes and edit only the requested changelog files.