@yiliang114/harness-task

v0.1.2

Published

a month ago

Global CLI wrapper for the Skills harness control-plane and portable skill workflows.

0High
0Medium
0Low

yiliang114

ai agent skills harness cli codex claude-code qwen

Skills

English | 简体中文

个人 Skills 集合，用于各种 AI CLI 工具（如 Claude Code、Qwen 等）。

目录结构

.
├── README.md
├── commands/        # 用户侧命令入口
├── scripts/         # 安装与辅助脚本
└── skills/          # 存放自定义 Skills

平台基础层

当前仓库除了继续提供可直接给 CLI 使用的 skills 之外，也开始提供 Harness 平台的基础能力：

可移植 Skill 规范：docs/architecture/portable-skill-spec.md
运行时契约：harness/contracts/
本地 control-plane MVP：harness/control_plane/
统一 registry 产物：dist/registry/skills.json
adapter / control plane 说明：docs/architecture/ 与 platform/

用法

安装到 Claude Code

scripts/install-workflows.sh --target-root "$HOME/.claude"

如果你只想把当前仓库的 skills 安装到全局，并且希望避免直接覆盖，推荐改用：

scripts/install-global-skills.sh

默认会同时安装到：

~/.claude/skills
~/.codex/skills

行为说明：

默认使用符号链接，不直接复制覆盖
如果目标 skill 已存在且内容相同，会自动跳过
如果目标 skill 已存在但不同，默认跳过并提示冲突
只有显式加 --update 才会替换冲突项
--update 替换前会先备份，默认备份到 ~/.skill-installer-backups/<timestamp>/

示例：

# 同时安装到 Claude Code 和 Codex，全程跳过重复/冲突项
scripts/install-global-skills.sh

# 只安装到 Codex
scripts/install-global-skills.sh --targets codex

# 只更新已有冲突项，并先备份
scripts/install-global-skills.sh --update

# 只安装指定 skills
scripts/install-global-skills.sh code-review-expert issue-reply issue-release-followup branch-diff-review

更新方式：

如果默认使用符号链接，直接修改当前仓库里的 skills/<name> 即可；全局目录会指向最新内容
对于已经存在的冲突项，执行 scripts/install-global-skills.sh --update
更新后建议重启 Claude Code / Codex，让技能列表重新加载

安装到 Qwen CLI

scripts/install-workflows.sh --target-root "$HOME/.qwen"

当前仓库结构

.
├── commands/   # 用户侧命令入口
├── scripts/    # 安装与辅助脚本
└── skills/     # 可复用 workflow skills

安装脚本

仓库内置统一安装脚本：

scripts/install-workflows.sh --target-root "$HOME/.qwen"
scripts/install-workflows.sh --target-root "$HOME/.claude"
scripts/install-workflows.sh --target-root "$HOME/.codex" --clean

说明：

会同时同步 skills/ 和 commands/
--clean 会清理目标目录中已不再存在于当前仓库的文件
适合做本地安装和后续同步刷新

导出工作流

如果你希望显式生成不同 CLI 的导出目录，使用：

# 导出到 dist 目录
scripts/export-workflows.sh --output-root dist --targets claude,codex,qwen --mode copy --clean

# 直接导出到某个目标根目录
scripts/export-workflows.sh --direct-root "$HOME/.codex" --mode copy --clean

如果你只想刷新统一 registry：

python3 scripts/build-skill-registry.py

CI 与 CLI 的区别

当前仓库里有两类东西，不要混淆：

CLI：你本地直接运行的命令，例如 scripts/harness、scripts/harness-task、scripts/harness-dispatch
CI：GitHub Actions 里的自动校验和导出流程

当前已经存在的 CI workflow 是：

.github/workflows/validate-registry.yml
.github/workflows/export-skills.yml

它们负责测试、校验 registry 和导出产物，不负责代替你本地使用 CLI。如果你前面说的是 HoneyScanTask，当前仓库里并没有这个名字；现有命令名是 harness / harness-task。

全局安装方式

