@weotro/dx 0.1.18 → 0.1.19
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/package.json
CHANGED
|
@@ -25,8 +25,9 @@ Use this skill to complete a Dependabot remediation loop with minimal manual inp
|
|
|
25
25
|
5. Apply dependency changes (prefer overrides/resolutions for transitive alerts).
|
|
26
26
|
6. Refresh lockfile.
|
|
27
27
|
7. Run required project verification commands.
|
|
28
|
-
8. For
|
|
29
|
-
9.
|
|
28
|
+
8. For authorized issue and PR delivery, find and reuse a matching tracking issue or create one with the alert scope, remediation plan, and verification results. Commit, push, and open a focused PR linked to that issue. A local remediation request finishes with verified local changes and drafts for any requested delivery that still lacks authorization.
|
|
29
|
+
9. If the user requests merging, continue through the merge workflow below using the existing authorization; opening a PR alone does not complete that request.
|
|
30
|
+
10. Report the issue, PR, merge outcome, and residual risk using the final reply requirements below.
|
|
30
31
|
|
|
31
32
|
## Default Commands
|
|
32
33
|
```bash
|
|
@@ -51,7 +52,18 @@ pnpm install --lockfile-only
|
|
|
51
52
|
|
|
52
53
|
## PR Requirements
|
|
53
54
|
Include these sections:
|
|
54
|
-
1.
|
|
55
|
-
2.
|
|
56
|
-
3.
|
|
57
|
-
4.
|
|
55
|
+
1. Tracking issue: issue number and URL; use `Closes #<issue>` only when the PR completes the issue's entire scope. Otherwise use `Refs #<issue>` and keep the remaining work tracked.
|
|
56
|
+
2. Fixed alerts: alert id, package, target version
|
|
57
|
+
3. Remaining alerts: alert id, reason (for example, no upstream patch)
|
|
58
|
+
4. Verification: exact commands run and outcomes
|
|
59
|
+
5. Risk note: what is deferred and why
|
|
60
|
+
|
|
61
|
+
## Merge Workflow
|
|
62
|
+
- Before merging, verify the PR's current head, required checks, review requirements, and mergeability. Follow the repository's merge strategy and branch protection; do not bypass required checks or reviews.
|
|
63
|
+
- When merge is authorized and requirements pass, merge with `gh pr merge`, binding the operation to the verified head via `--match-head-commit`. If the head changes, verify the new head before retrying.
|
|
64
|
+
- If checks or reviews block merging, resolve actionable failures within scope and recheck. Report any remaining blocker precisely. Enabling auto-merge or entering a merge queue is pending, not a completed merge.
|
|
65
|
+
- After merging, verify the PR's `MERGED` state and merge commit, check the tracking issue's state, and fetch Dependabot alerts again. Report still-open alerts as observed; distinguish scan results that have not yet updated from confirmed remediation failures.
|
|
66
|
+
|
|
67
|
+
## Final Reply Requirements
|
|
68
|
+
Always explicitly mention both **Issue** and **PR**, including their numbers, URLs, and observed states. If either was not created or reused, say so and explain why; never substitute a Dependabot alert number for an issue number.
|
|
69
|
+
State whether the PR was actually merged, with the merge commit when available, or give the concrete pending condition or blocker. Include verification results and remaining alerts. Do not claim completion of a requested merge based only on PR creation, auto-merge configuration, or queue entry.
|
|
@@ -11,6 +11,8 @@ description: 仅在显式调用 git-release 时使用：准备或执行版本发
|
|
|
11
11
|
只读检索、本地草稿、可回滚编辑和常规测试可自主推断并继续；从相关文件和直接依赖开始，仅在证据不足或影响跨模块时扩大范围，复用仍有效的验证。
|
|
12
12
|
仅在不可逆或难以回滚的修改缺少具体授权时，先完成预览、草稿与验证，再说明对象和影响并等待确认；会话中已有授权继续有效。缺少事实时先查证、标注假设并推进独立工作，确实无法确定操作目标时才询问。对外发送消息须有明确授权。
|
|
13
13
|
|
|
14
|
+
用户显式调用本技能执行发布，即明确授权在本次目标仓库创建并推送目标版本的 tag，以及创建并发布对应的 GitHub Release。完成准备和验证后连续执行至发布结果核验，无需再次询问是否推送 tag 或创建 Release。用户明确限定为仅准备、草稿、审计或修改技能时，按该范围执行；本授权不包含覆盖冲突 tag、删除既有 Release 或额外的生产操作。
|
|
15
|
+
|
|
14
16
|
## 发布准备
|
|
15
17
|
|
|
16
18
|
从当前 release 分支、用户指定版本或项目版本策略确定目标版本，说明来源。若项目采用 `release/vX.Y.Z`（也支持 alpha/beta/rc）则沿用；其他命名服从项目规则。没有版本策略时可以准备下一补丁版本的本地草稿，公开发布前核实目标。
|
|
@@ -27,7 +29,7 @@ description: 仅在显式调用 git-release 时使用：准备或执行版本发
|
|
|
27
29
|
|
|
28
30
|
## 创建发布
|
|
29
31
|
|
|
30
|
-
|
|
32
|
+
执行前核对目标仓库、版本、commit 和发行说明，确认发布检查通过、目标 tag 无冲突，然后依据「执行边界与优先级」中的明确授权直接推送 tag 并创建 GitHub Release。发布流程可能自动触发制品发布或部署，不因此追加确认步骤；仅在目标无法确定、检查失败或远端状态冲突时暂停受阻操作并说明原因。
|
|
31
33
|
|
|
32
34
|
按项目发布流程创建 tag、推送并创建 Release；例如：
|
|
33
35
|
```bash
|