@weotro/dx 0.1.11 → 0.1.13

package/skills/delivering-design-handoff/SKILL.md

@@ -1,290 +1,33 @@
 ---
 name: delivering-design-handoff
-description: 仅在用户显式调用 $delivering-design-handoff 或明确要求使用 delivering-design-handoff 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 delivering-design-handoff 时使用：整理设计、实施计划与工程交接资料。
 ---
 
 # Delivering Design Handoff
 
-## Overview
+## 执行边界与优先级
 
-Turn an approved design into a ready-to-assign engineering package with one closed loop: spec, spec review and fixes, implementation plan, plan review and fixes, handoff doc, issue, branch, commit, push, issue assignment comment, and copyable assignment text.
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
 
-**Core principle:** after the design is approved, the user should not have to restate the delivery choreography. Each review gate must be completed and fixed before the next artifact is written.
+把已有设计整理为可交给工程师实施的文档。沿用已讨论的方向；尚有局部空缺时写明假设并继续草稿，不重新启动整轮设计问答。
 
-## When To Use
+## 文档与检查
 
-Use this only after the solution direction is already approved. If the design is still being explored, first use `brainstorming`.
+按项目惯例选择路径；无既有约定时使用：
+- 设计：`docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`，说明目标、方案、接口、兼容性、风险与验收标准。
+- 计划：`docs/superpowers/plans/YYYY-MM-DD-<topic>.md`，列出涉及文件、实现顺序、关键接口与实际验证命令。
+- 交接：`docs/superpowers/handoffs/YYYY-MM-DD-<topic>-handoff.md`，提供文档链接、实施顺序、风险和完成标准。小任务可按用户或项目要求合并文档。
 
-Typical user asks:
+设计、计划和交接草稿可并行完善；交付前核对三者一致性，修正实际影响实施的缺口。根据复杂度选择自审或独立审查，已有有效审查可复用；审查工具不可用时自行检查并注明限制。仅在需要相应写作方法且技能可用时读取 `brainstorming` 或 `writing-plans` 的相关章节。
 
-- “把这个方案写成设计文档并提 issue”
-- “写计划和交接文档，提交到 issue 分支”
-- “后续不想重复输入，从设计文档到 issue/分支/提交都自动做”
-- “给我一段可以直接复制给工程师的任务分配文字”
+## 交付
 
-## Required Output Contract
+1. 检查相关项目指令、分支及本次涉及文件的状态，保护已有改动。
+2. 完成任务要求的文档，检查关键接口、验收标准和失效链接；真实未决项标明假设与影响。
+3. 需要 Issue、提交、推送或分配评论时，先准备正文与明确文件清单，再按任务授权执行。只要求本地交接时，本地文档即可完成。
+4. 需要分支时从项目规定的基线创建，保留现有工作；按明确路径暂存并检查 diff。多行正文用临时文件与 `--body-file` 或 `git commit -F` 传递。
+5. 已授权发布交接评论时，包含分支、提交、文档链接和可复制的任务分配文字，并读回核对。用户或项目要求 PR 时，纳入本次交付。
 
