sk-create-changelog

create-changelog

create-changelog is the changelog-authoring workflow packet of the sk-doc family. It creates global component changelog files under .opencode/changelog/{component}/v{VERSION}.md or packet-local nested changelogs under a spec packet's changelog/ folder, depending on source topology.

The executable contract lives here: resolve the work source, detect global vs packet-local output, calculate the version when global versioning applies, generate content from the canonical format, validate, then write the file. Use assets/changelog-template.md as the shared global changelog template and the references/ set (routed by references/README.md) only for supplementary worked examples or edge cases.

---

1. WHEN TO USE

Activation Triggers

Use this workflow when the task involves:

1. Creating a global component changelog for .opencode/changelog/{component}/v{VERSION}.md.
2. Creating a packet-local nested changelog for a spec folder or phase child.
3. Running or supporting /create:changelog.
4. Resolving a changed spec folder, component hint, or recent git history into a changelog target.
5. Calculating the next four-part semantic version for a global changelog.
6. Preparing GitHub release notes from the generated global changelog content.

Keyword triggers: create changelog, /create:changelog, changelog, changelog entry, release notes, global changelog, packet-local changelog, nested changelog, since the last version, --bump, --release, vX.Y.Z.B.

When NOT to Use

Use another sk-doc packet when:

1. The user only wants a generic release plan with no file output.
2. The target is a README or install guide. Use create-readme.
3. The target is an agent, command, benchmark package, flowchart, feature catalog, manual testing playbook, or skill. Use create-agent, create-command, create-benchmark, create-flowchart, create-feature-catalog, create-manual-testing-playbook, or create-skill.
4. The user wants to audit, validate, score, or optimize an existing changelog. Use create-quality-control.
5. The work source is too ambiguous to resolve to a spec folder, component hint, or recent git history.
6. The user asks for Git branch, commit, PR, or release mechanics beyond preparing release-note content.