v0.8.1

pr-review gains two new dogfood-driven gates and CONTRIBUTING.md codifies the matching rule: (1) Step 1 DoR rejects AI co-author trailers in commit messages (Co-Authored-By: Claude / 🤖 Generated with Claude Code etc.) — authorship semantics stay human; (2) Step 5 rejects CHANGELOG bullets that land in a published [X.Y.Z] dated section — closes the GitHub mergeStateStatus: CLEAN blind-spot where 3-way merge applies the textual diff into the post-Cut "wrong" section. Both rules were surfaced by this very release cycle and the regression they caught (PR #16 → PR #17 dogfood) is the canonical evidence. Patch release — ### Changed only, no Breaking.

Changed

• skills/pr-review/SKILL.md Step 5 — new sub-gate: CHANGELOG diff must land in [Unreleased], never an existing dated [X.Y.Z] section (#18) — adds a checkbox under Step 5 instructing the reviewer to inspect every new bullet's ## [...] heading parent in the diff and return 🔁 REQUEST_CHANGES if any bullet lands inside a published dated section. Documents the typical cause (PR base predates a release-sop Cut PR merge → GitHub 3-way merge applies the textual diff to the now-"wrong" section), the mergeStateStatus: CLEAN blind-spot (only checks textual conflict, not semantic placement), the two legitimate exceptions (the release-sop Cut PR itself; the hotfix-flow patch-tag-branch PR landing in its newly-created [X.Y.(Z+1)] section), and two recovery recipes (gh pr checkout && git rebase main before merge, or a follow-up docs(changelog) move-PR after merge — cf. this repo's PR #17 dogfood precedent). Closes the gap surfaced by the PR #16 → PR #17 dogfood: previously Step 5 only checked section type (Added / Changed / Fixed / …) but not section placement ([Unreleased] vs dated).
• skills/pr-review/SKILL.md Step 1 DoR — new gate forbidding AI co-author trailers in commit messages (#16) — Step 1 now rejects PRs whose commits contain Co-Authored-By: Claude / Co-authored-by: Claude Code <noreply@anthropic.com> / 🤖 Generated with Claude Code lines. Author attribution semantics must stay human (git log / git blame shouldn't carry an AI noreply@anthropic.com email). AI assistance for drafting / refactoring / debugging is fine — only the attribution trailer is rejected. Includes a git log --grep='Co-[Aa]uthored-[Bb]y:.*Claude' detection one-liner and a pointer to release-sop 故障预案 for the cleanup recipe (filter-branch / interactive rebase + force-push, with the temporary allow_force_pushes opening on protected branches).
• CONTRIBUTING.md Pull-requests section — same rule — adds a "Commit message hygiene" bullet forbidding AI co-author trailers in commits and PR bodies, with a git commit --amend recovery hint and a prepare-commit-msg hook suggestion for tooling that auto-appends trailers. Tracks the pr-review Step 1 gate.

v0.8.0

release-sop skill reshape — version-number recommendation now driven by the skill reading the latest tag + [Unreleased] against a SemVer table (no more Captain guessing); CHANGELOG ships as a separate Cut PR with no self-approve; red lines extended 5 → 8 to enforce both; plus an optional release-please automation track that bots Step 1.5 + Cut PR body + tag push while preserving the human review gate at Cut PR review (Step 4c) and post-release smoke (Step 6/7/8). Minor release — ### Added triggered by the new automation-track and Step 4 ↔ Step 5 causality-chain subsections; no Breaking changes.

Changed

• skills/release-sop/SKILL.md reshaped from 7 steps to 10 steps to close three release-flow gaps (#13) — (1) version-number recommendation added as Step 1.5: skill now self-runs git tag --sort=-v:refname | head -1 + an awk over the [Unreleased] section to read the latest tag and the pending entries, then applies a SemVer table (### Breaking / feat!: → major; ### Added / feat(...) → minor; only ### Fixed / ### Changed / ### Security / ### Docs / ### Removed → patch; empty [Unreleased] → STOP back to changelog-bot) to recommend the next bump before asking the Captain to confirm — Captain no longer has to remember the version number; 0.x → 1.0 is not auto-triggered (requires explicit Captain declaration); first-release case defaults to v0.1.0. (2) Step 4 rewritten as a Cut PR: previous Step 4 conflated content-writing with release-cut; the new Step 4 is split into 4a (Pre-cut gate — verifies [Unreleased] entries meet pr-review Step 5 / changelog-bot Step 2 granularity; fails STOP back to changelog-bot and forbids writing content inside the Cut PR), 4b (the Cut PR's only change is CHANGELOG.md — rename [Unreleased] → [X.Y.Z] - YYYY-MM-DD, add a blank [Unreleased] placeholder; no code / test / other-doc changes allowed), 4c (the Cut PR must go through full pr-review — author cannot self-approve; sole-maintainer projects must declare sole-maintainer release in PR body and observe a 24h cool-off). (3) Tag is now explicitly anchored to the Cut PR's merge commit to prevent release-notes-vs-tag drift. Companion red lines and 故障预案 rows added for each failure mode (empty [Unreleased], low-granularity entries, self-approve attempt, mixed-content Cut PR, first-release no-tag case). Reason: feature/fix PRs were merging without their CHANGELOG entries, forcing later releases to backfill (e.g. [0.7.2] had to backfill [0.5.0]–[0.7.1] PR refs); Captains were also having to remember version numbers and self-approve Cut PRs, both of which weakened team review. Reshape preserves agent-agnostic and Git-host-agnostic positioning.
• README.md skills table row for release-sop updated — describes the new 10-stage shape, the SemVer auto-recommend behavior, and the separate-Cut-PR / no-self-approve constraint. No install-path or trigger changes.
• skills/release-sop/SKILL.md red lines extended from 5 to 8 — three new hard red lines, each tied to a specific failure mode the previous SOP did not enforce: (6) Cut PR cannot self-approve / self-merge (sole-maintainer exception requires explicit sole-maintainer release declaration in PR body + ≥24h cool-off, framed as a non-default escape hatch); (7) [Unreleased] empty / entries below pr-review Step 5 granularity cannot be Cut (mandatory loop back to changelog-bot); (8) version number must come from Step 1.5's SemVer recommendation + Captain confirmation, not from a Captain typing a version in Step 1. Companion 故障预案 rows added so the skill always has a concrete "what to do" for each violation rather than just naming the red line.

Added

• skills/release-sop/SKILL.md — new ### Step 4 ↔ Step 5 因果链 subsection (#13) — between Step 4 (Cut PR) and Step 5 (tag push), with an ASCII chain diagram (Cut PR merge → CHANGELOG dated section → human tag push → CI release.yml → publish) plus a 3-row who-does-what-triggers-what table. Reason: the most common newbie misread of release-sop is "Cut PR merge auto-releases", which then breaks red line 1 (tag is the only release trigger) the moment a wrong version slips through. The subsection makes the human gate between Cut PR merge and tag push explicit, ties it to why red line 2 (no unpublish) makes that gate non-negotiable, and notes the no-release.yml docs/skill-repo case (Captain runs gh release create --notes-from-tag manually).
• skills/release-sop/SKILL.md — new ## 自动化轨道（release-please 模式，可选） section — placed after Step 8 / before 故障预案; documents how googleapis/release-please-action@v4 automates Step 1.5 (version recommend via Conventional Commits) + Step 4b (the Cut PR body is bot-maintained) + Step 5 (tag + GitHub Release on Cut PR merge), while preserving Step 4c team review (red line 6 still applies — Release PR is still a PR), Step 6/7/8 human ops, and red line 1 (tag is still the only release trigger; bot just becomes the tag pusher). Includes a ~20-line .github/workflows/release-please.yml example, the release-type matrix (simple/node/go/python/rust), the companion release.yml for tag-triggered packaging (GoReleaser / npm publish / docker push), a Conventional Commits → bump cheat sheet, a section explaining why semantic-release (skips Cut PR gate) and changesets (overkill for single repos) are not recommended, and a 4-row "when to pick release-please vs manual SOP" decision table (release frequency, conventional-commits readiness, monorepo, GitHub-Action availability). Keeps the SKILL agent-agnostic — the section is documentation for human/agent reading, not a hard step.
• README.md skills table row for release-sop mentions the release-please automation track as an optional path — no install-path or trigger changes.

v0.7.2 — hotfix-flow Step 7 fix + CHANGELOG backfill

[0.7.2] - 2026-05-10

Follow-up to a retrospective pr-review pass on #7: the hotfix-flow skill's Step 7 no longer prescribes a git merge --no-ff forward-merge that a required_linear_history / protected main (this repo's own, for one) would reject, and the [0.5.0]–[0.7.1] CHANGELOG entries get the PR references they were missing. No skill behavior change beyond the Step 7 wording. Patch release.

Fixed

• skills/hotfix-flow/SKILL.md Step 7 no longer prescribes git merge --no-ff for repos with linear history (#11) — the forward-merge step gave git merge --no-ff hotfix/… as the default command, which a required_linear_history / protected main (like this repo's own) rejects; Step 7 and its edge-case row now spell out that on such repos the forward-merge goes through a PR with a rebase/squash merge, keeping --no-ff only as the "repo allows merge commits" path. Surfaced by running the pr-review skill retrospectively on #7.

Changed

• CHANGELOG.md — PR references backfilled on the [0.5.0]–[0.7.1] entries (#11) — the primary bullet of [0.5.0] / [0.6.0] / [0.7.0] / [0.7.1] now carries (#3) / (#5) / (#7) / (#9), matching the (#init) / (#1) convention on [0.1.0] / [0.4.0]; these had been missing the PR ref that pr-review Step 5 / changelog-bot Step 2 require.

v0.7.1 — CONTRIBUTING.md + SECURITY.md

[0.7.1] - 2026-05-10

Community-health files added — CONTRIBUTING.md and SECURITY.md. No skill changes; these are the files the skills already referenced (pr-review Step 1/Step 6, issue-triage Step 0/Step 1, hotfix-flow, release-sop Step 2). Patch release.

Added

• CONTRIBUTING.md — contributor guide — codifies the two hard rules (one skill per directory, ecosystem-agnostic core), what shipping a new skill entails (SKILL.md + examples/<name>-demo.md + README rows + CHANGELOG entry; install.sh auto-discovers), the PR conventions pr-review checks (title type(scope): summary, What/Why + linked issue, tests/CHANGELOG/docs same-PR, CHANGELOG goes in [Unreleased] not a tag commit — pointer to changelog-bot, Breaking + migration line, the security flag), local-testing steps (./install.sh <skill> → restart Claude Code), and the release / hotfix procedure (release-sop / hotfix-flow; tag is the only release trigger; main is protected, all changes via PR). Previously these rules lived only as a two-line section in the README.
• SECURITY.md — security policy — supported versions (latest release only; upgrade before reporting), what counts as a security issue for a docs/skill repo (a SKILL.md that could be steered to do harm or skip a gate; install.sh filesystem surprises; supply-chain of the raw-URL install path) vs. an ordinary bug, how to report privately (GitHub private vulnerability reporting via the Security tab — no public issues/PRs/discussions with details or PoCs), what to expect (acknowledgement, fix-or-written-decision, hotfix-flow for fixes that can't wait, coordinated disclosure with an advisory naming affected versions, credit), and how it ties into the skills (issue-triage routes here, pr-review Step 6 requires this flow, hotfix-flow runs security fixes through it). pr-review, issue-triage, hotfix-flow, and release-sop all reference SECURITY.md; this is the file they were referencing.
• README.md — Contributing section points to CONTRIBUTING.md / SECURITY.md; layout tree updated — the Contributing section keeps the two-line rule summary and now links the full CONTRIBUTING.md and SECURITY.md, plus notes main is protected; the repo-layout tree gains CONTRIBUTING.md and SECURITY.md rows.

v0.7.0 — hotfix-flow skill (roadmap complete)

[0.7.0] - 2026-05-10

hotfix-flow skill shipped — the last 🚧 in the roadmap. The Git-host-workflow family is now complete: issue-triage → pr-review → changelog-bot → release-sop, with hotfix-flow as the emergency entry. hotfix-flow carries the same hard-gate philosophy plus two non-negotiables: cherry-pick only the fix (no "while we're here" extras), and forward-merge the hotfix back to main (and every intermediate release/* branch) — no merge-back, not done. Agent-agnostic markdown contract; Git-host-agnostic (GitHub / GitLab / Gitea).

Added

• skills/hotfix-flow/SKILL.md — generic hotfix-flow SOP — drives a hotfix for a released version that can't wait for the next release. Eight gated steps: Step 0 should-we-hotfix gate (regression/S1/security in a released version + release train too slow + locate the affected version, the base = the release tag or release/* branch, the fix commit, the linked issue-triage'd issue), Step 1 the fix lands on main first via a normal PR (so main never regresses) — exceptions for "main already moved past it" and "bug only exists on the released branch", Step 2 branch the hotfix off the release point (git switch -c hotfix/vX.Y.(Z+1) vX.Y.Z, not off main), Step 3 cherry-pick only the fix commit(s) — no unrelated commits, no "while we're here" cleanups, big conflict ⇒ stop (not a clean hotfix), Step 4 a CHANGELOG entry under a new ## [X.Y.(Z+1)] - YYYY-MM-DD dated section on the hotfix branch (the one case an entry goes into a dated section on a non-main branch — drafted via changelog-bot), Step 5 the simplified hotfix review (pr-review's hotfix gates only: CI green + regression test + CHANGELOG entry + correct base + pr-review Step 6 security-trigger judgement not skipped), Step 6 tag the patch release and hand to release-sop entering at its Step 5 (tag → push → GitHub Release whose notes name the affected versions → post-release smoke → DOD), Step 7 forward-merge the hotfix back to main (and through every intermediate release/* branch in order) — via a PR if main is protected; until this lands the hotfix is not done; verified with git branch --contains <fix-sha> showing main + main's CHANGELOG having [X.Y.(Z+1)], Step 8 DOD closeout. Includes an edge-case runbook (could-just-wait, fix-not-on-main, big cherry-pick conflict, tag-off-main repo, multi-release-branch repo, security hotfix via SECURITY.md, protected main, forgotten forward-merge, "slip in one more change", hotfix-on-a-hotfix) and eight red lines (branch off the release point not main; cherry-pick only the fix; fix must be on main too; must forward-merge back; hotfix still needs a CHANGELOG entry + regression test; security hotfix runs through SECURITY.md; tag is the only release trigger; no extra commits in the hotfix). Composition: triggered by S1/security issues from issue-triage; uses pr-review's hotfix gates; uses changelog-bot for the entry; hands off to release-sop for the release closeout. Agent-agnostic; Git-host-agnostic.
• README.md — hotfix-flow promoted from 🚧 planned to ✅ shipped; the roadmap is now complete — Skills table row rewritten with the 8-stage summary; the "planned skills" note replaced with "all five skills are shipped — the Git-host-workflow family is complete"; quickstart gains a hotfix-flow curl one-liner; Usage section gains a hotfix-flow trigger table; repo-layout tree updated for skills/hotfix-flow/SKILL.md and examples/hotfix-flow-demo.md; Background section reworded ("the other planned skills" → "the other four skills"). install.sh unchanged — it auto-discovers any skills/<name>/SKILL.md.
• examples/hotfix-flow-demo.md — worked hotfix-flow transcript — the 8 steps run end-to-end on a hypothetical S1 regression in dws 0.4.0 (panic on a redirecting URL) in a tag-off-main repo: Step 0 the should-we-hotfix decision, Step 1 the fix landing on main via PR #171, Step 2 branching hotfix/v0.4.1 off tag v0.4.0, Step 3 cherry-picking only the fix commit (with the "big conflict ⇒ stop" note), Step 4 the [0.4.1] dated CHANGELOG section on the hotfix branch, Step 5 the simplified review with the security-trigger judgement explicitly run, Step 6 tagging v0.4.1 and handing to release-sop, Step 7 the forward-merge-back-to-main PR with the git branch --contains verification, Step 8 the DOD closeout. Closes with the security-hotfix-via-SECURITY.md, the "don't slip in --retry" cherry-pick-only, and the skipped-forward-merge contrasts.

v0.6.0 — issue-triage skill

[0.6.0] - 2026-05-10

issue-triage skill shipped — the front of the workflow chain: it decides which issues are accepted (and thus fixes #N-eligible for changelog-bot, a DoR plus for pr-review, milestone fodder for release-sop DOD). Same hard-gate philosophy: a written rationale on every disposition, an explicit S1–S4 severity rubric instead of title-driven guessing, and security reports routed to SECURITY.md rather than triaged in the open. Agent-agnostic markdown contract; Git-host-agnostic (GitHub / GitLab / Gitea). After this, only hotfix-flow remains 🚧 in the roadmap.

Added

• skills/issue-triage/SKILL.md — generic issue-triage SOP — takes an incoming issue (or a batch) and produces a written triage verdict. Seven steps: Step 0 issue + repo context load (gh issue view / glab / tea; label taxonomy, .github/ISSUE_TEMPLATE/, CONTRIBUTING/SUPPORT, SECURITY.md, milestones, CODEOWNERS), Step 1 type classification into exactly one of bug / feature / question-support / docs / task-chore / security / meta-discussion — security stops here and routes to SECURITY.md (no detail-chasing in the open), Step 2 actionability gate with a written rationale per disposition (accepted / needs-repro / needs-info / needs-discussion / duplicate / out-of-scope-wontfix / stale / upstream), Step 3 area/component labeling against the repo's area/* taxonomy (no unilateral new labels), Step 4 severity for accepted bugs against an explicit S1–S4 rubric (severity ≠ priority; S1 security-adjacent → back to the Step 1 security path), Step 5 the triage output block (type · disposition · area · severity · suggested labels/milestone/owner · one-line rationale posted on the issue · templated needs-repro/needs-info comment or duplicate/out-of-scope close comment · what-happens-next) — applied via gh issue edit/comment/close only with write access + user confirm; never closes on a guess, Step 6 handoff / batch mode (per-issue table, never blanket-label). Includes an edge-case runbook (no label taxonomy, security report in a public issue, no reporter response, multi-issue bundle, bug-that's-actually-a-question, emotion-titled report, duplicate-with-better-info, cross-repo/upstream, in-scope-but-undecided) and six red lines (no rationale-free triage, no public-issue security handling, no title-driven severity, no unilateral label/milestone changes, no guess-based closes, no batch blanket-labeling). Explicit composition: changelog-bot writes fixes #N only against accepted issues; pr-review Step 1 counts a linked-triaged-issue as a DoR plus; release-sop Step 8 DOD closes the milestoned issues; S1+security feeds hotfix-flow. Agent-agnostic; Git-host-agnostic.
• README.md — issue-triage promoted from 🚧 planned to ✅ shipped — Skills table row rewritten with the 7-stage summary; quickstart gains an issue-triage curl one-liner; Usage section gains an issue-triage trigger table; repo-layout tree updated for skills/issue-triage/SKILL.md and examples/issue-triage-demo.md. install.sh unchanged — it auto-discovers any skills/<name>/SKILL.md.
• examples/issue-triage-demo.md — worked issue-triage transcript — the 7 steps run end-to-end on a hypothetical no-repro bug report (dws fetch hangs forever): first pass → needs-repro (area + severity deferred on no evidence) with the filled-in template comment; second pass after the reporter supplies a repro → accepted, area/http, S2 (rationale records why it's not S1), milestone v0.6.0, owner from CODEOWNERS, posted rationale, gh commands; plus a batch-mode table triaging three more issues (duplicate close, question route + close, out-of-scope close) and a closing contrast on the public-issue-security and emotion-titled-report cases.

v0.5.0 — changelog-bot skill

[0.5.0] - 2026-05-10

changelog-bot skill shipped — generates the CHANGELOG entries that pr-review Step 5 later checks and release-sop Step 4 later folds into a dated release. Same hard-gate philosophy: a granularity gate that bounces low-quality bullets, a Breaking special case with a mandatory migration line, and a hard red line against committing the CHANGELOG itself (it proposes; the author merges via a normal PR). Agent-agnostic markdown contract; Git-host-agnostic (GitHub / GitLab / Gitea).

Added

• skills/changelog-bot/SKILL.md — generic CHANGELOG-entry drafter — takes a PR / commit-range / branch / pasted diff and produces a ready-to-paste Keep-a-Changelog entry. Six steps: Step 0 input identification + CHANGELOG house-style scan (file location, sections used, bullet conventions, [Unreleased] vs dated sections), Step 1 diff walk + classification into Breaking / Added / Changed / Deprecated / Removed / Fixed / Security with non-user-facing noise (refactors, test-only, CI, formatting, behavior-neutral dep bumps) discarded — whole-PR-is-noise ⇒ a valid "no entry needed, because …" output, Step 2 per-entry drafting behind a granularity gate (every bullet must carry bolded phenomenon + root cause/trigger + fix/implementation + impact plus PR ref / fixes #N; rejects "fix a bug" / "improve performance" / "update deps"; won't fabricate root cause), Step 3 Breaking-change special case (own Breaking section + mandatory migration line + major-bump cross-check), Step 4 placement & output (top of [Unreleased] under the right section in Keep-a-Changelog order; never a tag commit / dated section; never auto-commits), Step 5 self-check against the exact gates pr-review Step 5 applies + handoff line. Includes an edge-case runbook (no CHANGELOG file, repo doesn't use one, multi-change PR, oversized diff, unknown root cause, dependency bump, pure-docs/CI/test PR, pre-existing non-compliant entry) and six red lines (never commits the CHANGELOG, never fabricates root cause/impact, no low-granularity bullets, no hiding Breaking in a normal section, never writes into a tag commit / dated section, never changes the repo's CHANGELOG format unilaterally). Explicit composition: pr-review Step 5 checks presence/format/granularity — changelog-bot generates the content; release-sop Step 4 folds [Unreleased] entries into the dated release. Agent-agnostic; Git-host-agnostic.
• README.md — changelog-bot promoted from 🚧 planned to ✅ shipped — Skills table row rewritten; quickstart gains a changelog-bot curl one-liner; Usage section gains a changelog-bot trigger table; repo-layout tree updated for skills/changelog-bot/SKILL.md and examples/changelog-bot-demo.md. install.sh unchanged — it auto-discovers any skills/<name>/SKILL.md.
• examples/changelog-bot-demo.md — worked changelog-bot transcript — the 6 steps run end-to-end on a hypothetical PR (fix(auth): refresh token rotation drops the new token on a slow write): Step 0 input + house-style scan, Step 1 classification into one Fixed + one Security change (test file noted as coverage, not its own entry), Step 2 turning a would-be "fix a bug" bullet into two four-element granular entries (with a counter-example of the bounced version), Step 3 not-Breaking determination, Step 4 the ready-to-paste [Unreleased] block placed under ### Fixed / ### Security, Step 5 the self-check + handoff to pr-review Step 5 / release-sop Step 4. Closes with the "pure-refactor ⇒ no entry needed" and "renamed flag ⇒ Breaking + migration line" contrasts.

v0.4.0 — pr-review skill

pr-review skill shipped — a generic 8-stage PR review SOP that guards exactly the gates release-sop Step 2 later replays. Same hard-gate philosophy as release-sop: every step has a written gate, failure stops execution at that step, no skip path, no "fix it in a follow-up". Agent-agnostic markdown contract; Git-host-agnostic (GitHub / GitLab / Gitea).

Added

• skills/pr-review/SKILL.md — generic 8-stage PR review SOP (#1) — encodes Step 0 PR context load (GitHub gh / GitLab glab / Gitea tea / manual), Step 1 DoR meta check (title convention, What/Why, linked issue, target branch, PR size, clean history), Step 2 change classification + interface/behavior/data impact (breaking → must be flagged + CHANGELOG Breaking + migration note), Step 3 line-level code review (correctness, edge/failure, error handling, resource & concurrency, consistency, unintended side effects) producing [blocking] / [nit] comments, Step 4 test-coverage gate (tests same-PR, regression test for fixes, no skipped tests, CI green — zero-test feature PR or red CI ⇒ hard BLOCK), Step 5 CHANGELOG-entry gate (presence + Keep-a-Changelog format + granularity; content generation deferred to changelog-bot), Step 6 security-review trigger checklist (auth / crypto / parsers & deserialization / permission model / dependency bumps / CI secrets & pull_request_target / new endpoints — must write an explicit hit-or-no-hit line), Step 7 verdict report (✅ APPROVE / 🔁 REQUEST_CHANGES / ⛔ BLOCK with per-gate results, unmet-item list with "how to fix", security verdict, line-level comments, one-line conclusion). Includes edge-case runbook (CI in-flight, sole-maintainer author, hotfix PR, oversized diff, bot/dependency PR, vendored/generated code, reviewer out of depth), seven red lines (no approve on red CI, no zero-test feature PR, no unflagged breaking change, security trigger ⇒ must route, no "fix in a follow-up", no self-approve, don't promote nits to blockers or demote blockers to nits), and explicit composition with release-sop (this skill guards exactly the gates release-sop Step 2 later replays), changelog-bot, hotfix-flow, issue-triage. Agent-agnostic: same contract loads into Claude Code / Qoder / Cursor / Custom GPT / generic LLM.
• README.md — pr-review promoted from 🚧 planned to ✅ shipped — Skills table row rewritten with the 8-stage summary; quickstart now has a pr-review curl one-liner alongside release-sop; Usage section gains a pr-review trigger table; repo-layout tree updated to show skills/pr-review/SKILL.md and the new examples/ directory. install.sh needs no change — it already auto-discovers any skills/<name>/SKILL.md.
• examples/pr-review-demo.md — worked pr-review transcript — the 8 steps run end-to-end against a hypothetical PR (feat(http): add --retry N flag): Step 0 context load, DoR pass, change classification flagging stale docs, a line-level review surfacing two [blocking] (unreset POST body on retry, unbounded un-jittered backoff) plus two [nit], a test-coverage gate noting a missing regression test, a missing-CHANGELOG-entry gate, an explicit no-hit security-trigger judgement, a 🔁 REQUEST_CHANGES verdict report with a numbered how-to-fix list, then a second pass after the author's follow-up commit flipping it to ✅ APPROVE. Closes with notes on when the verdict would instead be ⛔ BLOCK / 🔒 SECURITY REVIEW REQUIRED, and on why this repo's own PR #1 is a near-trivial APPROVE (docs-only).

v0.3.0 — release-sop agent-agnostic

[0.3.0] - 2026-05-10

Repo and release-sop skill repositioned from "Claude Code-only" into agent-agnostic: the SKILL is a markdown behavior contract that loads into Claude Code, Qoder, Cursor, ChatGPT Custom GPT, or any LLM. Same contract, different load mechanism.

Changed

• skills/release-sop/SKILL.md frontmatter & H1 generalized — description now reads "通用 Git 项目发布 SOP 引导 skill（适用于 GitHub / GitLab / Gitea 等 Git 主机；可装入 Claude Code / Qoder / Cursor / 通用 LLM 等任意 AI Agent）"; H1 changed from "通用 GitHub 发布流程" to "通用 Git 项目发布流程（多 Agent 兼容）". Body of the SOP unchanged — the steps, gates, red lines, runbook stay identical.
• README.md rewritten — opening positions repo as agent-agnostic skill collection; new "Why agent-agnostic?" section; install section now leads with a 5-row Agent × install-path × trigger × notes table (Claude Code / Qoder / Cursor / Custom GPT / generic LLM); Claude Code commands kept as the quickstart subsection; companion blog post link updated to /git-release-sop/.
• Companion blog post URL changed — companion post slug renamed from /github-release-sop/ to /git-release-sop/ to match the broadened positioning. Old URL retains a meta-refresh redirect on the blog side.

Notes

• This is non-breaking for existing installs: anyone who installed v0.2.0's ~/.claude/skills/release-sop/SKILL.md keeps working — the skill body and its name: frontmatter are unchanged. Only the description text and H1 in the file's metadata-zone were touched.
• install.sh continues to target the Claude Code skills directory layout. Per-target install (Qoder / Cursor / etc.) is on the roadmap but not in this version.

v0.2.0 — git-skill multi-skill collection

[0.2.0] - 2026-05-10

Repo repositioned from a single-skill project (claude-skill-release-sop) into a multi-skill collection (git-skill) for Git-host workflows (GitHub / GitLab / Gitea). release-sop is the first skill; pr-review, issue-triage, changelog-bot, hotfix-flow are planned.

Breaking

• Repo renamed PeterGuy326/claude-skill-release-sop → PeterGuy326/git-skill — old URLs auto-redirect via GitHub but new clones / installs should use the new URL. Update any pinned raw.githubusercontent.com install commands accordingly.
• SKILL.md moved from repo root to skills/release-sop/SKILL.md — the one-liner curl install command path changed from /main/SKILL.md to /main/skills/release-sop/SKILL.md.
• install.sh signature changed from "no-arg installs the only skill" to "takes a skill name or --all" — old ./install.sh invocation now errors and prints usage; use ./install.sh release-sop to keep prior behavior.

Changed

• README.md rewritten to introduce the repo as a skill collection — includes a roadmap table for planned skills, a layout section, and updated install paths.
• install.sh rewritten to support multi-skill installs (--all, --list, <skill-name>) and both user / project scopes — fails fast with usage hint and skill list when called with no args.
• GitHub repo description updated to reflect collection positioning.

Migration

If you installed v0.1.0:

# Update local clone (only needed if you keep a local working copy):
cd <your-local-clone>
git remote set-url origin https://github.com/PeterGuy326/git-skill.git
git pull --ff-only

# Update one-liner install (the SKILL itself is unchanged behaviorally):
mkdir -p ~/.claude/skills/release-sop && \
  curl -fsSL https://raw.githubusercontent.com/PeterGuy326/git-skill/main/skills/release-sop/SKILL.md \
  -o ~/.claude/skills/release-sop/SKILL.md

The installed ~/.claude/skills/release-sop/SKILL.md file is identical to v0.1.0 — no behavior change inside the skill, only repo-level reorganization.