-By the end, produce all of these or clearly state the blocker:
-
-| Item | Required shape |
-| --- | --- |
-| Design spec | `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`, created using the design-doc discipline from `brainstorming` |
-| Spec adversarial review | Reviewer subagent completed before the plan exists; valid findings applied to the spec, or explicit rejected findings with reasons |
-| Implementation plan | `docs/superpowers/plans/YYYY-MM-DD-<topic>.md`, created by using `writing-plans` |
-| Plan adversarial review | Reviewer subagent findings applied to the plan, or explicit rejected findings with reasons |
-| Handoff doc | `docs/superpowers/handoffs/YYYY-MM-DD-<topic>-handoff.md` |
-| GitHub issue | Structured issue with background, goals, plan, acceptance criteria, and doc paths |
-| Issue branch | `codex/docs/<issue-id>-<slug>` for docs-only handoff, or matching repo convention |
-| Commit | Conventional commit ending with `Refs: #<issue-id>` |
-| Push | Branch pushed with upstream |
-| Issue comment | Comment linking branch, commit, spec, plan, and handoff, plus the same project-manager-style assignment block from the final answer |
-| Final answer | Short status plus a copyable project-manager-style assignment block |
-
-## Workflow
-
-### 1. Confirm starting state
-
-- Read project instructions: `AGENTS.md`, referenced ruler docs, and git workflow docs.
-- Check branch and worktree:
-
-```bash
-rtk git status --short --branch
-rtk git remote -v
-rtk gh auth status
-```
-
-- If there are unrelated dirty changes, do not overwrite them. If the handoff docs are the only dirty files, continue.
-
-### 2. Write the design spec
-
-Use `brainstorming` for the design-document phase. If the conversation already contains an approved design, do not restart exploratory questioning; treat that approved discussion as the input and apply `brainstorming`'s write-design-doc and self-review standards.
-
-Create `docs/superpowers/specs/YYYY-MM-DD-<topic>-design.md`.
-
-Spec sections:
-
-- Background
-- Goals
-- Non-goals
-- Chosen approach and rejected alternatives
-- Backend/frontend/data/API design as applicable
-- Error handling
-- Testing and verification
-- Compatibility and risks
-- Acceptance criteria
-
-Run a self-review:
-
-```bash
-rtk rg -n "TBD|TODO|待定|占位|\\.\\.\\." <spec-path>
-```
-
-Fix every hit that is a placeholder. A literal example such as `new BasePaginationResponseDto(total, page, limit, items)` is allowed; vague ellipses are not.
-
-### 3. Dispatch adversarial review
-
-Spawn one reviewer subagent. The prompt must include:
-
-- spec path
-- repo root
-- current approved design context
-- review axes: correctness, missing edge cases, repo convention violations, testability, and handoff ambiguity
-- “read-only, do not modify files”
-
-Apply all valid findings to the spec. If rejecting a finding, record the reason in the handoff doc's review notes and mention it briefly in the final answer only if material.
-
-**Gate before planning:** do not create the implementation plan until the reviewer subagent has returned, every valid spec finding has been fixed, every rejected finding has a recorded reason, and the spec placeholder scan has passed again. If the reviewer subagent is still running, timed out, or failed, this gate is not complete. If the user asks to save time by writing the plan while review or fixes are pending, decline that shortcut and finish this gate first.
-
-### 4. Create the implementation plan
-
-Announce and use `writing-plans`:
-
-> I'm using the writing-plans skill to create the implementation plan.
-
-Start this step only after Step 3 is complete.
-
-Create `docs/superpowers/plans/YYYY-MM-DD-<topic>.md` using the `writing-plans` required structure:
-
-- header with goal, architecture, tech stack, and global constraints
-- file map before tasks
-- bite-sized tasks with exact files, interfaces, steps, commands, and expected results
-- self-review for spec coverage, placeholders, and type consistency
-
-Run placeholder scan:
-
-```bash
-rtk rg -n "TBD|TODO|待定|占位|\\.\\.\\." <plan-path>
-```
-
-Fix every true placeholder. Do not proceed to handoff until the plan can guide an engineer without asking back.
-
-### 5. Dispatch plan adversarial review
-
-Spawn one reviewer subagent for the plan. The prompt must include:
-
-- spec path
-- plan path
-- repo root
-- review axes: spec coverage, task order, file ownership, testability, missing code/commands, placeholders, type/interface consistency, and repo convention violations
-- “read-only, do not modify files”
-
-Apply all valid findings to the plan. If a finding reveals a spec defect, fix the spec too and re-check plan consistency.
-
-### 6. Write the handoff document
-
-Create `docs/superpowers/handoffs/YYYY-MM-DD-<topic>-handoff.md`.
-
-This is separate from the implementation plan. It is the short assignment packet for a human engineer:
-
-- Issue title and eventual issue id placeholder until issue exists
-- branch name placeholder until branch exists
-- links/paths to spec and plan
-- why the work matters
-- implementation order summary
-- top risks and invariants
-- required verification commands
-- delivery boundary and acceptance checklist pointer
-
-Run placeholder scan over all docs. Placeholders that must be filled before commit, such as issue id after creation, must not remain.
-
-```bash
-rtk rg -n "TBD|TODO|待定|占位|\\.\\.\\." <spec-path> <plan-path> <handoff-path>
-```
-
-### 7. Create the GitHub issue
-
-Use heredoc, never `-m` or literal `\n`.
-
-Issue body must include:
-
-- Background
-- Goals
-- Plan
-- Acceptance criteria with objective checkboxes
-- Links or paths to the spec, implementation plan, and handoff doc
-
-Labels should match repo conventions. Prefer labels for backend/frontend/admin/database/api/docs when they exist.
-
-After issue creation, fill the concrete issue id and URL into the handoff doc if it used placeholders.
-
-### 8. Create the issue branch
-
-Fetch the base and create a clean issue branch:
-
-```bash
-rtk git fetch origin main --prune
-rtk git switch -c codex/docs/<issue-id>-<slug> origin/main
-```
-
-If the spec was created before switching, remember that untracked files usually follow the checkout but tracked edits may not. Verify both docs are present after the switch. If content disappears, recover it intentionally with `git show`, `git stash`, or re-apply the patch; never use destructive checkout/reset.
-
-After branch creation, fill the concrete branch name into the handoff doc if needed. Run final placeholder scan:
-
-```bash
-rtk rg -n "TBD|TODO|待定|占位|\\.\\.\\." <spec-path> <plan-path> <handoff-path>
-```
-
-### 9. Commit and push
-
-Stage only the intended docs:
-
-```bash
-rtk git add <spec-path> <plan-path> <handoff-path>
-rtk git diff --cached --stat
-rtk git diff --cached --check
-```
-
-Commit:
-
-```bash
-rtk git commit -F - <<'MSG'
-docs: add <topic> handoff
-
-变更说明：
-- 新增设计文档，固化已确认方案、风险、测试和验收标准。
-- 新增实施计划和交接文档，拆分实现任务、文件范围和验证命令。
-
-Refs: #<issue-id>
-MSG
-```
-
-Push:
-
-```bash
-rtk git push -u origin <branch>
-```
-
-Comment on the issue with branch, commit, spec path, plan path, handoff path, and the copyable project-manager-style assignment block from the final answer. This issue comment is mandatory; do not finish with only a local final answer.
-
-### 10. Do not create a pull request
-
-This skill stops after the handoff docs are committed, pushed to the remote issue branch, and linked from the GitHub issue comment. Do not create or update a PR for the docs-only handoff branch as part of this workflow, even when the repository's normal implementation flow expects PRs.
-
-If the user explicitly asks for a PR, treat that as a separate follow-up workflow after this handoff is complete.
-
-### 11. Final verification
-
-Before claiming completion, run:
-
-```bash
-rtk git status --short --branch
-rtk git log -1 --oneline
-rtk git rev-parse --abbrev-ref --symbolic-full-name @{u}
-```
-
-Report actual state. If no tests/builds were run because this is docs-only, say that.
-
-Read back the issue comments and verify that the latest handoff comment contains the branch, commit, spec path, plan path, handoff path, and the same assignment block shown in the final answer. If `gh issue comment` failed, the comment is missing, or the readback does not match the final assignment block, fix that before claiming completion.
-
-## Final Answer Template
-
-Keep it short, then include this copyable block:
-
-```markdown
-已准备好交接资料：
-
-- Issue：#<issue-id> <issue-url>
-- 分支：`<branch>`
-- 提交：`<sha> <subject>`
-- 设计文档：`<spec-path>`
-- 实施计划：`<plan-path>`
-- 交接文档：`<handoff-path>`
-
-以下交接评论已同步写入 Issue，可直接派发给开发工程师：
-
-请基于 `<branch>` 接手实现 Issue #<issue-id>：<issue-title>。
-
-先阅读：
-1. `<spec-path>`
-2. `<plan-path>`
-3. `<handoff-path>`
-
-实现时请按实施计划的 Task 顺序推进，并重点守住以下约束：
-- <top-risk-or-constraint-1>
-- <top-risk-or-constraint-2>
-- <top-risk-or-constraint-3>
-
-完成后请至少运行：
-- `<verification-command-1>`
-- `<verification-command-2>`
-- `<verification-command-3>`
-
-验收标准以 Issue #<issue-id> 的 checklist 为准。实现过程中如遇到与设计文档冲突的细节，先在 Issue 中同步风险和建议处理方式。
-```
-
-In Codex app, after successful git actions, also emit the app directives for branch creation, staging, commit, and push.
-
-## Common Mistakes
-
-- Writing the issue before the spec is stable and then forgetting to update links.
-- Writing the implementation plan before spec adversarial review has completed and valid findings have been fixed.
-- Skipping adversarial review because the spec “looks obvious”.
-- Treating the handoff doc as the implementation plan. The implementation plan must be produced with `writing-plans`, reviewed, and fixed before the handoff doc.
-- Skipping adversarial review of the implementation plan.
-- Creating the branch from the current stale feature branch instead of `origin/main`.
-- Committing on an unrelated branch.
-- Writing a handoff that says “add tests” without exact files, behaviors, and commands.
-- Forgetting the issue comment, leaving the receiving engineer to hunt for branch and docs.
-- Posting an issue comment with links only, but omitting the project-manager-style assignment block.
-- Creating or updating a PR for the docs-only handoff branch instead of stopping after commit, push, and issue comment.
-- Final answer lists artifacts but omits the copyable project-manager-style assignment block.
+最终给出实际产物链接、验证结果及简短可复制的交接文字：从哪个分支接手、先读什么、实施重点、验收命令。只报告实际完成的提交、推送和评论。

