@weotro/dx 0.1.0

package/package.json

@@ -0,0 +1,45 @@
+{
+  "name": "@weotro/dx",
+  "version": "0.1.0",
+  "type": "module",
+  "license": "MIT",
+  "repository": {
+    "type": "git",
+    "url": "git+ssh://git@github.com/rangershi/dx.git"
+  },
+  "bugs": {
+    "url": "https://github.com/rangershi/dx/issues"
+  },
+  "homepage": "https://github.com/rangershi/dx#readme",
+  "bin": {
+    "dx": "bin/dx.js",
+    "dx-with-version-env": "bin/dx-with-version-env.js"
+  },
+  "files": [
+    "bin/",
+    "lib/",
+    "skills/",
+    "LICENSE",
+    "README.md",
+    "package.json"
+  ],
+  "publishConfig": {
+    "access": "public"
+  },
+  "dependencies": {
+    "strip-json-comments": "^5.0.3",
+    "yaml": "^2.8.1"
+  },
+  "devDependencies": {
+    "jest": "^29.7.0",
+    "nx": "22.4.4"
+  },
+  "scripts": {
+    "test": "NODE_OPTIONS=--experimental-vm-modules jest"
+  },
+  "engines": {
+    "node": ">=20.11.0"
+  },
+  "nx": {},
+  "packageManager": "pnpm@10.30.0+sha512.2b5753de015d480eeb88f5b5b61e0051f05b4301808a82ec8b840c9d2adf7748eb352c83f5c1593ca703ff1017295bc3fdd3119abb9686efc96b9fcb18200937"
+}

