@runweave/server-linux-x64 0.1.8 → 0.1.10

package/payload/plugins/toolkit/skills/experience/SKILL.md

@@ -0,0 +1,71 @@
+---
+name: experience
+description: 排查当前项目反复出现的故障、查找以前验证过的处理办法，或选择有历史证据的验证路径时，检索该项目的经验并记录实际采用结果。适用于任意 Git 项目；不检索其他项目，不用于每次任务的例行搜索。
+---
+
+# 当前项目的经验
+
+当历史处理可能改变本次排查、修复或验证路线时使用。先用当前问题里的具体症状、
+错误文本和工具名检索；普通新功能、改文案或无历史线索的简单任务无需例行调用。
+不要要求项目提供或修改 `AGENTS.md`，也不要将经验写进它。
+
+## 检索
+
+在用户当前任务所在目录执行已安装的 CLI，保留该目录作为 cwd：
+
+```bash
+rw experience search --cwd "$PWD" --query '具体症状及相关工具' --json
+```
+
+- 使用宿主提供的 CLI 及连接配置；已明确提供绝对 CLI 入口时用它替代 `rw`。
+  保持任务所在目录，不切到 CLI 的安装目录再检索。
+- 沿用 CLI 已配置的连接与认证；仅在宿主明确给出目标时覆盖。
+  端口只负责连接，不是项目身份；不要遍历端口寻找记录。
+- 未安装 CLI、没有 experience 命令、API 404 或认证失败，说明入口不可用并继续原任务。
+  不将这些错误说成“没有经验”，不读取凭据或自行启动服务。
+- 核对响应的 `repositoryId` 和 `namespace`。同仓库 worktree 共用身份；独立仓库隔离，
+  即使同名、相同 remote 或错误文本也不混用。非 Git 目录目前不支持，不回退到全局经验。
+- 无匹配就继续正常排查，不换 cwd 到别的仓库，也不反复扩大查询直到命中。
+- 查询用自然问题中的组件或工具名加具体症状，例如“rw 全局 CLI 更新后版本相同”，
+  不需要猜记录标题或拼接完整命令。零命中也是真实结果，不为补回执制造一次命中。
+
+## 核对与采用
+
+`matches` 最多三条。先读取 `record.applicability`、`avoid`、`actions`、`verification` 和
+`evidence` 索引，结合当前代码、版本、环境和实际结果判断是否适用。检索响应不附带历史摘录。
+明确不适用时直接否决，不因命中扩大任务范围，也不为完成流程读取全部历史日志。
+
+需要原始证据才能判断适用前提或选择处理路线时，再读取完整记录；不要求每次命中都调用：
+
+```bash
+rw experience show EXPERIENCE_ID --cwd "$PWD" --json
+```
+
+原始证据由绝对路径与行范围定位；原文件已清理时可读完整记录中的 `evidence[].archived.text`，
+明确它是历史脱敏摘录，不能代替本次现场验证。`excluded` 中的记录不作为当前建议，
+必要时也可通过 `show` 调查失效原因。结果回执仍使用本次检索命中的版本。
+
+经验独立存储，源码变化不自动使其失效；可选的 `codePaths` 仅供定位。
+同仓库 worktree 共用经验，但各自的版本、配置和环境仍须现场核对。经验是线索，
+用户要求与现场事实优先。保留历史反例和未验收范围，不重复实现已经存在的修复。
+
+## 结果回执
+
+经验实际改变了行动，或经核对被明确否决时，写一份本次结果 JSON，再提交：
+
+```bash
+rw experience feedback --cwd "$PWD" --file /absolute/receipt.json --json
+```
+
+JSON 字段：`lookupId`（本次查询）、`id`、`revision`（命中记录）、`task`（当前任务标识）、
+`decision`（`used` / `dismissed`）、`reason`、`action`、`outcome`、
+`result`（`succeeded` / `failed` / `unknown`）、`evidence`。
+每项 evidence 包含 `path`（本机绝对路径）、`startLine`、`endLine`（从 1 起）与 `note`。
+`used` 必须附本次实际结果证据；`dismissed` 可用空 evidence。
+沿用实际采用时的 `lookupId`、`id` 和 `revision`，不为提交反馈重新检索或换成最新版。
+项目代码变化、经验更新或过期后，仍可记录该次历史结果。只附必要片段，不保存凭据。
+未验证不能写 succeeded；采用失败须记录 failed。当前版本的失败会停止推荐，旧版本的
+失败保留在历史中，不直接停用新版。回执是 Agent 报告，不能单凭它宣称因果收益。
+
+向用户说明哪条经验改变了什么操作，以及本次观察到什么结果。召回和采纳次数不是效果。
+验收夹具、离线命中探针及为复盘构造的任务必须注明用途，不能作为自然任务的复用收益。