package/skills/delivering-design-handoff/agents/openai.yaml

@@ -0,0 +1,2 @@
+policy:
+  allow_implicit_invocation: false

package/skills/doctor/SKILL.md

@@ -1,10 +1,16 @@
 ---
 name: doctor
-description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 doctor 时使用：检查或修复本机 agent 开发环境。
 ---
 
 # Doctor
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 ## 概览
 
 本技能用于把当前机器调整到可稳定运行 agent 开发工作流的状态。
@@ -13,7 +19,7 @@ description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技
 
 ## 目标状态
 
-最终环境应尽量满足：
+完整环境体检时参考以下目标；单项修复仅检查目标工具及直接依赖，已有健康证据可复用：
 
 - `python3` 可用。
 - `python` 可调用 Python 3，或有清晰说明当前系统无需/不应创建该别名。
@@ -28,7 +34,7 @@ description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技
 
 ## 执行原则
 
-- 先诊断，再修复；不要未经确认就重复安装已经健康的工具。
+- 先诊断，再修复；健康工具直接复用，已明确需要的可回滚修复自主执行。
 - 优先使用系统已有的包管理器和用户态安装路径。
 - 遇到多个可行方案时，选择对系统影响最小、最容易回滚的方案。
 - 对需要管理员权限、网络下载或会修改 shell 配置的动作，执行前简短说明影响。