当前仓库推荐发布为 npm 包，不是 Rust crate。原因很简单：当前运行时是 bash + python3，仓库里没有 Rust 工程；用 npm 包做全局分发成本最低，也最贴合现有 CLI 结构。

如果后续发布到 npm，你可以直接这样安装：

npm install -g @yiliang114/harness-task

安装后可直接在任意目录调用：

harness issue https://github.com/example/repo/issues/123
harness-task list
harness-dispatch --task-id <task_id>
harness-serve

推荐的日常使用方式：

# 1. 先创建 task，并查看系统给出的 dispatch plan
harness issue https://github.com/example/repo/issues/123

# 2. 对 ready issue，直接进入 issue-to-pr 路由
harness issue https://github.com/example/repo/issues/123 --ready

# 3. 只有在你明确要 one-shot 自动执行时，才加 --execute
harness issue https://github.com/example/repo/issues/123 --ready --execute

# 4. PR / release 也走同一个总入口
harness pr https://github.com/example/repo/pull/7
harness pr https://github.com/example/repo/pull/7 --publish-mode approve
harness release v1.2.3

推荐把 harness 作为日常主入口。
harness-task、harness-dispatch、harness-serve 仍然保留，适合你需要精细控制 task 创建、dispatch 或本地 API 时使用。 PR 相关任务现在默认会附带 publish_mode=review-only，并优先使用 codex-cli 做 review；是否真正 approve、comment、request-changes 或 merge，仍然应该作为后续的显式决策。

运行前提：

bash
python3
如果要真实执行底层 executor，还需要本机已安装对应 CLI，例如 codex、claude、qwen

当前仓库已经补了 npm 发布准备：

package.json
.github/workflows/publish-npm.yml

真正发布到 npm 还需要你在 GitHub 仓库里配置 NPM_TOKEN。没有这个 token，我只能把发布流程准备好，不能替你完成线上发布。

本地 Control Plane

当前仓库已经包含一个本地优先的 Harness control-plane MVP：

推荐先用统一入口：

# issue 默认走 prepare：创建 task + 返回 dispatch 计划
scripts/harness issue https://github.com/example/repo/issues/123

# ready issue 会自动进入 issue-to-pr lane
scripts/harness issue https://github.com/example/repo/issues/123 --ready

# PR / maintenance / release 也有结构化入口
scripts/harness pr https://github.com/example/repo/pull/7
scripts/harness maintenance --assignee yiliang
scripts/harness release v1.2.3

# 显式执行而不是只做 prepare
scripts/harness issue https://github.com/example/repo/issues/123 --ready --execute

这层统一入口的作用是把结构化命令翻译成 harness 能理解的标准输入：

issue -> issue_url / readiness
pr -> pr_url
maintenance -> assignee / maintenance_query / parent_issue
release -> release_tag

也就是说，即使你没有额外写用户配置，系统也能靠内建默认规则先分到正确的 lane 和 skill，再继续选择 executor。

更短的包装命令：

# 初始化/创建/查看 task
scripts/harness-task init
scripts/harness-task create --title "Ready issue" --input issue_url=https://github.com/example/repo/issues/123 --input readiness=ready
scripts/harness-task list

# 查看或执行 dispatch
scripts/harness-dispatch --task-id <task_id>
scripts/harness-dispatch --task-id <task_id> --execute

# 启动本地 API
scripts/harness-serve

这些脚本本质上只是 python3 -m harness.control_plane.cli 的薄包装，默认会自动带上：

HARNESS_STATE_DIR，默认指向仓库内 .harness/state
HARNESS_REGISTRY_PATH，默认指向 dist/registry/skills.json
HARNESS_EXECUTOR_CONFIG，默认指向 platform/adapters/executors.local.json

如果你要改成 dry-run 或测试配置，直接覆盖环境变量即可，例如：

HARNESS_EXECUTOR_CONFIG=platform/adapters/executors.json scripts/harness-dispatch --task-id <task_id>

底层原生命令仍然保留：