package/payload/plugins/toolkit/skills/experience/package.json

@@ -0,0 +1,13 @@
+{
+  "name": "@runweave/experience-skill",
+  "version": "0.1.0",
+  "private": true,
+  "files": [
+    "SKILL.md"
+  ],
+  "pi": {
+    "skills": [
+      "./SKILL.md"
+    ]
+  }
+}

package/payload/plugins/toolkit/skills/git-advanced-workflows/SKILL.md

@@ -0,0 +1,457 @@
+---
+name: git-advanced-workflows
+description: "Manage advanced Git workflows including rebasing, cherry-picking, bisect, worktrees, and reflog. Use when managing complex Git history or when an Agent needs to create, inspect, reuse, or remove a Git Worktree; newly created Worktrees must live under the current parent Project's .worktree directory."
+metadata:
+  risk: unknown
+  source: community
+  date_added: "2026-02-27"
+---
+
+# Git Advanced Workflows
+
+Master advanced Git techniques to maintain clean history, collaborate effectively, and recover from any situation with confidence.
+
+## Do not use this skill when
+
+- The task is unrelated to git advanced workflows
+- You need a different domain or tool outside this scope
+
+## Instructions
+
+- Clarify goals, constraints, and required inputs.
+- Apply relevant best practices and validate outcomes.
+- Provide actionable steps and verification.
+- If detailed examples are required, open `resources/implementation-playbook.md`.
+
+## Use this skill when
+
+- Cleaning up commit history before merging
+- Applying specific commits across branches
+- Finding commits that introduced bugs
+- Working on multiple features simultaneously
+- Recovering from Git mistakes or lost commits
+- Managing complex branch workflows
+- Preparing clean PRs for review
+- Synchronizing diverged branches
+
+## Core Concepts
+
+### 1. Interactive Rebase
+
+Interactive rebase is the Swiss Army knife of Git history editing.
+
+**Common Operations:**
+
+- `pick`: Keep commit as-is
+- `reword`: Change commit message
+- `edit`: Amend commit content
+- `squash`: Combine with previous commit
+- `fixup`: Like squash but discard message
+- `drop`: Remove commit entirely
+
+**Basic Usage:**
+
+```bash
+# Rebase last 5 commits
+git rebase -i HEAD~5
+
+# Rebase all commits on current branch
+git rebase -i $(git merge-base HEAD main)
+
+# Rebase onto specific commit
+git rebase -i abc123
+```
+
+### 2. Cherry-Picking
+
+Apply specific commits from one branch to another without merging entire branches.
+
+```bash
+# Cherry-pick single commit
+git cherry-pick abc123
+
+# Cherry-pick range of commits (exclusive start)
+git cherry-pick abc123..def456
+
+# Cherry-pick without committing (stage changes only)
+git cherry-pick -n abc123
+
+# Cherry-pick and edit commit message
+git cherry-pick -e abc123
+```
+
+### 3. Git Bisect
+
+Binary search through commit history to find the commit that introduced a bug.
+
+```bash
+# Start bisect
+git bisect start
+
+# Mark current commit as bad
+git bisect bad
+
+# Mark known good commit
+git bisect good v1.0.0
+
+# Git will checkout middle commit - test it
+# Then mark as good or bad
+git bisect good  # or: git bisect bad
+
+# Continue until bug found
+# When done
+git bisect reset
+```
+
+**Automated Bisect:**
+
+```bash
+# Use script to test automatically
+git bisect start HEAD v1.0.0
+git bisect run ./test.sh
+
+# test.sh should exit 0 for good, 1-127 (except 125) for bad
+```
+
+### 4. Worktrees
+
+Work on multiple branches simultaneously without stashing or switching.
+
+For every Worktree created by an Agent, use the task's assigned parent Project root and place the Worktree at the direct-child path `<projectRoot>/.worktree/<managedName>`.
+
+- Treat `projectRoot` as the current Runweave parent Project, not the Git common-dir checkout. A parent Project may itself be a linked Worktree.
+- If the current cwd is already `<projectRoot>/.worktree/<name>`, create any additional Worktree as its sibling under the same parent Project; never create nested `.worktree/<name>/.worktree/<other>` directories.
+- Use a short lowercase ASCII slug for `managedName`. Keep the directory name separate from a branch name containing `/`.
+- Before creation, reject a symlinked `.worktree` root, ensure the root `/.worktree/` path is Git-ignored, and inspect `git worktree list --porcelain` for path or branch collisions.
+- Do not create new Worktrees in `/tmp`, `/private/tmp`, repository siblings, `.trae/worktrees`, or another tool-private directory. Existing Worktrees outside `.worktree` may continue to be used when the task is already bound to them; do not migrate them implicitly.
+- Remove only the exact managed Worktree after checking that it is clean and no task-owned runtime still uses it. Do not use broad `git worktree prune` or forced removal as routine cleanup.
+
+```bash
+# Run from the assigned parent Project root
+project_root="$(git rev-parse --show-toplevel)"
+worktree_root="$project_root/.worktree"
+baseline_revision="<exact-baseline-revision>"
+
+# The repository must ignore /.worktree/ before creation
+test ! -L "$worktree_root"
+mkdir -p "$worktree_root"
+git -C "$project_root" check-ignore -q .worktree/
+
+# Inspect exact registered identities before changing them
+git -C "$project_root" worktree list --porcelain
+
+# Add new worktree for feature branch
+git -C "$project_root" worktree add \
+  "$worktree_root/feature-new-feature" \
+  feature/new-feature
+
+# Add worktree and create new branch
+git -C "$project_root" worktree add \
+  -b bugfix/urgent \
+  "$worktree_root/bugfix-urgent" \
+  main
+
+# Add detached validation worktree from an exact baseline
+git -C "$project_root" worktree add \
+  --detach \
+  "$worktree_root/validate-terminal-state" \
+  "$baseline_revision"
+
+# Remove one clean, no-longer-used worktree and verify the registration is gone
+git -C "$worktree_root/feature-new-feature" status --short
+git -C "$project_root" worktree remove \
+  "$worktree_root/feature-new-feature"
+git -C "$project_root" worktree list --porcelain
+```
+
+### 5. Reflog
+
+Your safety net - tracks all ref movements, even deleted commits.
+
+```bash
+# View reflog
+git reflog
+
+# View reflog for specific branch
+git reflog show feature/branch
+
+# Restore deleted commit
+git reflog
+# Find commit hash
+git checkout abc123
+git branch recovered-branch
+
+# Restore deleted branch
+git reflog
+git branch deleted-branch abc123
+```
+
+## Practical Workflows
+
+### Workflow 1: Clean Up Feature Branch Before PR
+
+```bash
+# Start with feature branch
+git checkout feature/user-auth
+
+# Interactive rebase to clean history
+git rebase -i main
+
+# Example rebase operations:
+# - Squash "fix typo" commits
+# - Reword commit messages for clarity
+# - Reorder commits logically
+# - Drop unnecessary commits
+
+# Force push cleaned branch (safe if no one else is using it)
+git push --force-with-lease origin feature/user-auth
+```
+
+### Workflow 2: Apply Hotfix to Multiple Releases
+
+```bash
+# Create fix on main
+git checkout main
+git commit -m "fix: critical security patch"
+
+# Apply to release branches
+git checkout release/2.0
+git cherry-pick abc123
+
+git checkout release/1.9
+git cherry-pick abc123
+
+# Handle conflicts if they arise
+git cherry-pick --continue
+# or
+git cherry-pick --abort
+```
+
+### Workflow 3: Find Bug Introduction
+
+```bash
+# Start bisect
+git bisect start
+git bisect bad HEAD
+git bisect good v2.1.0
+
+# Git checks out middle commit - run tests
+npm test
+
+# If tests fail
+git bisect bad
+
+# If tests pass
+git bisect good
+
+# Git will automatically checkout next commit to test
+# Repeat until bug found
+
+# Automated version
+git bisect start HEAD v2.1.0
+git bisect run npm test
+```
+
+### Workflow 4: Multi-Branch Development
+
+```bash
+# Run from the assigned parent Project root
+project_root="$(git rev-parse --show-toplevel)"
+hotfix_worktree="$project_root/.worktree/hotfix-critical-bug"
+mkdir -p "$project_root/.worktree"
+git -C "$project_root" check-ignore -q .worktree/
+
+# Create a direct-child worktree for the existing hotfix branch
+git -C "$project_root" worktree add \
+  "$hotfix_worktree" \
+  hotfix/critical-bug
+
+# Work on hotfix in separate directory
+cd "$hotfix_worktree"
+# Make changes, commit
+git commit -m "fix: resolve critical bug"
+git push origin hotfix/critical-bug
+
+# Return to main work without interruption
+cd "$project_root"
+git fetch origin
+git cherry-pick hotfix/critical-bug
+
+# Clean up the exact path when it is clean and no runtime uses it
+git -C "$hotfix_worktree" status --short
+git -C "$project_root" worktree remove "$hotfix_worktree"
+```
+
+### Workflow 5: Recover from Mistakes
+
+```bash
+# Accidentally reset to wrong commit
+git reset --hard HEAD~5  # Oh no!
+
+# Use reflog to find lost commits
+git reflog
+# Output shows:
+# abc123 HEAD@{0}: reset: moving to HEAD~5
+# def456 HEAD@{1}: commit: my important changes
+
+# Recover lost commits
+git reset --hard def456
+
+# Or create branch from lost commit
+git branch recovery def456
+```
+
+## Advanced Techniques
+
+### Rebase vs Merge Strategy
+
+**When to Rebase:**
+
+- Cleaning up local commits before pushing
+- Keeping feature branch up-to-date with main
+- Creating linear history for easier review
+
+**When to Merge:**
+
+- Integrating completed features into main
+- Preserving exact history of collaboration
+- Public branches used by others
+
+```bash
+# Update feature branch with main changes (rebase)
+git checkout feature/my-feature
+git fetch origin
+git rebase origin/main
+
+# Handle conflicts
+git status
+# Fix conflicts in files
+git add .
+git rebase --continue
+
+# Or merge instead
+git merge origin/main
+```
+
+### Autosquash Workflow
+
+Automatically squash fixup commits during rebase.
+
+```bash
+# Make initial commit
+git commit -m "feat: add user authentication"
+
+# Later, fix something in that commit
+# Stage changes
+git commit --fixup HEAD  # or specify commit hash
+
+# Make more changes
+git commit --fixup abc123
+
+# Rebase with autosquash
+git rebase -i --autosquash main
+
+# Git automatically marks fixup commits
+```
+
+### Split Commit
+
+Break one commit into multiple logical commits.
+
+```bash
+# Start interactive rebase
+git rebase -i HEAD~3
+
+# Mark commit to split with 'edit'
+# Git will stop at that commit
+
+# Reset commit but keep changes
+git reset HEAD^
+
+# Stage and commit in logical chunks
+git add file1.py
+git commit -m "feat: add validation"
+
+git add file2.py
+git commit -m "feat: add error handling"
+
+# Continue rebase
+git rebase --continue
+```
+
+### Partial Cherry-Pick
+
+Cherry-pick only specific files from a commit.
+
+```bash
+# Show files in commit
+git show --name-only abc123
+
+# Checkout specific files from commit
+git checkout abc123 -- path/to/file1.py path/to/file2.py
+
+# Stage and commit
+git commit -m "cherry-pick: apply specific changes from abc123"
+```
+
+## Best Practices
+
+1. **Always Use --force-with-lease**: Safer than --force, prevents overwriting others' work
+2. **Rebase Only Local Commits**: Don't rebase commits that have been pushed and shared
+3. **Descriptive Commit Messages**: Future you will thank present you
+4. **Atomic Commits**: Each commit should be a single logical change
+5. **Test Before Force Push**: Ensure history rewrite didn't break anything
+6. **Keep Reflog Aware**: Remember reflog is your safety net for 90 days
+7. **Branch Before Risky Operations**: Create backup branch before complex rebases
+
+```bash
+# Safe force push
+git push --force-with-lease origin feature/branch
+
+# Create backup before risky operation
+git branch backup-branch
+git rebase -i main
+# If something goes wrong
+git reset --hard backup-branch
+```
+
+## Common Pitfalls
+
+- **Rebasing Public Branches**: Causes history conflicts for collaborators
+- **Force Pushing Without Lease**: Can overwrite teammate's work
+- **Losing Work in Rebase**: Resolve conflicts carefully, test after rebase
+- **Unsafe Worktree Placement or Cleanup**: Create only under `<projectRoot>/.worktree/<managedName>` and remove only the verified exact target
+- **Not Backing Up Before Experiment**: Always create safety branch
+- **Bisect on Dirty Working Directory**: Commit or stash before bisecting
+
+## Recovery Commands
+
+```bash
+# Abort operations in progress
+git rebase --abort
+git merge --abort
+git cherry-pick --abort
+git bisect reset
+
+# Restore file to version from specific commit
+git restore --source=abc123 path/to/file
+
+# Undo last commit but keep changes
+git reset --soft HEAD^
+
+# Undo last commit and discard changes
+git reset --hard HEAD^
+
+# Recover deleted branch (within 90 days)
+git reflog
+git branch recovered-branch abc123
+```
+
+## Resources
+
+- **references/git-rebase-guide.md**: Deep dive into interactive rebase
+- **references/git-conflict-resolution.md**: Advanced conflict resolution strategies
+- **references/git-history-rewriting.md**: Safely rewriting Git history
+- **assets/git-workflow-checklist.md**: Pre-PR cleanup checklist
+- **assets/git-aliases.md**: Useful Git aliases for advanced workflows
+- **scripts/git-clean-branches.sh**: Clean up merged and stale branches