@@ -37,7 +43,7 @@ description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技
 
 ## 建议工作流
 
-1. 收集上下文：
+1. 按任务范围收集必要上下文；完整体检可检查：
    - 操作系统与架构
    - 当前 shell 与 PATH
    - `python3`、`python`、`node`、`npm`、`pnpm`、`dx`、`agent-browser`、`rg`、`gh`、`rtk` 的存在性与版本
@@ -46,12 +52,12 @@ description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技
 2. 对照目标状态判断缺口。
 3. 制定最小修复动作并执行。
 4. 每次修复后重新验证相关项。
-5. 所有项目完成后运行一次最终复检。
+5. 汇总已验证的结果，只补查仍缺证据或被后续修改影响的项。
 6. 输出报告。
 
 ## 验证要求
 
-最终复检至少覆盖：
+按本次修复范围选择验证项；完整体检覆盖下列适用项：
 
 - 每个目标命令是否可被当前 shell 找到。
 - 每个目标命令的版本或基本健康输出。

package/skills/doctor/agents/openai.yaml

@@ -0,0 +1,2 @@
+policy:
+  allow_implicit_invocation: false

package/skills/gh-dependabot-cleanup/SKILL.md

@@ -1,15 +1,21 @@
 ---
 name: gh-dependabot-cleanup
-description: 仅在用户显式调用 $gh-dependabot-cleanup 或明确要求使用 gh-dependabot-cleanup 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 gh-dependabot-cleanup 时使用：修复 Dependabot 安全告警。
 ---
 
 # GH Dependabot Cleanup
 
+## 执行边界与优先级
+
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
+
 ## Overview
 Use this skill to complete a Dependabot remediation loop with minimal manual input. Rely on `gh` directly, fix all patchable alerts in scope, and document unpatched alerts without auto-dismiss.
 
 ## Closed Loop Workflow
-1. Confirm target and scope in one sentence.
+1. Infer the repository and scope from the task and current remote, state the choice, and fetch evidence without waiting for reconfirmation.
 2. Fetch open alerts with `gh api`.
 3. Classify alerts into:
    - patchable: has `first_patched_version`
@@ -19,7 +25,7 @@ Use this skill to complete a Dependabot remediation loop with minimal manual inp
 5. Apply dependency changes (prefer overrides/resolutions for transitive alerts).
 6. Refresh lockfile.
 7. Run required project verification commands.