# 初始化本地状态目录
python3 -m harness.control_plane.cli init-store

# 创建一个会自动路由的 task
python3 -m harness.control_plane.cli create-task \
  --title "Ready issue" \
  --input issue_url=https://github.com/example/repo/issues/123 \
  --input readiness=ready

# 先查看 dispatch 计划
python3 -m harness.control_plane.cli dispatch-run --task-id <task_id>

# 再通过本地 adapter 执行
python3 -m harness.control_plane.cli dispatch-run --task-id <task_id> --execute

# 看看当前 task 被路由到了哪个 profile / executor / model
python3 -m harness.control_plane.cli dispatch-run --task-id <task_id> | jq '.profile, .executor, .model'

# 启动本地 API
python3 -m harness.control_plane.cli serve

# 通过 GitHub webhook payload 创建 task
curl -X POST http://127.0.0.1:8765/intake/github \
  -H 'Content-Type: application/json' \
  -H 'X-GitHub-Event: issues' \
  -d '{"action":"opened","repository":{"full_name":"example/repo"},"issue":{"number":123,"title":"Fix flaky test","html_url":"https://github.com/example/repo/issues/123","labels":[{"name":"ready"}]}}'

# 通过 HTTP 直接 dispatch
curl -X POST http://127.0.0.1:8765/tasks/<task_id>/dispatch \
  -H 'Content-Type: application/json' \
  -d '{"execute":true}'

默认状态目录为 .harness/state/。默认的策略化 executor 配置在 platform/adapters/executors.json。这个文件默认是安全的：它已经把任务映射到 codex / claude / qwen / gemini / kimi 这些执行器，但 wrapper 默认仍停在 dry-run，不会立刻真实调用模型。如果你想直接开始真实执行，优先用 platform/adapters/executors.local.json。如果你想先看模板或进一步改造，再看 platform/adapters/executors.live.example.json。

从这一步开始，dispatch 不再只输出 lane / profile / executor / model，还会显式绑定一个 skill：

issue-triage -> issue-triage
issue-to-pr -> issue-to-pr
pr-review -> pr-review
community-maintenance -> community-maintenance
release-publish -> release-publish
未命中的 lane 默认回退到 open-source-flow

也就是说，harness 现在会把“该走哪个 skill”一并写进 task payload 和 prompt。你仍然可以手工直接调用 skill，但如果走 harness，它会先替你完成这层选择。

当前 live 模板的推荐策略是：

通用轻任务：kimi-cli
检索/维护类轻任务：gemini-cli
中等复杂度 coding：qwen-cli
深度实现任务：codex-cli
PR/release 审查类任务：codex-cli

策略优先级是：

明确 lane 优先于 complexity
complexity=low/medium/high 主要用于泛化的 open-source-flow 任务

直接使用方式：

python3 -m harness.control_plane.cli dispatch-run \
  --task-id <task_id> \
  --config platform/adapters/executors.local.json \
  --execute

执行后可以在 .harness/state/artifacts/ 里看到：

*.task.json：结构化 task payload，包含 dispatch.skill 与 dispatch.skill_path
*.prompt.txt：真正发给本地 executor 的 prompt，里面已经包含 skill 名称和 skill 文件路径
*.result.json：执行结果
*.log：stdout / stderr 合并日志

添加新 Skill

将你的 Skill 文件放入 skills/ 目录即可。

工作流矩阵

