القائمة
Use when creating and publishing a new GitHub release with an auto-generated changelog and README review.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Run markdown linting from tools/spec-lint/, fix issues, and rerun until clean
Whole-repo audit for over-engineering. Like ponytail-review, but scans the entire codebase instead of a diff: writes a ranked checklist to plans/AUDIT.md of what to delete, simplify, or replace with stdlib/native equivalents. Use when the user says "audit this codebase", "audit for over-engineering", "what can I delete from this repo", "find bloat", or calls ponytail-audit. One-shot report, does not apply fixes.
Fix ponytail audit items from plans/AUDIT.md one at a time. For each item: implementer fix → ponytail-review → normal review → quality gate → mark done → commit. Cycle until reviewer is happy at each stage. Complements ponytail-audit.
Code review focused exclusively on over-engineering. Finds what to delete: reinvented standard library, unneeded dependencies, speculative abstractions, dead flexibility. One line per finding: location, what to cut, what replaces it. Use when the user says "review for over-engineering", "what can we delete", "is this over-engineered", "simplify review", or calls ponytail-review. Complements the correctness-focused reviewer subagent — this one only hunts complexity.
Use when executing a project folder under plans/ that contains SPEC.md, PLAN.md, and PHASE_XX.md files.
Fix the first incomplete checklist item in plans/<project>/REVIEW.md, commit the fix, then stop. Does not commit REVIEW.md — it is gitignored by design.
| name | publish-release |
| description | Use when creating and publishing a new GitHub release with an auto-generated changelog and README review. |
Create a tagged release, generate a changelog, review the README, and publish to GitHub via the gh CLI. The workflow commits loose changes, runs the quality gate, builds, generates a CHANGELOG.md, reviews the README.md, tags, pushes, and creates a GitHub release.
Run git status --porcelain. If there are uncommitted changes, ask the user whether to commit them. If they agree, stage all changes and create a commit with message chore: checkpoint before release.
If there are staged but uncommitted changes, ask whether to commit them with the same message.
Run the full quality gate:
go test ./... && make check-fix
If it fails, report the failure and stop — do not proceed to the release.
Confirm the project compiles cleanly:
make build
If the build fails, report the failure and stop.
Ask the user for the new version string (e.g. 0.1.0, 0.2.0). Present a suggested version by looking at existing tags:
git tag --sort=-v:refname | head -5
If no tags exist, suggest 0.1.0. Otherwise suggest a patch bump of the latest tag.
Identify the previous release tag. Find the most recent tag matching v* with git tag --sort=-v:refname | head -1. If no tag exists, use the first commit as the range start (or collect all commits).
Collect commit messages between the previous tag and HEAD:
git log <prev-tag>..HEAD --oneline
If CHANGELOG.md does not exist, create it with a # Changelog heading. If it exists, update it.
Build a new ## [<version>] - <date> section. Categorise commits by conventional-commit type:
| Prefix | Section |
|---|---|
feat: / feature: | Added |
fix: | Fixed |
chore: / refactor: | Changed |
docs: | Changed |
test: | Changed |
remove: | Removed |
break: | Breaking |
For each category, list the commit messages as bullet points, stripping the commit hash and conventional-commit prefix. Skip merge commits (Merge branch ...).
Insert the new section at the top of CHANGELOG.md, immediately after the # Changelog heading. Follow consistent section formatting.
Read README.md in full. Do a high-level review:
Report any issues found. Ask the user whether to fix them now or defer. If fixing, make the edits and stage README.md.
Stage CHANGELOG.md and README.md (if changed). Commit with message:
release: v<version>
Create a lightweight tag:
git tag v<version>
git push origin HEAD
git push origin v<version>
If push fails (e.g. no upstream branch), ask the user how to proceed.
Use the gh CLI to create the release. Build the release notes from the changelog section just created. Extract the ## [<version>] section from CHANGELOG.md for the body:
gh release create v<version> --title "v<version>" --notes "<changelog-section>"
If a one-time auth code is needed, prompt the user.
Confirm the release was created by checking the exit code and the URL in the output.
Report:
If the user wants to attach build artefacts to the release, rebuild with platform-specific targets (if available in the Makefile) and upload:
gh release upload v<version> <file> [...]
Only do this if the user explicitly requests it.
CHANGELOG.md style if one exists.gh CLI. If gh is not installed or authenticated, stop and tell the user to set it up.CHANGELOG.md and README.md (if reviewed) should be in the release commit.