-8. Commit, push, and open exactly one PR.
+8. For an authorized PR delivery, commit, push, and open a focused PR; a local remediation request finishes with the verified local changes.
 9. Report residual risk (unpatched alerts) in PR and final reply.
 
 ## Default Commands
@@ -49,6 +55,3 @@ Include these sections:
 2. Remaining alerts: alert id, reason (for example, no upstream patch)
 3. Verification: exact commands run and outcomes
 4. Risk note: what is deferred and why
-
-## Fast Trigger
-修复安全警告

package/skills/git-release/SKILL.md

@@ -1,210 +1,50 @@
 ---
 name: git-release
-description: 仅在用户显式调用 $git-release 或明确要求使用 git-release 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+description: 仅在显式调用 git-release 时使用：准备或执行版本发布及回访审计。
 ---
 
 # Git Release
 
-## 目标
-
-在 `release/vX.Y.Z` 或 `release/vX.Y.Z-<prerelease>.N` 分支上，完成发布前检查、GitHub Release 创建和本次发布部署完成后的回访审计 Issue 建立；若当前不在 release 分支，则先从最新 `main` 自动创建目标 release 分支。
-
-## 执行原则
-
-- 全程使用中文输出。
-- 严格执行前置校验，任何硬性条件不满足时立即终止。
-- 发行说明必须结构化、可读、可追溯。
-- 发布完成必须留下一个可追踪的“部署完成后回访审计单” Issue；终端里临时打印 checklist 不算完成。
-- 回访 Issue 是审计本次 release 是否完整、正确落地的取证清单，不是部署操作手册。正文应围绕本次发布内容提出核对项，不编排部署步骤、命令顺序或服务器操作教程。
-- 本技能只编写回访审计 Issue，不执行生产验证。不得登录生产服务器、访问生产数据库、调用生产只读接口、查询生产监控或尝试取得生产凭据。
-- GitHub Release 创建成功不代表已经部署。所有需要部署完成后取证的审计项默认未勾选，留给运维或后续回访 agent 补充实际结果与证据。
-- 命令默认在仓库根目录执行。
-- 若能从当前 release 分支或自动建分支流程唯一推断出合法版本号，直接使用该版本继续发布，不要询问用户确认。
-
-## 流程
-
-### 一、发布前检查
-
-1. 检查工作区是否干净：`git status --porcelain`。
-2. 若存在未提交变更，列出文件并终止流程。
-3. 检查当前分支：`git branch --show-current`。
-4. 若当前分支不匹配 `^release/v\d+\.\d+\.\d+(-(alpha|beta|rc)\.\d+)?$`，执行以下自动建分支流程（仅此场景执行）：
-- 同步远程与本地 `main`：`git fetch origin main --tags && git checkout main && git pull --ff-only origin main`。
-- 获取上一个已发布版本（优先）：`gh release list --limit 1 --json tagName,publishedAt --jq '.[0].tagName'`；若为空则回退 `git describe --tags --abbrev=0`。
-- 解析版本号并将最后一位加一（例如 `v1.2.3 -> v1.2.4`），得到新分支版本 `<NEXT_VERSION>`。
-- 创建并切换分支：`git checkout -b release/v<NEXT_VERSION>`。
-5. 再次检查当前分支，必须匹配：`^release/v\d+\.\d+\.\d+(-(alpha|beta|rc)\.\d+)?$`。
-6. 从分支名提取版本号，例如：
-- `release/v1.2.3` -> `v1.2.3` -> `1.2.3`
-- `release/v1.2.3-beta.2` -> `v1.2.3-beta.2` -> `1.2.3-beta.2`
-7. 检查目标 tag 是否已存在：`git tag -l "v<VERSION>"`。
-8. 输出推断出的版本号和推断来源，直接使用该版本号继续执行；不要向用户请求确认。
-9. 仅当无法从分支名或自动建分支流程唯一推断出合法版本号时，终止并要求用户显式指定目标版本。
-
-### 二、更新版本号
-
-1. 更新以下文件的 `version` 字段为纯版本号（不带 `v` 前缀）：
-- `package.json`
-- `apps/backend/package.json`
-- `apps/front/package.json`
-- `apps/admin-front/package.json`
-2. 仅修改 `version` 字段，不变更其他内容。
-3. 执行提交：
+## 执行边界与优先级
 