package/skills/create-issue/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: create-issue
+description: 仅在用户显式调用 $create-issue、/create-issue 或明确要求使用 create-issue 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+---
+
+# Create Issue
+
+## Overview
+
+Turn a converged discussion into issue(s) that read like **an architect handing a spec to a programmer**: the programmer can locate the work, understand the plan without asking back, and verify done objectively — without the user re-issuing instructions each time.
+
+**Core principle — write it as a task dispatch, not a bug note.** Every issue must let a programmer execute end-to-end on first read. That means three things per finding:
+1. **Stable location** — anchor to a durable identifier (`file` + function/class/symbol/section name, or a short quoted snippet). Line numbers are a *navigation hint only*, always approximate, never the anchor — code shifts and a hard line pin rots immediately and over-constrains the fix.
+2. **An unambiguous plan** — what to change and why, with no decision left dangling that forces the programmer to come back and ask.
+3. **An objective acceptance check** — verifiable by behavior/text/data-state plus a runnable command where applicable.
+
+An issue that says "the button is wrong" forces the developer to re-investigate what you already know. An issue pinned to `Button.tsx:42` sends them to the wrong line after one edit. Anchor by symbol, plan the work, define done.
+
+**Manual-only:** this skill NEVER auto-triggers on keywords (提issue / file an issue / etc.). Run it only when the user explicitly invokes `/create-issue` or names the skill.
+
+## When to Use
+
+Only on explicit invocation. Appropriate when a review/investigation has converged — you've already located code and compared against a source of truth, and actionable items emerged.
+
+**Not for:** still-exploring discussions, trivial one-line fixes the user is about to do themselves, or vague ideas with no verifiable outcome.
+
+## Workflow
+
+1. **Probe the repo's issue conventions first.** Read `CONTRIBUTING`, issue templates (`.github/`), or any `git-workflow`/ruler docs; skim a recent `gh issue list`. Match their template, labels, title style. Never hardcode another repo's format.
+2. **Group issues:**
+   - **3+ issues → always auto-create one parent/umbrella tracking issue + child issues. Do NOT ask, do NOT discuss.** Children link back with `Refs: #<parent>`; the parent lists children as a checklist and holds the cross-issue map.
+   - **Fewer than 3 → apply the Merge vs. Split table.** Confirm via AskUserQuestion only when genuinely ambiguous; otherwise state the default and proceed.
+3. **Anchor every finding to a stable location.** Anchor by `file` + durable identifier (function/class/method/symbol name, or a short quoted snippet), NOT by a hard line number. A line number may ride along as an approximate hint (`Button.tsx · onSubmit() (~L42)`), but the symbol is the anchor — it survives edits, a line pin doesn't. Pair each with its source-of-truth location (design section, spec criterion). Present as a table: `维度 | 期望(真源) | 现状(代码) | 位置(符号/锚点)`.
+4. **Plan the work like an architect.** State the intended approach so a programmer can execute without coming back to ask. Resolve the decisions you can already resolve; for genuinely open ones, say so explicitly and give the constraint/tradeoff rather than leaving a silent gap. Name the shared root cause once. Avoid ambiguity: if a phrasing could be read two ways, rewrite it.
+5. **Draw the boundary.** Explicitly list what's OUT of scope, what stays unchanged, and any knock-on effects on other files/modules — so the developer doesn't "fix" intentional things or miss a ripple. Call out adjacent code the change must NOT break.
+6. **Make acceptance criteria objective.** Each checkbox judges ONE thing, verifiable by behavior/text/data-state PLUS a runnable command (lint/build/test) where applicable. No "code is cleaner" subjective items.
+7. **Create via heredoc**, not `-m`/`--body` single-line (literal `\n` won't become newlines). Title in Conventional Commits style. For plain ordinals use `A1`/`第1项`/`` `#1` `` — never bare `#1`/`#2` (GitHub resolves them to issue links).
+8. **Review created issues — both plan AND code (MANDATORY).** After ALL issues are created, dispatch a subagent to audit them (see section below). The audit has TWO jobs: (a) verify claims match the codebase, and (b) read each issue as the programmer who'll execute it and flag any plan-level defect — ambiguity, missing decision, wrong/risky approach, undefined scope. Fix EVERY problem it reports via `gh issue edit` before reporting done.
+9. **Report back** the created URL(s) + one-line grouping/boundary summary + what the review found and fixed.
+
+## Post-Creation Review (mandatory)
+
+After creating every issue, dispatch a subagent (Explore or general-purpose). Hand it the issue numbers/URLs and have it run BOTH passes below per issue. Reading code consistency alone is not enough — a factually-correct issue can still be unexecutable.
+
+**Pass A — Code consistency (does it match reality?):**
+- Every location anchor (file + symbol) actually exists and points at the claimed code. (Don't fail an issue over a stale line-number hint — anchors are symbols; line numbers are approximate by design.)
+- Each acceptance criterion is objectively verifiable (a real command / path / behavior), not aspirational.
+- Claims about current state (bugs, missing permissions/config, signatures) are true in the code TODAY.
+- No finding contradicts the codebase or describes work already done.
+
+**Pass B — Plan soundness (read it as the assigned programmer):** Ask "could I execute this start-to-finish without coming back to ask a question?"
+- **Ambiguity:** any sentence open to two readings; vague pronouns; "fix the handling" with no defined target behavior.
+- **Missing decision:** the issue defers a choice it should have made (which API, which file, which pattern) and leaves the programmer guessing.
+- **Wrong/risky approach:** the proposed plan would break adjacent code, fight an existing convention (check ruler/CLAUDE.md), or pick a clearly worse path.
+- **Undefined scope/boundary:** no out-of-scope statement, or knock-on effects on other modules not called out.
+- **Acceptance ≠ goal:** the checkboxes, even if objective, don't actually prove the stated goal is met.
+- **Structural:** `Refs:`/parent links correct; no bare `#n` ordinal mis-links; 3+ issues have an umbrella.
+
+The subagent returns a per-issue defect list spanning both passes. **You MUST fix ALL reported problems** via `gh issue edit` (heredoc), then re-verify. Do not report the task complete while any reported problem stands unfixed.
+
+## Merge vs. Split (only when <3 issues)
+
+| Signal | Action |
+|--------|--------|
+| Same component / source-of-truth target / change cycle, mutually non-blocking | One issue, internal groups (A/B/C) |
+| Different host (e.g. web vs. mobile/Flutter), independent tracking/rollback, one item far heavier | Split, link with `Refs:` |
+| User explicitly asks to split/merge | Follow user, link related ones |
+
+## Common Mistakes
+
+- **Pinning to a hard line number** → after one edit the anchor points at the wrong code and over-constrains the fix. Anchor by file + symbol; line numbers are an approximate hint only.
+- **Filename with no symbol anchor at all** → developer re-hunts. Always name the function/class/section.
+- **Writing a bug note, not a task spec** → "X is wrong" with no plan leaves the programmer to redesign. State the intended approach.
+- **Leaving a decision dangling** → "handle this better" forces a round-trip question. Resolve it, or state the constraint explicitly if genuinely open.
+- **Acceptance criteria all subjective/visual** → not verifiable. Attach a command or observable behavior.
+- **Acceptance that doesn't prove the goal** → objective but checks the wrong thing. Tie each checkbox to the stated goal.
+- **Asking about grouping for 3+ issues** → don't. Auto-create umbrella + children.
+- **Post-creation review only checks code, not the plan** → ships factually-correct but unexecutable/ambiguous issues. Run BOTH passes (code consistency + plan soundness).
+- **No out-of-scope section** → developer changes intentional things or misses a ripple. Always state the boundary and knock-on effects.
+- **`-m "...\n..."`** → literal `\n` in the issue body. Use heredoc `--body-file -`.
+- **Bare `#1`/`#2` for ordinals** → GitHub mis-links them. Use `A1` / backticks.
+
+## Red Flags — stop and fix before reporting done
+
+- About to anchor a finding to a bare line number, or with no symbol/source-of-truth reference at all.
+- The issue describes what's wrong but not what to do about it — a programmer would have to design the fix from scratch.
+- A sentence in the issue could be read two ways, or defers a decision the issue should have made.
+- An acceptance checkbox you can't verify by running something or observing a concrete state — or that doesn't actually prove the goal.
+- 3+ issues created without an umbrella, or related issues without `Refs:`.
+- Reported done without running BOTH review passes (code + plan) and fixing every finding.

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

@@ -0,0 +1,290 @@
+---
+name: delivering-design-handoff
+description: 仅在用户显式调用 $delivering-design-handoff 或明确要求使用 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.
+
+**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`.
+
+Typical user asks:
+
+- “把这个方案写成设计文档并提 issue”
+- “写计划和交接文档，提交到 issue 分支”
+- “后续不想重复输入，从设计文档到 issue/分支/提交都自动做”
+- “给我一段可以直接复制给工程师的任务分配文字”
+
+## Required Output Contract
+
+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/doctor/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: doctor
+description: 仅在用户显式调用 $doctor 或明确要求使用 doctor 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+---
+
+# Doctor
+
+## 概览
+
+本技能用于把当前机器调整到可稳定运行 agent 开发工作流的状态。
+
+不要把执行路径写死。模型应先识别当前系统、shell、包管理器、已有工具版本与用户权限，再自行选择最合适的检测和修复方式。完成修复后必须复检，并给出可读报告。
+
+## 目标状态
+
+最终环境应尽量满足：
+
+- `python3` 可用。
+- `python` 可调用 Python 3，或有清晰说明当前系统无需/不应创建该别名。
+- `node`、`npm`、`pnpm` 可用，且满足当前工作流需要。
+- `dx` 可用，并已完成必要初始化。
+- `agent-browser` 可用，且 Chromium/浏览器依赖已安装到可运行状态。
+- `rg`（rip grep）可用。
+- `gh`（GitHub CLI）可用；若当前工作流需要 GitHub 操作，还应完成认证。
+- `rtk` 可用，且明确是 [rtk-ai/rtk](https://github.com/rtk-ai/rtk)；不能把其他同名二进制当作通过。
+- [rtk-ai/rtk](https://github.com/rtk-ai/rtk) 已分别完成 Codex CLI 与 Claude Code 的初始化。
+- 常用 PATH 配置在当前 shell 中可生效；若需要持久化，说明写入了哪个 shell 配置文件。
+
+## 执行原则
+
+- 先诊断，再修复；不要未经确认就重复安装已经健康的工具。
+- 优先使用系统已有的包管理器和用户态安装路径。
+- 遇到多个可行方案时，选择对系统影响最小、最容易回滚的方案。
+- 对需要管理员权限、网络下载或会修改 shell 配置的动作，执行前简短说明影响。
+- 不要求固定轮次；根据实际结果迭代，直到通过验收或明确无法继续。
+- 不要强制执行远程安装文档。只有当诊断显示确实需要外部安装指引时，才读取可信来源并按实际情况采用。
+
+## 建议工作流
+
+1. 收集上下文：
+   - 操作系统与架构
+   - 当前 shell 与 PATH
+   - `python3`、`python`、`node`、`npm`、`pnpm`、`dx`、`agent-browser`、`rg`、`gh`、`rtk` 的存在性与版本
+   - `gh` 的认证状态（例如 `gh auth status`）
+   - `rtk` 是否为 [rtk-ai/rtk](https://github.com/rtk-ai/rtk)，以及它对 Codex CLI 与 Claude Code 的初始化状态
+2. 对照目标状态判断缺口。
+3. 制定最小修复动作并执行。
+4. 每次修复后重新验证相关项。
+5. 所有项目完成后运行一次最终复检。
+6. 输出报告。
+
+## 验证要求
+
+最终复检至少覆盖：
+
+- 每个目标命令是否可被当前 shell 找到。
+- 每个目标命令的版本或基本健康输出。
+- `dx` 的初始化结果或当前初始化状态。
+- `gh --version` 能正常运行；若需要 GitHub 操作，`gh auth status` 应显示可用账号，否则报告未认证原因。
+- `rtk` 必须确认来源为 [rtk-ai/rtk](https://github.com/rtk-ai/rtk)。至少用 `rtk --version`、`rtk --help`、安装来源或命令特征交叉验证；若发现同名非 rtk-ai/rtk 工具，判定为未通过。
+- [rtk-ai/rtk](https://github.com/rtk-ai/rtk) 的 `rtk gain` 能正常运行。
+- [rtk-ai/rtk](https://github.com/rtk-ai/rtk) 的 Codex CLI 初始化必须有明确证据。优先使用 `rtk init --show --codex`，确认全局或本地 Codex 配置已包含 `RTK.md` 与 `AGENTS.md` 引用；若当前 `rtk` 版本命令不同，使用等价的只读检查并在报告中说明。
+- [rtk-ai/rtk](https://github.com/rtk-ai/rtk) 的 Claude Code 初始化必须有明确证据。优先使用 `rtk init --show --agent claude`，确认 Claude Code hook、`RTK.md`、`CLAUDE.md` 引用与 `settings.json` hook 配置处于健康状态；若当前 `rtk` 版本命令不同，使用等价的只读检查并在报告中说明。
+- `agent-browser` 是否能找到并使用已安装的浏览器依赖。
+- 对未通过项给出失败原因、已尝试动作和下一步建议。
+
+## 报告格式
+
+最终报告使用中文，至少包含：
+
+- 环境摘要：系统、shell、关键 PATH 变更。
+- 检查结果表：检查项、状态、版本/证据、说明。
+- RTK 初始化：分别列出 Codex CLI 与 Claude Code 的检查命令、通过/失败状态、关键证据文件或 hook。
+- 已执行修复：实际执行过的安装、链接、初始化或配置变更。
+- 未完成项：若存在，说明阻塞原因和用户需要做什么。
+- 结论：通过 / 部分通过 / 未通过。

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

@@ -0,0 +1,54 @@
+---
+name: gh-dependabot-cleanup
+description: 仅在用户显式调用 $gh-dependabot-cleanup 或明确要求使用 gh-dependabot-cleanup 技能时使用；不要通过关键词、任务类型或上下文自动触发。
+---
+
+# GH Dependabot Cleanup
+
+## 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.
+2. Fetch open alerts with `gh api`.
+3. Classify alerts into:
+   - patchable: has `first_patched_version`
+   - unpatched: no `first_patched_version`
+   - direct vs transitive
+4. Announce remediation plan before edits.
+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.
+9. Report residual risk (unpatched alerts) in PR and final reply.
+
+## Default Commands
+```bash
+# 1) Fetch open alerts JSON
+gh api -H 'Accept: application/vnd.github+json' \
+  '/repos/OWNER/REPO/dependabot/alerts?state=open&per_page=100'
+
+# 2) Tabular triage view
+gh api -H 'Accept: application/vnd.github+json' \
+  '/repos/OWNER/REPO/dependabot/alerts?state=open&per_page=100' \
+  | jq -r '.[] | [.number, .security_vulnerability.package.name, .dependency.relationship, .security_advisory.severity, (.security_vulnerability.first_patched_version.identifier // "none"), .security_vulnerability.vulnerable_version_range, .html_url] | @tsv'
+
+# 3) Typical lock refresh (adapt to repo)
+pnpm install --lockfile-only
+```
+
+## Decision Rules
+- Keep unpatched alerts open by default; do not dismiss unless explicitly requested.
+- If one package maps to multiple alerts, upgrade once to the highest required safe version.
+- Keep the PR focused on security dependency remediation only.
+- If repo has branch/issue conventions, follow them strictly.
+
+## PR Requirements
+Include these sections:
+1. Fixed alerts: alert id, package, target version
+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/gh-dependabot-cleanup/agents/openai.yaml

@@ -0,0 +1,7 @@
+interface:
+  display_name: "Dependabot Cleanup PR"
+  short_description: "Fix GitHub Dependabot alerts in one PR workflow"
+  default_prompt: "Use $gh-dependabot-cleanup to remediate open Dependabot alerts and create one PR."
+
+policy:
+  allow_implicit_invocation: false