package/payload/plugins/toolkit/skills/github-pr/SKILL.md

@@ -0,0 +1,109 @@
+---
+name: github-pr
+description: 当用户要求提交代码并合并到 GitHub（提交 PR、走完 PR 全流程、合并到主分支）时使用。一键完成：提交工作区代码 → 创建 PR → 轮询状态并解决冲突/门禁失败 → CR 通过后合并。
+---
+
+# GitHub PR 全流程
+
+一条命令把当前工作区的改动**提交、开 PR、跟到通过、合并进目标分支**。基于 `gh` CLI（GitHub）。
+
+这是随插件安装的跨仓库技能，适用于 GitHub 仓库。目标仓库无需包含本技能、预检脚本或插件源码；所有 Git 操作都在用户要提交的目标仓库执行。
+
+技能资源从实际加载的 `SKILL.md` 所在目录解析，使用绝对路径调用；不要到目标仓库寻找 `plugins/toolkit`，也不要硬编码某台机器的路径或缓存版本。辅助脚本依赖 Node.js 内置模块、Git 和 `gh`，有 `curl` 时额外检查无凭证网络连通性；缺少 `curl` 时明确跳过该探测，仍执行 GitHub API 检查。不需要在目标仓库安装 npm/pnpm 依赖。没有 Node.js 或脚本资源缺失时，按下述规则逐项执行 Git/gh 只读检查，不要求目标项目引入 Node.js。
+
+提交格式及 PR 模板以目标仓库的说明和现有配置为准，不沿用技能开发仓库的约定。已有 commit/push hook 和远端 CI 属于本流程；构建、lint、测试、Dev Session、UI/CDP 验收及其他主动验证，只有用户在当前请求中明确要求，或显式调用对应验证技能时才执行。目标仓库列出可用验证命令，不等于纯 Git/PR 请求已经授权执行。Husky 和提交钩子都可选，不存在时记录为缺省，不自动创建或安装。
+
+## 参数
+
+- 目标分支可选：用户指定则用指定分支；未指定默认远程主分支（`origin/HEAD`，回退 `main` → `master`）。
+- 默认新建分支提交并基于它开 PR；仅当用户明确要求「当前分支」时在当前分支提交。
+- “所有代码”“全部改动”只扩大本次核对与暂存范围，不授权主动运行全量或范围相称的验证，不授权启动 Dev Session、浏览器或设备验收，也不授权修复由自选验证发现的其他问题。
+- 以下命令以 `origin` 为常见示例。使用其他 remote、fork/upstream 或 GitHub Enterprise 时，先从用户请求和远端配置确定发布仓库、PR 目标仓库及主机，再替换命令参数；不能把它们默认当作同一个仓库。非 GitHub 平台使用对应流程；仅在可用时转用 create_mr 技能。
+
+## 前置检查
+
+- 在目标工作区调用随技能分发的 [预检脚本](scripts/preflight.mjs)：`node "<技能安装目录>/scripts/preflight.mjs" "<目标工作区路径>"`；省略工作区参数时检查当前目录，不要为了运行脚本切换到技能目录。脚本只读，不执行 hook、fetch、暂存或账号切换；输出 JSON 和各项退出码，全部检查收集完成后才以 0/1 表示预检通过/存在失败。
+- 检查内容包括当前提交、分支（允许 detached HEAD）、工作区与暂存区、worktree 占用、origin 的读取/推送目标、有效 hook 路径及 Husky 入口、活跃账号和目标仓库访问权限。脏工作区属于待确认范围，不自动判失败；`passed` 只表示预检完成且无失败，不代表已获写权限或可以合并。
+- 认证使用 `gh auth status --active --hostname github.com`，并通过当前账号及目标仓库 API 验证。非活跃账号失效不阻断，不自动登出或切换账号。不要用普通 `gh auth status` 的整体失败判定当前账号失效；也不要用 `gh auth status --json` 的退出码判断认证成功，它可能在认证失败时仍返回 0。
+- 脚本失败时检查 `failedChecks` 和 `hooks`；网络错误、超时、缺少 CLI 与权限不足分别处理。脚本隐藏认证原文，必要时单独重跑失败检查，不使用 `--show-token`。确实缺少当前身份或所需权限时才找用户授权。
+- `checks.credential` 独立探测当前主机凭证是否可读，只记录布尔结果，不打印或保存 Token；`checks.network` 用 `curl` 探测 GitHub API 与 Git HTTPS 主机，仅作为诊断，探测失败记录为 `warning`。凭证可读时始终执行 `gh` 账号及仓库检查，以实际 `gh` 结果决定阻塞和恢复，不因 `curl` 自身的证书或代理问题阻断提交。`gh auth status` 的 `(keyring)` 表示凭证来源，后面的 `Timeout` 不能证明 keyring 读取失败。API 超时不等于凭证失效，后台没有交互式终端也不意味着不能使用当前系统账号已有的合法凭证。
+- 网络失败先读 `diagnosis`、`recovery.attempts` 和网络错误分类，再检查当前进程代理环境、DNS 与电脑已配置的备用路线。已有获准的 HTTP(S) 备用代理时用 `node "<技能安装目录>/scripts/preflight.mjs" "<工作区>" --fallback-proxy "<代理 URL>"` 验证；URL 不允许内嵌密码，脚本不修改系统网络、Git 配置或账号。不要猜代理地址、永久写死 GitHub IP、关闭 TLS 校验或因超时要求换 Token。
+- 预检最多执行三轮（初次加两次网络重试），仅网络或检查超时进入恢复；认证拒绝、仓库无权限和限流直接保留准确原因。验证备用路线成功后，将 `recovery.connectionEnvironment` 中的环境变量应用于后续所有 `git` 和 `gh` 命令，不能只让预检走备用路线。没有可用路线或次数耗尽时返回网络阻塞，并分别说明凭证探测结果与已尝试路线；不要编造成 keyring 权限拒绝。创建 PR、合并等写操作超时仍先查询远端事实，不能照搬只读探测的重试方式。
+- `recovery.gitTransport` 为 `ssh` 时，HTTP 代理仅恢复 GitHub API；Git SSH 还须使用已有的 SSH 代理配置并独立验证 `git ls-remote`。不要因 API 已恢复就声称 SSH 推送可用，也不要自动改 remote 或 SSH 配置。
+- 独立只读检查分别保留结果，不用 `&&` 串联，也不用 `|| true` 吞错。依赖操作仍需前一步成功才能执行；异步命令返回运行中标识时，等待其真正完成。手动回退也遵守这些规则。
+- 辅助脚本自动检查的范围是 `origin` 指向 github.com 且读写目标一致。其他 remote、fork、SSH 主机别名、Enterprise 等配置使用手动预检：独立检查工作区、暂存区、worktree 和实际钩子路径；解析真实主机与仓库后检查 `gh auth status --active --hostname <主机>`、当前身份及仓库权限。脚本不支持某种配置不等于该仓库不能使用本技能；目标能从现有配置确定时无需再次询问。
+
+## 流程
+
+用户委托全流程后，只有实际 commit hook、push hook、远端 CI 或必需评审明确报告的失败，才是本技能所说的门禁失败。不要为了预判门禁而主动运行验证命令、调用其他验证技能、启动运行环境或设计额外验收场景；前置脚本的只读预检不属于代码验证。
+
+确认失败由本次改动引起且修复不改变用户目标时，先读失败输出、修复并重跑原门禁，再继续提交、推送或合并；不要在可修复时停下询问用户是否要处理，也不要把失败日志当作最终交付。自选检查或自建验收场景发现的问题不自动取得修复授权。只有用户显式要求对应验证，或修复来自实际门禁，才按本流程修复；需要改变用户目标、扩大到无关代码，或确实缺少权限、外部资源时，说明具体阻塞并请求必要输入。
+
+### 1. 提交代码
+
+- 在暂存、提交或复制补丁前，记录改动来源目录与提交目录；使用 [来源工作区脚本](scripts/source-worktree.mjs) 的 `capture <来源目录> <恢复回执.json> <范围.json>` 保存来源 HEAD、完整暂存区和脏文件恢复快照。范围文件是本次已核对的仓库相对路径 JSON 数组；回执放在来源工作区外的私有目录，不上传或打印其内容。在独立 worktree 提交时，来源目录仍属于本次交付的收尾范围，不能只清理提交目录。来源本身直接提交后变干净时，按下文普通干净工作区流程处理，无需复用提交前快照强行同步。
+- 根据用户请求和 diff 确定本次范围，检查已有暂存内容；使用 `git add -- <本次路径>`，同文件混有其他任务改动时按 hunk 暂存。只有用户明确要求全部改动且已核对范围时才用 `git add -A`。已有无关暂存内容也不能夹带提交或擅自取消暂存，必要时使用独立 worktree 承载本次补丁。
+- `git fetch origin` 后核对目标分支与本次提交范围；如改动已合并，核实对应 PR 的合并事实后直接执行第 5 步来源工作区收尾，避免重复 PR，也不能只报告已合并就留下原始改动。新分支不能夹带当前分支上无关的领先提交。脏工作区不要直接 rebase，也不要为方便操作而 stash、reset 或清理他人改动。
+- 读 `git diff --cached` 复核最终范围，按目标仓库惯例生成 commit message；无明确惯例时使用 Conventional Commits，描述意图而非文件列表。
+- 默认基于 commit subject 新建分支：`git checkout -b <type>/<slug>`；用户要求当前分支则跳过。
+- 若用户未显式要求验证或调用验证技能，完成范围复核后直接进入提交；不要插入“运行与改动范围相称的验证”、完整验收或类似计划项。
+- `git commit`。pre-commit hook 失败时按输出处理依赖/环境问题或本次代码问题，复核 hook 生成的改动、只暂存本次修复再重试。不修改无关代码来凑检查通过，不跳过 hook。
+- 工作区无改动但分支已有领先提交时，直接进入开 PR。
+
+### 2. 创建 PR
+
+- `git push -u origin <branch>`；等待 hook 与推送成功退出后再开 PR。推送失败先区分本地 pre-push 门禁、远端保护规则与 non-fast-forward，不把它们统称为 GitHub 故障。
+- **本地 pre-push 门禁失败**：读取具体失败项并核对是否由本次改动引起；若是，直接修复、只暂存修复范围、提交并重跑原门禁，再推送。例如架构检查报 `New >600 line file is not in the legacy baseline` 时，核对文件和行数，按职责抽取独立逻辑并保持行为，重新运行架构检查；不要压缩排版、扩大历史基线、跳过 hook，或把“是否修复”交给用户选择。若失败来自既有无关代码，也先核对能否在授权范围内安全修复；确实不能时报告准确的失败项与阻塞原因。
+- 远端拒绝为 non-fast-forward 时先 fetch 并检查远端新增提交的归属，再在工作区安全时 rebase，不能覆盖其他人的更新。分支保护拒绝时核对实际规则，不用强推或绕过保护制造成功。
+- 创建前按明确仓库、head/base 查询 open PR；存在则复用。命令超时或返回不确定时先查询远端是否已成功，避免盲目重试。
+- 把说明写入临时文件，再用 `gh pr create --repo <仓库> --base <目标分支> --head <branch> --title <subject> --body-file <文件>`，保留换行和字面量。body 写清改动要点与实际验证情况。
+- 记录 PR 编号/URL 供后续轮询。
+
+### 3. 轮询状态，解决冲突与门禁失败
+
+目标：把 PR 推进到「可合并 + CR 通过」。用 JSON 读权威状态，不要靠页面文本猜：
+
+```bash
+gh pr view <pr> --repo <仓库> --json number,state,headRefOid,reviewDecision,mergeable,mergeStateStatus,statusCheckRollup
+gh pr checks <pr> --repo <仓库> --json name,state,bucket,link
+```
+
+关键字段：
+
+- `mergeable`：`MERGEABLE` 可合 / `CONFLICTING` 有冲突 / `UNKNOWN` 计算中（稍等重查）。
+- `mergeStateStatus`：`CLEAN` / `BLOCKED`（缺 CR 或门禁）/ `BEHIND`（落后基线）/ `DIRTY`（冲突）。
+- `reviewDecision`：`APPROVED` / `CHANGES_REQUESTED` / `REVIEW_REQUIRED`。
+- `statusCheckRollup` 同时可能包含 CheckRun 的 `status/conclusion` 和 StatusContext 的 `state`，不能统一只读 `state`。可用 `gh pr checks` 的 `bucket` 归类：`pass/fail/pending/skipping/cancel`。
+
+处理策略：
+
+- **CI pending**：优先 `gh pr checks <pr> --repo <仓库> --watch --interval 20 --fail-fast`，通过异步执行等待并定期更新进度。普通 checks 的退出码 8 表示 pending，不是失败；查询/API 错误也不能当作 CI 失败。检查尚未注册、返回为空时核对仓库工作流，不能直接认定通过。等待超时报告仍在等待，不宣称完成。
+- **代码冲突（CONFLICTING/DIRTY）**：本地 `git fetch origin && git rebase origin/<目标分支>`，解决冲突后 `git push --force-with-lease`（GitHub 仓库允许 `--force-with-lease`）。
+- **落后基线（BEHIND）**：仓库门禁要求更新时，同上 rebase 后重推；仅目标分支有新提交且仍可正常合并时不重复 rebase。每次重推后，旧 SHA 的检查和评审结论不能替代新 SHA 的状态。
+- **门禁失败**：拉取失败 check 的日志，定位并修复，提交后重新推送触发重跑；与 pre-push 一样，本次改动造成的确定性失败由 Agent 负责修复，不停下让用户决定是否继续。取消的检查、非预期跳过的必需检查也要查明原因。只在明确瞬时故障时有限重试，同一错误无新证据不循环重跑。
+- **CHANGES_REQUESTED**：这是人工评审要求改动；总结评审意见，做出修改后重推，不要绕过评审。
+- 合并前重新读取 `headRefOid`：当前提交的应运行检查已通过、评审要求已满足、无冲突且无其他阻塞才允许直接合并。`APPROVED` 不代表 CI 通过，`CLEAN` 不替代检查明细；`UNKNOWN` 继续等待。不要仅查 `--required` 而漏掉本次应运行的检查。若读取期间 head 改变，重新验证新 head。
+
+### 4. CR 通过后合并
+
+- 满足条件后执行 `gh pr merge <pr> --repo <仓库> --squash --match-head-commit <刚验证的headRefOid>`；按仓库惯例可改合并策略。远端合并与本地清理分步执行，默认不加 `--delete-branch`，避免 main 被其他 worktree 占用或脏工作区使整个操作表现为失败。
+- 若启用了合并队列或仍需等待门禁，可登记 auto-merge/入队，登记时同样使用 `--match-head-commit`，并继续跟进当前 head；登记成功不等于已合并，不绕过门禁。
+- 不论合并命令成功、失败或超时，都单独运行 `gh pr view <pr> --repo <仓库> --json state,mergedAt,mergeCommit,headRefOid` 确认远端事实。只有 `state=MERGED` 才报告合并完成；未知状态先查明再重试。
+
+### 5. 合并后清理
+
+- 先确认已合并，再 fetch 并重读来源目录、提交目录的 `git status`、分支指向及 `git worktree list`。固定最新目标分支的完整 commit SHA，确认包含合并提交；远端成功、本地同步和残留改动分别核对。全流程委托包含本次来源改动的安全收尾；不删除来源目录，也不处理无关 worktree。
+- 来源目录仍脏时，用 `node "<技能安装目录>/scripts/source-worktree.mjs" inspect <恢复回执.json> <目标SHA>` 核对：`covered` 是本次范围内、内容和文件模式（或删除状态）与目标提交一致的路径；`retained` 是未交付或无关的路径。`changed`、`sourceHeadChanged`、`sourceIndexChanged`、`historyUncovered` 或 `indexUncovered` 非空/为 true 时不自动同步；先核对后续改动与归属，不能用旧快照清掉新内容。脚本不会用“新增字段已收录”替代整份文件比较，同文件部分交付时保留该文件。
+- `canFinish=true` 且已确认来源没有其他 Agent、编辑器或自动化正在写入、允许本次工作区切换到目标提交时，执行 `node "<技能安装目录>/scripts/source-worktree.mjs" finish <恢复回执.json> <目标SHA> --source-idle`。它保留恢复回执和来源 HEAD 的 backup 分支，仅暂存已覆盖的本次路径，将已覆盖的未跟踪文件从原目录移开，再用不带 force 的 checkout detach 到目标 SHA；Git 拒绝覆盖剩余改动时恢复原暂存区和移开的文件，保留具体阻塞。`--source-idle` 是调用者已核实独占写入的声明，不是锁。禁止对正在被其他任务写入的来源执行此命令。
+- 来源变干净（例如直接在来源提交）时，确认本次提交已合并、没有未交付的独有提交且不存在其他任务写入后，可 detach 到目标 SHA。用户明确要求保持当前分支、来源有后续改动、源 HEAD 有未交付提交、剩余改动与目标更新冲突，或同文件混有部分交付内容时，保留现场并逐项说明原因和后续处理；不能为了干净使用 reset --hard、clean、整文件恢复或重放旧 stash。目标分支被其他 worktree 占用时不切换或拉取那个目录。
+- 同步后独立回读来源 HEAD、工作区与暂存区：本次已覆盖路径不再显示为脏，保留路径的内容、文件模式、删除状态及暂存语义仍正确。只删除本次创建且干净、无运行会话使用的交付 worktree/分支；恢复快照和 backup 分支保留并报告位置。squash 后 `git branch -d` 拒绝时不直接升级为 `-D`。
+- 远端源分支只在确认属于本次任务、仍指向已合并的 head 时删除。若用 `git push --delete`，须带针对该 ref 和已验证 SHA 的显式 `--force-with-lease`；该操作可能触发 pre-push，不能为省检查禁用 hook。分支已被自动删除则无需再处理。
+- 最终分别报告 PR/合并提交、来源工作区同步状态、剩余改动的路径及原因、恢复位置和实际验证结果。清理失败不改写已合并事实，也不触发重复合并；来源本次旧改动仍残留时，不能宣称全流程收尾完成。
+
+## 安全与边界
+
+- 只在确认 GitHub 仓库且已登录时执行；缺权限就停下找用户要授权。
+- **不用 `--admin` 绕过门禁，不跳过人工评审**（CHANGES_REQUESTED 必须真实改完）。
+- 冲突/落后用 `--force-with-lease`，不用 `--force`。
+- 检测到疑似敏感信息（密钥/密码）时警告用户再继续。
+- 全程可观测：每一步输出分支、commit、PR URL、当前状态；失败不静默，报出关键字段与错误。