-```bash
-git add package.json apps/*/package.json
-git commit -F - <<'MSG'
-chore: bump version to <VERSION>
-
-更新所有 package.json 版本号为 <VERSION>
-
-发布准备提交
-MSG
-```
-
-### 三、收集与分析变更
-
-1. 优先获取最近已发布版本：
-
-```bash
-gh release list --limit 1 --json tagName,publishedAt --jq '.[0].tagName'
-```
-
-2. 若无 GitHub Release，回退：`git describe --tags --abbrev=0`。
-3. 采集范围：`<last-release-tag>..HEAD`。
-4. 收集数据：
-- `git log <last-release-tag>..HEAD --oneline`
-- `git log <last-release-tag>..HEAD --pretty=format:"%H|%s|%b"`
-- `git diff <last-release-tag>..HEAD --shortstat`
-5. 从提交中提取 PR 编号（合并提交、Refs、Closes 等），并用 `gh pr view` 获取标题与标签。
-6. 去重同一 PR。
-7. 分类变更：
-- 新增：`feat` 或 feature 标签
-- 优化：`refactor`、`perf`、`chore`
-- 修复：`fix` 或 bug 标签
-- 技术改进：`docs`、`test`、`build`、`ci`
-8. 过滤噪音：忽略无意义合并记录与 `chore: bump version`。
-9. 识别运维提醒：环境变量、数据库迁移、依赖更新、配置与部署变更。
-
-### 四、生成发行说明
-
-1. 生成 3-5 条发布摘要，按业务影响排序。
-2. 输出分类变更清单，关联 PR 或 Issue。
-3. 使用以下结构：
-
-```markdown
-# v<VERSION> 发行说明
-
-## 发布摘要
-
-- <核心变更1> (#PR)
-- <核心变更2> (#PR)
-- <核心变更3> (#PR)
-
-发布日期：<YYYY-MM-DD>
-对比分支：`<last-tag>...v<VERSION>`
-
-## 新增
-
-- <新增项> (#PR)
-
-## 优化
-
-- <优化项> (#PR)
+在宿主系统与开发者指令约束内，冲突时依次采用：当前任务的具体要求与已有授权 > 目标项目适用的 AGENTS.md > 本技能及其引用的通用流程。
+只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
+仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
 
-## 修复
+## 发布准备
 
-- <修复项> (#PR)
+从当前 release 分支、用户指定版本或项目版本策略确定目标版本，说明来源。若项目采用 `release/vX.Y.Z`（也支持 alpha/beta/rc）则沿用；其他命名服从项目规则。没有版本策略时可以准备下一补丁版本的本地草稿，公开发布前核实目标。
 
-## 技术改进
+检查工作区、基线与目标 tag。无关未提交改动保留；需要干净发布环境时使用隔离 worktree，继续在原工作区读取与起草。版本格式错误、tag 指向冲突或缺少发布内容时先诊断可修复原因，阻止有问题的发布操作，继续可完成的准备工作。
 
-- <技术改进项> (#PR)
+从项目实际 manifest 与发布配置确定需要更新的包，仅修改本次发布的版本字段；不假设存在 `apps/backend` 等目录。按项目规定运行发布检查与相关测试，复用当前输入的有效结果。需要提交时按明确文件路径暂存并核对。
 
-## 运维提醒
+## 发行说明
 
-- <提醒项>
+优先从 GitHub Release 确定上次发布，必要时结合 tags 与项目策略确认基线。首次发布按项目约定确定范围。读取该基线到目标提交的日志、diff 摘要和相关 PR；仅对影响理解有必要的文件展开内容。
 
-## 引用
+说明实质变更、对应 PR/Issue、兼容性和升级注意事项；按实际内容分类，不填无关栏目。先在本地完成发行说明和回访审计草稿，便于核对后发布。
 
-- PRs：#1, #2
-- Issues：#10
-- 共计 <X> 个提交
+## 创建发布
 
-## 升级指南
-
-1. <步骤1>
-2. <步骤2>
-```
-
-### 五、创建发布
-
-1. 创建 annotated tag：
+推送 tag 和创建 Release 可能触发不可逆的制品发布或部署。在执行前核对目标仓库、版本、commit、发行说明及现有授权；授权已明确覆盖这些对象时直接继续，否则准备好具体结果再确认。
 