| 阶段 | 主要 Skill | Command | 输出 | | --- | --- | --- | --- | | 高层编排入口 | open-source-flow | open-source-flow | 选中的 workflow lane / 当前阶段 / 下一步 | | 会话收尾 / handoff | session-wrap | session-wrap | 当前会话总结 / handoff / 验证缺口 / commit-ready 判断 | | 创建 Issue | create-issue | create-issue | Issue 草稿 / Issue URL | | Triage Issue | issue-triage | issue-triage | 分类建议 / 下一步动作 | | 回复 Issue | issue-reply | issue-reply | 回复草稿 / 评论链接 / 关闭决策 | | 发布后回访 Issue | issue-release-followup | issue-release-followup | 候选 issue 列表 / 回复草稿 / 评论链接 / 关闭决策 | | 分支差异 Review | branch-diff-review | branch-diff-review | 纯 git 分支对比下的分支意图总结 / 风险与优化建议 | | Agent 改动 Review | agent-change-review | agent-change-review | review 范围判断 / 二次审查 findings / 下一步动作 | | 仓库初始化 | repo-ops | repo-ops | 仓库路径 / 分支 / 前置检查 | | 导入 PR/MR 分支 | import-pr-branch | import-pr-branch | source repo / source branch / 导入分支 / 目标 remote | | 从 Issue 到开发 | issue-to-pr | issue-to-pr | 分支、验证状态、PR 下一步 | | 执行修复闭环 | issue-execution-loop | issue-execution-loop | baseline / 根因 / 修复 / 验证 / retry 状态 | | 统一验证 | verification-pack | verify | pass / fail / skipped 验证结果 | | 本地提交 | commit | commit | 一个或多个 commit（支持 --single 单提交模式） | | 创建 PR | auto-pr | auto-pr | PR 描述 / PR URL（支持 --description-only 仅生成描述） | | 审查 PR | pr-review | pr-review | Review 草稿 / Review 评论 | | 发布 / 上线 | release-publish | release-publish | Release URL / 版本 / 发布验证 / Hotfix 流程 | | 社区维护 | community-maintenance | community-maintenance | assignee 队列表 / actionable issue 队列 / stale / follow-up / 父 issue 关联队列过滤结果 / issue assignee 推荐 / 路由建议 |

Review Skill 区分

| Skill | 适用场景 | 依赖上下文 | 主要输出 | | --- | --- | --- | --- | | agent-change-review | 本地改动来自另一个 agent、模型或终端会话，想先做独立二审再决定下一步 | 本地仓库 + 文件、工作树或当前分支 diff | review 范围 / 二次审查 findings / 路由后的下一步 | | branch-diff-review | 纯 git 分支对比，想先理解当前分支主要做了什么，再看还能怎么优化 | 本地仓库 + 两个分支 | 分支意图总结 / must-fix / should-improve / optional-optimization | | pr-review | GitHub PR 的默认审查路径；高风险 PR 可选开启 expert mode（已吸收原 code-review-pr） | GitHub PR | review 草稿 / 审核结论 / 评论或 review 发布动作 | | code-review-expert | 独立深度 review，或在高风险 PR 中作为 expert mode 的额外视角 | 当前 git 变更或 MR 风格 diff | 分级 findings / 架构与安全建议 / 可删除代码与后续计划 |

如何开始

推荐默认从 open-source-flow 这个高层入口开始，让它先判断当前是“新需求 / 已有 Issue / 导入 PR/MR 分支 / 已有 PR / 发布 / 社区维护”中的哪一段，再路由到对应 workflow。

场景 0：我有一个 PR/MR 链接，想把源分支导入当前仓库

直接这样触发：

用 open-source-flow 处理这个 PR 导入任务：
<github-or-gitlab-pr-mr-url>

要求：
- 把源分支导入当前 checkout 的仓库
- 先新建本地导入分支
- 在导入分支上 merge，不要直接动当前分支
- 只推当前仓库 remote，不要推回 source fork

如果你已经明确知道 lane，也可以直接调用 import-pr-branch。

如果你只是想在停工前把当前本地会话收尾，直接用 session-wrap。它只处理当前 session，并把后续动作路由回 verification-pack、agent-change-review 或 commit。

场景 1：我已经有一个 Issue，要完整走完解决链路

直接这样触发：

用 open-source-flow 处理这个 issue：
https://github.com/<owner>/<repo>/issues/<number>

要求：
- 先搜索相关 issue / PR，确认是否重复
- 如果类似问题已经在最新代码中修复，先告知升级建议，不要重复修
- 结合源码分析根本原因，不要只看 issue 文案
- 明确记录修复思路后再动手
- 完成修改后跑完整验证
- 验证通过后提交 commit 并按模板创建 PR
- PR 里要关联原 issue 和相关 issue

