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.