+按项目发布流程创建 tag、推送并创建 Release；例如：
 ```bash
 git tag -a v<VERSION> -m "Release v<VERSION>"
-```
-
-2. 推送 tag：
-
-```bash
 git push origin v<VERSION>
+gh release create v<VERSION> --title "v<VERSION>" --notes-file <notes-path>
 ```
+预发布版本按项目规则设置 prerelease 标记。部分失败时先读回远端状态，复用已创建的 tag/Release，仅补齐剩余步骤；不覆盖冲突 tag，也不盲目重放发布。
 
-3. 创建 GitHub Release：
-
-```bash
-gh release create v<VERSION> \
-  --title "v<VERSION>" \
-  --notes-file - <<'EOF'
-<完整发行说明>
-EOF
-```
-
-4. 读回 Release，确认 tag、标题、正文和 URL 正确：`gh release view v<VERSION> --json tagName,name,body,url,isDraft,isPrerelease`。
-
-### 六、创建部署完成后回访审计 Issue
-
-1. 完整读取 [发布后回访契约](references/post-release-follow-up.md)。
-2. 以本次 Release 说明、`<last-release-tag>..HEAD` 的提交与 diff、关联 PR/Issue 为主，按需读取仓库内的部署配置、迁移、运维脚本和 ops manifest，建立“发布内容 -> 受影响对象 -> 发布后风险/预期行为 -> 审计证据”的映射。不得通过 SSH、生产域名、数据库、监控平台、云平台 API 或私有环境配置验证当前生产状态。
-3. 自动创建一个“本次 release 部署完成后的回访审计单” Issue。逐项覆盖本次发布中的新增、优化、修复、技术改进和运维提醒；只有与本次变更相关时，才加入版本一致性、服务健康、迁移、脚本、数据、配置、可观测性、业务验收、回滚或延迟观察项。
-4. 每个审计项写清关联发布内容、审计对象、通过标准和应附的脱敏证据。使用“核对/确认/观察”的审计表述，不写“登录、执行、重启、部署”等操作步骤，也不提供部署命令或操作顺序。
-5. Issue 初始状态写为“待部署完成后回访”。所有依赖部署后事实的 checklist 保持未勾选；Release、tag 或 CI 的成功只能作为发布信息，不能代替生产落地证据。
-6. 使用 `gh issue view` 读回 Issue，确认没有占位符；发行说明中的每项实质变更均有对应审计项或明确的不适用说明；正文不存在通用部署手册式步骤；然后输出 Issue URL。
-
-## 终止条件
-
-以下任一情况出现时终止流程并给出明确原因：
-
-- 工作区存在未提交修改。
-- 当前分支不符合 release 分支命名规则，且无法从 `main` 自动创建 release 分支。
-- 版本号格式非法或与现有 tag 冲突。
-- 自上次发布以来无新提交。
-- 无法创建或读回部署完成后回访审计 Issue。
-
-## 输出模板
-
-### 发布前状态
+读回 `gh release view v<VERSION> --json tagName,name,body,url,isDraft,isPrerelease`，核对内容和目标提交后报告实际结果。
 
-- 工作目录状态
-- 当前分支
-- 解析出的版本号
-- 版本格式校验结果
-- tag 冲突校验结果
+## 发布后回访
 
-### 变更分析
+准备审计草稿时按需读取 [发布后回访契约](references/post-release-follow-up.md)。以本次变更映射受影响对象、预期行为、通过标准和脱敏证据；不是部署操作手册。
 
-- 基准版本
-- 提交范围
-- 提交数与 PR 数
-- 代码变更统计
-- 分类统计
+默认本技能只编写回访审计 Issue，不执行生产验证；用户另有只读取证任务时按该任务范围继续。发布成功不代表部署完成，依赖部署后事实的审计项保持未勾选。
 
-### 发布结果
+任务包含创建回访 Issue 时，发布成功后创建并读回，确认实质变更均有对应审计项或不适用说明。创建失败时保留草稿与已发布状态，修复可恢复错误，仅补做未完成的 Issue 操作。
 
-- 版本号
-- 分支名
-- tag 推送状态
-- Release URL
-- 预期部署环境、品牌与 target
-- 部署完成后回访审计 Issue URL
-- 待回访审计与待观察项目数量
+最终报告版本、目标提交、Release URL、验证结果和回访 Issue（或本地草稿）链接；区分发布成功、部署状态未知与未完成项。