如果你已经明确知道就是 issue 开发场景，也可以直接用：

用 issue-to-pr 处理这个 issue：
https://github.com/<owner>/<repo>/issues/<number>

要求：
- 先检查重复 issue / 相关 PR
- 如果发现相关 issue 已经在最新版本解决，先停止修复并反馈升级建议
- 结合源码定位根因
- 修复后跑 lint / test / typecheck / build
- 最后创建关联 PR，并把相关 issue 一并写进说明

这条路径的内部流程应当是：

读取 issue，并检查是否重复、是否缺信息、是否已有相关 PR
如果相似问题已经在最新代码中修复，优先给出升级建议并走 duplicate / superseded 处理
如果多个未解决 issue 指向同一个根因，先归并 issue 列表
用 repo-ops 准备仓库、分支和 workspace
用 issue-execution-loop 完成 baseline、根因分析、修复、验证和必要重试
用 commit 提交
用 auto-pr 创建关联 PR，并链接主 issue 与相关 issue

场景 2：我还没有 Issue，想先确认是否值得建单

直接这样触发：

用 open-source-flow 处理这个问题：
<你的需求 / bug 描述>

要求：
- 先搜索现有 issue / PR，确认是否已有重复内容
- 如果类似问题已经在最新代码中修复，优先告诉我升级建议
- 如果没有，再按仓库模板创建 issue
- 如果已有重复项，优先告诉我应该复用哪一个

这类请求通常会先路由到 create-issue。如果已经找到合适的 existing issue，就优先复用或在原 issue 下继续；如果新建了 issue，后续再进入 issue-to-pr。

场景 3：我希望把校验也完整纳入流程

触发时直接把校验要求写清楚，例如：

用 open-source-flow 处理这个 issue，并把完整校验纳入流程。
需要至少覆盖：
- lint
- typecheck
- tests
- build

如果某一项仓库里没有现成命令，请明确标记为 skipped，不要静默跳过。

场景 4：某个功能已经合并并发布，想批量回访相关 issue

这个场景适合用 issue-release-followup。它适用于：

先按 GitHub query 找 issue
判断哪些是这个功能的 direct match，哪些只是评论里顺带提到
核对相关 PR 是否已 merge、是否已进入 stable release
先生成回复草稿，再由你确认是否评论、是否关闭

直接这样触发：

用 issue-release-followup 处理 QwenLM/qwen-code 仓库里的 issue 回访：

搜索条件：
- is:issue state:open assignee:yiliang114

目标：
- 找出和 vscode ide companion 粘贴图片相关的 issue
- 区分直接相关和顺带提及
- 核对是否已经 merge，是否已经在 v0.13.0 发布
- 先给我中文回复草稿
- 发之前让我确认
- 只有完全解决的 issue 才建议关闭

如果你已经知道要核对的版本，也可以把版本和发布日期要求写进提示词，例如：

用 issue-release-followup 检查这个 query 下的 issue。
如果确认已经发布，回复里必须写清楚版本号和绝对日期，不要只写 latest。

场景 5：拉某个 assignee 的 issue / PR 队列，并只看还需要人处理的项

这个场景适合用 community-maintenance。它适用于：

按仓库和 assignee 拉 open issues / PR
判断哪些条目仍然是 pending-maintainer
先给你一个可继续处理的表格，而不是直接逐条回复
issue 后续路由到 issue-reply
PR 后续路由到 pr-review

直接这样触发：

用 community-maintenance 巡检 owner/repo 里 assign 给 yiliang114 的 open issue 和 PR：

- scope: both
- 只展示 pending-maintainer
- 按 oldest-unanswered-first 排序
- 先给我表格
- issue 后续用 issue-reply
- PR 后续用 pr-review
- 发评论前让我确认

如果你想看完整队列，而不是只看待处理项，也可以这样说：

