Product Changelogs: a Tokeny case study
Extract changes from Git commits to auto-generate user-facing version release notes. Follow the recorded task, execution screenshots, actual files and verification notes.
By the Tokeny team · Windows · Tokeny 1.7.8 · gpt-6-sol
Prepare the inputs
Create a separate workspace in Tokeny, download and unpack the sample inputs, then select a model that supports tools. The sample uses synthetic data or the public sources named in the article.
- source.bundle
Send the task to Tokeny
The original task was executed in Chinese. Copying these instructions reproduces the same task; the results below include an English report.
读取本目录真实 Git 提交历史，整理面向用户的版本更新说明和内部变更映射，隐藏纯内部维护项。不要操作其他仓库。 交付文件：CHANGELOG.md、commit-map.csv。 验收要点： - 更新说明对应实际 commit hash - 区分功能、修复和内部维护 这是使用合成演示输入或指定公开资料的真实操作案例。请先读取工作空间输入，再实际生成文件并自检。所有写入、脚本与临时服务限于当前工作空间；临时服务只监听 127.0.0.1，执行后关闭；不触达外部收件人、不发布、不付款、不更改系统设置，不调用子智能体。需要公开资料时可读取给定 URL。只启用完成任务必需的工具。另写 report.md（中文）和 report.en.md（英文），每份 400–800 字，包含输入、处理步骤、真实结果、检查方式和局限；失败或未验证部分如实记录，不能宣称成功。最终回复用中文列出产物、关键结果与待核实项。
The recorded run used an isolated demonstration workspace. Review the commands and file paths before approving operations in your own workspace.
What actually ran
The task was submitted through the Tokeny input box. An online model read the inputs and executed tools. Git operations target a separate demonstration repository. No remote push was performed.
Results and verification
Input
This review was limited to the current workspace and its local .git repository. I read README.md, ENVIRONMENT.md, .tokeny/manifest.json, and app.mjs, then checked the current branch and worktree state. The README identifies a demo task board and mentions an empty-title explanation; app.mjs exposes the current feature identifiers. At inspection time, .tokeny/ and ENVIRONMENT.md were untracked workspace inputs, so they were not treated as historical product changes. No other repository was accessed, and no external URL was read.
Processing steps
I used read-only Git commands to obtain the branch state, all visible commits, full and abbreviated hashes, timestamps, authors, subjects, file statistics, and patches. Each commit was then classified against its actual patch. Commit 1a793cb8d703d1fabf426ec22dea07085573bf2e creates features=["tasks"] and is classified as a feature. Commit 865d34c375306890281a7db70391fbf57cbd2c9f extends the feature list with csv-export and is also classified as a feature. Commit 5ba303196fda56d4f75a3dbf31df550c5d179bc2 adds the empty-title explanation to the README and is classified as a fix. No commit was identified as purely internal maintenance, so no maintenance item was exposed in the user-facing changelog. I then generated the Markdown changelog, the CSV commit mapping, and this bilingual report from those observed facts.
Actual results
CHANGELOG.md contains a 2026-11-07 release section with two additions and one fix. Every entry includes the complete commit hash that supports it. commit-map.csv contains all three historical commits and records the full hash, short hash, timestamp, category, visibility, user-facing summary, changed files, and evidence. The observed history therefore contains two feature commits, one fix commit, and zero purely internal maintenance commits.
Checks
The self-check verifies that all four deliverables exist and are non-empty UTF-8 text files. It compares every hash in the changelog and CSV with git log, checks the three CSV records, verifies their classifications and changed files against the patches, and confirms that the changelog covers each user-visible feature and fix without inventing a maintenance item. It also checks the final worktree diff to ensure that only the four requested deliverables were added and that no historical file or other repository was changed.
Limitations
The repository history contains only three minimal demo commits. The patches do not establish the complete runtime behavior of task listing, CSV export, or error-message rendering. I did not start the application or run an automated test suite, and app.mjs was not treated as a complete executable product. Accordingly, the statements about task listing and CSV export are evidence-based release notes derived from the commit subject and patch, not an end-to-end product acceptance result. The conclusion that there are no hidden maintenance items applies only to the currently visible history; it must be revisited when later commits are added.
Download and inspect the outputs
The archive contains the files created during this run. Use these checks when adapting the example to your own data.
- Reconcile the reported results against the downloadable sample inputs.
- Open the generated files and check the contents relevant to your task.
- Review the limitations and any unverified steps in the report.