菜单
Cut a new release of the SDD CLI — survey changes against the graph, propose the version bump, draft curated notes, and ship after explicit user confirmation. Invoke when the user wants to create a release or bump the version.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Work with the SDD decision graph. Check in on project state, capture signals, make decisions, evaluate completed work. Use when starting a session, capturing observations, or making project decisions.
Work with the SDD decision graph. Check in on project state, capture signals, make decisions, evaluate completed work. Use when starting a session, capturing observations, or making project decisions.
Run an SDD session through the workflow engine — procedures served step by step over the sdd MCP server instead of skill prose. Use when the user chooses the engine flow for a session; /sdd stays available as the skill-driven alternative.
Run an SDD session through the workflow engine — procedures served step by step over the sdd MCP server instead of skill prose. Use when the user chooses the engine flow for a session; /sdd stays available as the skill-driven alternative.
Set up an SDD graph on a fresh or sparse project — walk through a readiness sweep, brownfield context gather, actor capture, and Golden Circle strategic seeding, then hand back to /sdd via catch-up. Invoke when the graph lacks actors or aspirations.
Produce a colleague-style catch-up briefing on the SDD project. Threads recent activity, active work, and warm gaps into 2–4 story-arc clusters with action-tight numbered items. Use as the check-in mode when starting a session or whenever a fresh briefing is wanted.
| name | release |
| description | Cut a new release of the SDD CLI — survey changes against the graph, propose the version bump, draft curated notes, and ship after explicit user confirmation. Invoke when the user wants to create a release or bump the version. |
A release = a new git tag (vX.Y.Z) on main. The tag push triggers .github/workflows/release.yaml, which runs GoReleaser to publish binaries, build-provenance attestations, install.sh, and a Homebrew cask update at networkteam/homebrew-tap. The GitHub release body carries hand-written notes — not GoReleaser's auto-changelog.
git log $(git describe --tags --abbrev=0)..HEAD --oneline
The git log is the authoritative scope of the release. Commit subjects in this project often carry a graph entry ID like (d-tac-e1s) or (s-tac-2b0) — collect all relevant IDs from the log, then pull them in one batch call:
sdd show <id1> <id2> <id3> --up 0 --down 0
Full bodies plus the envelope's immediate closes/refs context, no chain traversal — the right level for highlight prose. You see what plan closed what without walking the whole upstream history. Skip housekeeping commits (sdd: refresh installed skills, sdd: signal/decision/wip graph entries, pure refactors with no user-visible effect).
Pre-1.0 convention in this project:
0.X+1.0) — net-new commands, contract supersession, broad feature deltas (e.g. v0.5.0 = sdd view + 7+7 type system + engage refactor)0.X.Y+1) — incremental polish, additive primitives, UX work within existing surfaces (e.g. v0.5.1 = not(<filter>) + sdd init readiness-check)Surface the proposed level with reasoning before drafting notes. The user decides; ambiguous scope deserves dialogue.
Format follows v0.5.0 / v0.5.1:
## Highlights
- **`feature` — short technical name** — one-paragraph narrative covering what shipped and the key surface details.
- **Second highlight** — ...
## Other changes
- One-line bullets for smaller items.
**Full Changelog**: https://github.com/networkteam/sdd/compare/vPREV...vNEW
Highlights = paragraph-worthy items. Other changes = one-liners. Skip housekeeping commits. Skip README and docs-only changes — the notes describe what shipped in the CLI binary, not documentation edits to the repo. Save the draft to .sdd/tmp/vX.Y.Z-notes.md (gitignored).
Show the user the proposed version, the reasoning, and the full draft. Wait for an explicit "yes / proceed / ship it" before running anything. Edits accepted in dialogue ≠ consent — ask if unclear.
gh release create vX.Y.Z --title vX.Y.Z --notes-file .sdd/tmp/vX.Y.Z-notes.md --target main
This single call creates the tag, pushes it, publishes the release with the curated body, and triggers the workflow. GoReleaser sees the existing release at the tag and attaches assets without overwriting the body — release.mode defaults to keep-existing.
Do not pass --draft. GoReleaser does not honor a third-party draft; it creates a competing published release at the same tag, leaving the draft orphaned. (Learned via the v0.5.1 mishap.)
Do not split into git tag + git push origin vX.Y.Z + gh release edit. The single-command form rolls all three into one and is the proven minimal flow.
gh run list --workflow=release.yaml --limit 1
gh run watch <run-id>
gh release view vX.Y.Z # body intact, assets attached
The workflow run typically completes in ~2 minutes. Sanity-check that the release body still shows the curated notes (not auto-generated) and that the assets list includes binaries, checksums, and install.sh.
If the workflow fails or completes partially: gh run rerun <run-id>. Re-runs are idempotent — GoReleaser attaches assets to the existing release without duplicating tap commits.
Do not delete the release to redo it. Deleting after the Homebrew tap was already pushed leaves the tap ahead of GitHub; recovery is messier than the original problem.
Do not re-tag. If the tag points at the right commit, rerun the workflow. Wrong commit is a separate problem worth capturing as a signal first.