用 community-maintenance 拉这个 assignee 队列，但不要只看 pending。
把 waiting-author 和 stale-candidate 也一起列出来。

如果你只想先把待处理 issue 拉出来逐个处理，也可以让它走 issue-only one-shot：

用 community-maintenance 拉 owner/repo 里 assign 给 yiliang114 的待处理 issue。
先给我 list，再逐个走 issue-reply；完整过滤参数按 assignee_queue.py --help 选。

如果你想要一个“我现在该处理的 issue 列表”，同时把未分配但推荐给你的 issue 也合并进来，可以这样说：

用 community-maintenance 给我拉一个 owner/repo 里现在该由 yiliang114 处理的 issue 队列：

- 合并：
  - 已 assign 给我且现在轮到 maintainer 回复的 issue
  - 还没人 assign 但根据 owner index 推荐应该由我处理的 issue
- 排除已经有关联 PR 的 issue
- 排除 parent issue
- 先给我 list
- 每条后面标明下一步建议走 issue-reply、issue-triage 还是 issue-to-pr

拉完队列后，下一步该用哪个 Skill？

队列拉出来之后，单个 issue 默认这样分流：

issue-reply：适合先读 thread、理解问题、查重复、结合代码辅助判断，并生成友好的维护者回复文案
issue-triage：适合 issue 还不够明确，需要先判断它是 ready、needs-info、duplicate-or-related，还是 already-fixed-or-not-reproducible
issue-to-pr：适合 issue 已经足够明确，准备直接进入修复、验证、提交和 PR 流程
open-source-flow：适合你不想手动选 lane，希望用一个高层入口自动路由

实用默认规则：

assigned-follow-up 类型，通常先走 issue-reply
unassigned-recommended 类型，通常先走 issue-triage
只有当 issue 已经明确 ready、并且你准备直接修时，才直接跳到 issue-to-pr

场景 6：review 当前分支和目标分支的差异，并判断还能怎么优化

这个场景适合用 branch-diff-review。它适用于：

对比当前分支和 main / master / 某个 feature branch 的差异
不依赖 GitHub / GitLab / Gitee 的 PR 或 MR 上下文
先理解这条分支主要做的事情是什么
再看实现有没有 correctness 风险、设计问题或还能继续优化的地方
区分必须修的问题和可选优化，不把所有建议都当阻断项

直接这样触发：

用 branch-diff-review review 当前分支和 main 的差异：

要求：
- 先总结这条分支主要做了什么
- 按功能块归纳，不要只按文件顺序罗列
- 看看有没有明显的 bug 风险或回归风险
- 再判断代码是否还能继续优化
- 区分 must-fix、should-improve、optional-optimization

如果你已经知道目标分支不是 main，也可以显式指定：

用 branch-diff-review 对比当前分支和 release/0.13 分支。
先告诉我这条分支主要改了什么，再评估实现是否还值得继续优化。

场景 7：我有一个 parent issue，想把关联 issue 拉出来并过滤掉已处理项

这个场景适合用 community-maintenance。它适用于：

一个 parent / tracking / epic issue 下挂了很多 child issues
你已经在本地用笔记、周报、巡检记录处理过其中一部分
现在只想看“剩余还没处理的完整列表”
希望先得到 handled / filtered 和 remaining queue，再决定是否继续逐条回复

直接这样触发：

用 community-maintenance 巡检这个 parent issue 派生出来的关联 issue 队列：
https://github.com/<owner>/<repo>/issues/<parent-number>

本地已处理记录目录：
<records-dir>

要求：
- 从 parent issue 的 title / body / comments 里提取显式关联的 issue
- 扫描本地记录目录，过滤已经处理过的 issue
- 不要静默过滤，必须列出 handled / filtered 和 remaining queue 两段
- remaining queue 里给出每条 issue 的摘要、当前判断和建议动作
- 发评论前让我确认

场景 8：我想为新产生的 issue 推荐负责人，或者在高置信度时自动 assign

这个场景适合用 community-maintenance。它适用于：

