release-brief
从一个 issue 和一段 diff 生成结构化发布摘要，固化“读 issue → 读 diff → 归类改动 → 评估风险 → 写验证步骤”的重复工作流。
git clone --depth 1 https://github.com/LearnPrompt/LearnPrompt /tmp/release-brief && cp -r /tmp/release-brief/research/articles/skills-hooks-mcp-roles/showcase/release-workbench/skills/release-brief ~/.claude/skills/release-briefSKILL.md
# release-brief 当需要把「一个已关闭的 issue」和「一段已合并的 diff」变成对外可读的发布摘要时，按下面的固定步骤执行，不要临场发挥顺序。 ## 触发条件 - 输入里同时存在一个 issue 标识（例如 `LP-42`）和一段 diff 或变更文件列表。 - 目标是产出发布摘要，而不是继续写代码。 ## 固定步骤 1. 读 issue：提取标题、问题描述与验收标准。 2. 读 diff：列出被改动的文件与关键函数。 3. 归类改动：区分是缺陷修复、功能新增还是纯重构。 4. 评估风险：指出回归面与需要人工确认的点。 5. 写验证步骤：给出可复制的复现或回归命令。 ## 输出契约 生成的发布摘要必须是一个 JSON 对象，且包含以下字段，缺一不可： - `issue`：issue 标识字符串。 - `summary`：一句话说明这次发布做了什么。 - `change_type`：`fix` / `feature` / `refactor` 之一。 - `risk`：风险说明，至少一句。 - `verification`：字符串数组，至少一条可执行验证命令。 ## 反例 - 只写 `summary` 而不给 `verification`：契约检查会失败。 - 把顺序打乱、先写风险再猜 issue 内容：违反固定步骤，产出不可复用。
Create or rewrite exactly one LearnPrompt Starlight MDX tutorial to the repository's golden-sample standard, with bottom-of-page auditable sources instead of SourceCard, a research pack, evidence ledger, reproducible showcase, independent review, quality score, and successful site build. Use for one LearnPrompt article, tutorial, chapter, or MDX page; in batch goals, invoke once per topic in an isolated task.
Read a read-only release feed over HTTP, enforce an auditable request contract, and write redacted JSON and Markdown reports. Use when the task is to inspect releases from a REST endpoint without mutating upstream state.
Inspect a small npm CLI release candidate and produce a row-by-row release-readiness checklist report with evidence, pass rules, severity, N/A policy, and a final gate. Use when the task is to review a release candidate without publishing it.
Save a shared web link as a clean Obsidian note. Use when the user gives a URL and asks to save, clip, or archive it into their Obsidian vault as a markdown note with title, source, and summary.
Migrate three legacy Markdown docs into Starlight-compatible migration candidates inside an isolated temp repo. Use when you need stage receipts, crash recovery, resume validation, or deterministic candidate packaging without touching real user docs.
Distill a candidate skill from observable repair receipts, then prove it on holdout fixtures. Use when you have repeated accepted patches, corrections, and validator results, but do not have permission to use private transcripts or hidden chain-of-thought.
Repair synthetic MDX frontmatter when title, description, or sidebar.order drift from the frontmatter contract. Use for files that follow the same observable patterns proven in the receipts; do not use on private transcripts, secret-bearing material, or arbitrary YAML.
Prepare a dry-run rename plan for a batch of receipt PDFs. Use when the user wants repository-style receipt filenames normalized under the local naming policy without renaming files yet.