Content
86%Weight 40%Scale 1-5Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.
A tight, well-structured release runbook: exact file-by-file edit list, explicit version-format invariants, and a clear branch-to-tag sequence with the most common failure mode flagged. The only real gaps are executable commands for tagging/publishing the GitHub Release and an explicit post-bump verification step.
Suggestions
Add the concrete commands for step 5, e.g. `git tag X.Y.Z <merge-commit>` and `gh release create X.Y.Z --generate-notes`, so the final step is copy-paste executable like the rest.
Add an explicit validation checkpoint after the version bump, e.g. `grep -rn "3\.04" CMakeLists.txt include/` (or re-check each of the five locations) before committing, turning the sync warning into a verify step.
State how to obtain the merge commit for the tag (e.g. `git rev-parse origin/master` after pulling post-merge) to remove ambiguity in step 5.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~45-line body is lean and assumes competence: exact files to edit (CMakeLists.txt, Doxyfile, package.xml, meson.build, SQLiteCpp.h), exact commit/tag/PR-title formats, and no explanation of concepts Claude already knows. It sits at anchor 5 — every token earns its place, with the zero-padding rule and version-number macro examples being genuinely non-obvious details. | 5 / 5 |
Actionability | Concrete, executable guidance throughout — exact file paths, the exact lines to change (e.g. `project(SQLiteCpp VERSION X.Y.Z)`, `#define SQLITECPP_VERSION_NUMBER XYYZZ`), commit message, PR title, and tag naming convention. Not 5 because the final steps give no copy-paste commands for the actual operations (e.g. `git tag X.Y.Z <merge-sha>` or creating the GitHub Release), leaving the operator to construct them. | 4 / 5 |
Workflow Clarity | A clear five-step numbered sequence (branch → CHANGELOG → bump → PR → tag) with real checkpoints: "Confirm every merged PR since the previous tag has a bullet" and the explicit sync warning that "a mismatch between the header macros and CMakeLists.txt is the most common release mistake". Not 5 because the batch version-bump has no explicit re-verification step (e.g. grep for the old version string before committing) — the sync check is stated as a rule rather than a validate-and-retry loop. | 4 / 5 |
Progressive Disclosure | Under 50 lines with well-organized sections and no external bundle files needed; the per-PR CHANGELOG and branching detail is correctly deferred to clearly signaled companion skills ([[sqlitecpp-workflow]], [[sqlitecpp-git-branching]]) rather than inlined. This matches the simple-skill exception in the rubric's scoring notes; no buried or nested references exist. | 5 / 5 |
Total | 18 / 20 Passed |