定时拉取新 issue
根据最近代码改动和已有 issue 分配情况构建 owner index
根据 issue 的 title / body / labels 推荐 assignee
把状态文件保存在本地，避免每次都从头全量分析

直接这样触发：

用 community-maintenance 拉取 owner/repo 的新 issue 并推荐 assignee：

- 先刷新 owner index
- 结合最近 merged PR 和历史 issue assignee
- 输出推荐 assignee、confidence 和 evidence
- 默认不要自动 assign
- 低置信度项标成 manual-review

场景 9：我有一个具体 issue，想先深分析再决定 assign 给谁

这个场景适合用 community-maintenance。它适用于：

你已经有一个 issue 链接
当前还没人跟进
想先分析源码，再更精确地推荐负责人
希望先看一句简短理由，再决定是否 assign

直接这样触发：

用 community-maintenance 深分析这个 issue 的负责人：

- issue: https://github.com/owner/repo/issues/123
- 如果还没人跟进，就分析源码
- 定位最可能的模块
- 根据最近改动记录推荐负责人
- 理由只要一句话
- 我确认后再 assign

Codex 在流程里做什么

在 Codex 会话里，真正执行源码分析、修改代码、运行命令和判断验证结果的是当前 Codex agent；skill 负责的是：

选择正确的 workflow lane
约束必须执行的检查顺序
定义什么时候应该继续重试，什么时候应该 blocked
确保最终的 issue / PR 关联关系完整

因此：

open-source-flow 是高层路由入口
issue-to-pr 是 issue 层决策和 GitHub 关联层
issue-execution-loop 是实际的 reproduce / root-cause / fix / verify / retry 闭环

兼容入口（已合并但保留 symlink）：

quick-commit → 已合并至 commit --single
code-review-pr → 已合并至 pr-review，仅保留兼容别名，默认推荐直接用 pr-review
create-pr → 已合并至 auto-pr
generate-pr-description → 已合并至 auto-pr --description-only

独立 skill：

code-review-expert 仍可用于更深的 review-first / MR 场景，也可在高风险 PR 的 pr-review 中作为 expert mode 额外补一轮
issue-release-followup 适合”功能已修复并发布后”的 issue 回访，而不是单个 issue 的一般答复
branch-diff-review 适合本地 git 分支之间的差异理解与优化审视，不依赖任何托管平台的 PR / MR 上下文

推荐起手入口：

不确定该用哪个 workflow 时，优先从 open-source-flow 开始
已经明确知道当前处于哪一段时，再直接进入对应的 stage skill

并行处理约定：

一个 issue 对应一个功能分支
当本地已有未完成工作或需要并行处理多个 issue 时，优先使用独立 worktree / workspace，而不是复用同一个脏工作区

License

MIT License

Published

Vulnerabilities

Links

Maintainers

Keywords

Readme

Skills

目录结构

平台基础层

用法

安装到 Claude Code

安装到 Qwen CLI

当前仓库结构

安装脚本

导出工作流

CI 与 CLI 的区别

全局安装方式

本地 Control Plane

添加新 Skill

工作流矩阵

Review Skill 区分

如何开始

场景 0：我有一个 PR/MR 链接，想把源分支导入当前仓库

场景 1：我已经有一个 Issue，要完整走完解决链路

场景 2：我还没有 Issue，想先确认是否值得建单

场景 3：我希望把校验也完整纳入流程

场景 4：某个功能已经合并并发布，想批量回访相关 issue

场景 5：拉某个 assignee 的 issue / PR 队列，并只看还需要人处理的项

拉完队列后，下一步该用哪个 Skill？

场景 6：review 当前分支和目标分支的差异，并判断还能怎么优化

场景 7：我有一个 parent issue，想把关联 issue 拉出来并过滤掉已处理项

场景 8：我想为新产生的 issue 推荐负责人，或者在高置信度时自动 assign

场景 9：我有一个具体 issue，想先深分析再决定 assign 给谁

推荐触发语句

Codex 在流程里做什么

License