cc-devflow 4.5.7 → 4.5.8

package/.claude/skills/cc-simplify/CHANGELOG.md

@@ -1,5 +1,11 @@
 # CC-Simplify Skill Changelog
 
+## v1.4.1 - 2026-05-10
+
+- make `cc-simplify` itself the explicit trigger for automatic read-only subagent review in ClaudeCode and Codex environments
+- prefer ClaudeCode `Task` / subAgent support or Codex built-in `explorer` / `default` agents without requiring an extra user prompt
+- require a truthful fallback report when the host does not expose any subagent tool, instead of pretending subagents ran
+
 ## v1.4.0 - 2026-04-28
 
 - add deep-module architecture review checks for shallow wrappers, hypothetical seams, and complexity that should move behind a smaller interface

package/.claude/skills/cc-simplify/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: cc-simplify
-version: 1.4.0
-description: "Use when changed code needs a Codex-native simplification pass for scope drift, reuse, code quality, efficiency, test quality, and confidence-gated smell fixes before cc-check or cc-act."
+version: 1.4.1
+description: "Use when changed code needs an automatic subagent-backed simplification pass for scope drift, reuse, code quality, efficiency, test quality, and confidence-gated smell fixes before cc-check or cc-act."
 ---
 
 # CC-Simplify
@@ -35,21 +35,32 @@ ONLY FIX CONFIRMED SMELLS. DO NOT BEAUTIFY BY GUESS.
 3. 如果变更跨多个互不相关模块，先按模块分组；不要让一个 cleanup pass 变成大扫除。
 4. 只审当前 diff 新增或本次改动扩大后的坏味道。历史债只在它阻挡当前交付或被本次 diff 放大时进入清理范围。
 
-## Phase 2: Codex 智能体评审
+## Phase 2: 自动子智能体评审
 
-如果当前环境支持 Codex 多智能体，并且用户已经明确触发 `cc-simplify` 或要求并行评审，可以构建只读评审智能体。
+触发 `cc-simplify` 本身就构成用户对子智能体 / subAgent 评审的明确授权。不要要求用户在 `[$cc-simplify]` 之外再补一句“请开启子智能体”。
+
+只要当前宿主支持子智能体，必须自动启动只读评审智能体；主线程只负责汇总、验证 finding、实际修复和最终验证。
 
 ### 调度原则
 
-- Codex 中优先使用 `spawn_agent(agent_type="explorer")` 创建只读评审智能体。
-- 如果当前环境没有 `explorer`，使用默认智能体也必须在 prompt 里写明：只读审查，不编辑文件。
+- ClaudeCode 环境：使用可用的 `Task` / subAgent 机制自动创建只读评审 subAgent。
+- Codex App / Codex 工具环境：优先使用内置 `explorer` 子智能体做只读评审；不要假设 ClaudeCode 的 `Task` / `subAgent` 语义存在。
+- 在暴露 `spawn_agent` 工具的 Codex 环境里，使用 `spawn_agent(agent_type="explorer", fork_context=false, ...)`；如果没有 `explorer`，使用 `default` 也必须在 prompt 里写明：只读审查，不编辑文件。
+- `cc-simplify` 的触发就是对子智能体的明确请求；不要再等待用户二次授权。
+- 不依赖 repo-local `.codex/agents/*.toml` 自定义 agent 名称来完成核心流程。自定义 agent 可以作为增强，但主流程必须能依赖 Codex 内置 `explorer` / `default` 或宿主内置 subAgent 机制。
 - 只把只读评审交给智能体；主线程负责最终判断和实际编辑。
 - 每个智能体拿到同一份完整 diff、相关任务/设计/spec 路径、当前 repo 根目录。
 - 智能体不能改文件，只输出结构化 findings。
-- 如果没有多智能体能力，主线程按同样清单顺序执行。
-- 小 diff 不强制开智能体：少于约 50 行且只触碰单一文件时，主线程执行同一清单即可。
+- 如果当前运行时没有子智能体工具，或工具调用被上层策略禁止，主线程按同样清单顺序执行，并在报告里写 `Agents used: no (subagent tool unavailable)`；不要伪造子智能体结果。
+- 小 diff 也要尝试启动子智能体；如果资源或宿主限制不适合三路并行，至少启动一个合并维度的只读 reviewer。
 - 条件 specialist 只在对应 scope 出现时启用；不要为了“完整”启动无关评审。
 
+默认调度：
+
+- 大 diff / 多文件 diff：启动 Agent A、Agent B、Agent C 三个只读评审智能体。
+- 小 diff / 单文件 diff：至少启动一个 combined reviewer，覆盖 A/B/C 三组检查。
+- 命中 security / api-contract / release / frontend-performance 时，再启动对应 specialist；如果 specialist 发现 `critical`，再启动 Red Team 只读复查。
+
 智能体 prompt 必须自包含：
 
 ```text

package/CHANGELOG.md

@@ -9,11 +9,18 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [4.5.8] - 2026-05-11
+
+### Changed
+
+- Updated `cc-review` with a risk-lane review swarm profile so broad implementation and PR-landing reviews separate intent/regression, security/privacy, performance/reliability, and contracts/coverage findings before main-thread triage.
+- Added the PR Harness skill lane: `cc-next` selects roadmap-aware next work, `cc-dev` drives current-worktree PDCA/IDCA goals to a remote PR, `cc-pr-review` reviews remote PRs in a separate session, and `cc-pr-land` lands reviewed PRs with rebase-first main parity proof.
+
 ## [4.5.7] - 2026-05-10
 
 ### Changed
 
-- Added public `cc-review` as an optional deep review skill that branches between plan-stage and implementation-stage review, keeps heavyweight methods in progressive references, checks in-scope code smells, and records Browser/Computer Use plus log evidence when UI or runtime behavior is involved.
+- Added public `cc-review` as an optional deep review skill that branches between plan-stage and implementation-stage review, builds a stateful review plan, dispatches read-only reviewer subAgents when available, records per-node review ledger entries, checks in-scope code smells, and records Browser/Computer Use plus log evidence when UI or runtime behavior is involved.
 - Updated `cc-roadmap` and `cc-plan` with AI Leverage Route/Decision Lens gates that require real user/operator, status quo workaround, human-vs-agent effort, complete-lake boundary, ocean boundary, and boil-lake/sharp-wedge/needs-evidence/pivot verdicts before work becomes implementation-ready.
 - Updated `cc-plan` with an opt-in External Best-Practice Validation gate that records generalized search approval, source trust, repo-fit verdicts, and skip reasons in durable planning artifacts.
 - Updated `cc-plan` Decision Question options to require `A/B/C` lettered choices while keeping `D1` / `D2` as question IDs.

package/README.md

@@ -14,13 +14,42 @@ CC-DevFlow is a small, explicit workflow system for agent coding. It gives an AI
 ```text
 cc-roadmap
 
+PR Harness: cc-next -> cc-dev -> cc-pr-review -> cc-pr-land
+
 PDCA: cc-plan        -> [cc-review] -> cc-do -> [cc-review] -> cc-check -> cc-act
 IDCA: cc-investigate -> [cc-review] -> cc-do -> [cc-review] -> cc-check -> cc-act
 ```
 
+```mermaid
+flowchart TD
+  Roadmap["cc-roadmap\nProduct direction and staged truth"] --> Next["cc-next\nPick next ready Goal Packet"]
+  Next --> Dev["cc-dev\nDrive current worktree to PR"]
+
+  Dev --> Route{"Route"}
+  Route -->|Feature or change| Plan["cc-plan\nFreeze scope and tasks"]
+  Route -->|Bug or regression| Investigate["cc-investigate\nFreeze root cause and repair boundary"]
+
+  Plan --> PlanReview["cc-review\nOptional plan review"]
+  Investigate --> PlanReview
+  PlanReview --> Do["cc-do\nImplement with evidence"]
+  Plan --> Do
+  Investigate --> Do
+
+  Do --> ImplReview["cc-review\nOptional implementation review"]
+  ImplReview --> Check["cc-check\nFresh verification verdict"]
+  Do --> Check
+  Check --> Act["cc-act\nCreate or update remote PR"]
+  Act --> PRReview["cc-pr-review\nSeparate PR review session"]
+  PRReview --> PRLand["cc-pr-land\nRebase, land, prove main parity"]
+  PRReview -->|Fixes required| Dev
+  PRLand --> Main["main\nLocal and remote parity"]
+```
+
+![CC-DevFlow PR Harness visual workflow](./docs/assets/cc-devflow-pr-harness-en.svg)
+
 ## Why cc-devflow
 
-- **Small public surface**: six core workflow skills, one optional deep review skill, plus a CLI for installation and platform adaptation.
+- **Small public surface**: core workflow skills, a PR Harness lane, one optional deep review skill, plus a CLI for installation and platform adaptation.
 - **Evidence before done**: implementation must pass through verification proof before shipping or handoff.
 - **Skill-first distribution**: the public contract lives in `.claude/skills/<skill>/SKILL.md` and `PLAYBOOK.md`, not in hidden runtime behavior.
 - **Multi-platform output**: install once, then adapt for Codex, Cursor, Qwen, Antigravity, and related agent environments.
@@ -56,17 +85,21 @@ Refresh every supported platform output:
 npx cc-devflow@latest adapt --cwd /path/to/your/project --all
 ```
 
-After installation, ask your agent to use the workflow skills directly. Start with `cc-roadmap` for product direction, use `cc-plan` for new work, use `cc-investigate` for bugs, optionally run `cc-review` on complex frozen plans or investigations, then continue through `cc-do`, optional implementation `cc-review`, `cc-check`, and `cc-act`.
+After installation, ask your agent to use the workflow skills directly. Start with `cc-roadmap` for product direction. Use `cc-next` to select the next roadmap-aware target, `cc-dev` to drive the current worktree through PDCA or IDCA until a remote PR is opened, `cc-pr-review` to review that PR in a separate session, and `cc-pr-land` to land reviewed PRs into main. For manual core workflow work, use `cc-plan` for new work, use `cc-investigate` for bugs, optionally run `cc-review` on complex frozen plans or investigations, then continue through `cc-do`, optional implementation `cc-review`, `cc-check`, and `cc-act`.
 
 ## Workflow Skills
 
 | Skill | Use it when | Main output |
 | --- | --- | --- |
 | `cc-roadmap` | You need product direction, staged scope, or backlog order | `devflow/roadmap.json`, `devflow/ROADMAP.md`, deprecated `devflow/BACKLOG.md` |
+| `cc-next` | You need to pick the next roadmap-aware ready target from roadmap and issue truth | one Goal Packet for `cc-dev` |
+| `cc-dev` | A selected objective should be driven in the current worktree to a remote PR | PDCA/IDCA artifacts plus a PR or handoff |
 | `cc-plan` | A feature or change needs scope, design, and task freezing | `planning/design.md`, `planning/tasks.md`, `task-manifest.json` |
 | `cc-investigate` | A bug needs symptom, reproduction, root cause, and repair boundary | `planning/analysis.md`, `planning/tasks.md`, `task-manifest.json` |
 | `cc-do` | Planned or investigated work needs implementation | code, tests, checkpoints, scratch runtime |
 | `cc-review` | Complex plans, investigations, or diffs need optional deep multi-round review before implementation or verification | `cc-review-report.md`, optional `cc-review-findings.json` |
+| `cc-pr-review` | A remote PR needs an independent review session before landing | PR review packet, findings, and landing verdict |
+| `cc-pr-land` | Reviewed PRs need rebase-first landing into main with parity proof | integrated main plus local/remote parity evidence |
 | `cc-check` | Work needs fresh verification evidence | `report-card.json` |
 | `cc-act` | Verified work needs a PR, local handoff, release note, or closeout | one final handoff file |
 
@@ -83,7 +116,7 @@ Canonical language and durable decisions stay inside cc-devflow-native sources:
 
 `cc-plan` freezes more implementation decisions before `cc-do` starts. Non-trivial plans compare minimal viable and ideal architecture options, full designs include decision horizon plus error/rescue mapping, and test-first plans record test framework evidence, public test seams, spec-style test names, public verification paths, behavior assertions, mock boundaries, coverage quality, mandatory regression tests, interface depth, Green minimality guards, refactor candidates, and vertical tracer-bullet slices when existing behavior changes. Before handoff, `cc-plan` and `cc-investigate` also reconcile the source roadmap item so RM status, REQ/FIX binding, progress, and spec diagnosis do not drift from the frozen change artifacts.
 
-`cc-review` is optional and deeper than `cc-check`. It can run immediately after `cc-plan` / `cc-investigate` to review the frozen plan or root-cause contract, or after `cc-do` to review the implementation. It classifies the input as plan-stage or implementation-stage, then runs the matching review branch: plan reviews borrow strategy/design/engineering/DX methods through progressive references, while implementation reviews inspect diff scope, code smells, tests, UI/runtime behavior, Browser/Computer Use evidence, and logs when applicable. Findings route back to `cc-plan` or `cc-do`; clean implementation reviews continue to `cc-check`.
+`cc-review` is optional and deeper than `cc-check`. It can run immediately after `cc-plan` / `cc-investigate` to review the frozen plan or root-cause contract, or after `cc-do` to review the implementation. It first reads prior review records and current git/artifact delta, writes a review plan, then checks review nodes one by one with ledger entries. When the host supports subagents, selected nodes can be dispatched to independent read-only reviewers so strategy, engineering, design, DX, smell, test, and runtime checks do not share one contaminated context. Broad implementation reviews can use separate risk lanes for intent/regression, security/privacy, performance/reliability, and contracts/coverage before the main thread triages raw findings. Plan reviews borrow strategy/design/engineering/DX methods through progressive references, while implementation reviews inspect diff scope, code smells, tests, UI/runtime behavior, Browser/Computer Use evidence, and logs when applicable. Findings route back to `cc-plan` or `cc-do`; clean implementation reviews continue to `cc-check`.
 
 ## Verification And Ship Gates
 
@@ -120,10 +153,14 @@ node bin/cc-devflow-cli.js adapt --cwd /tmp/example-project --platform codex
 
 ```bash
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-roadmap
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-next
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-dev
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-plan
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-investigate
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-do
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-review
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-pr-review
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-pr-land
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-check
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-act
 ```
@@ -186,10 +223,14 @@ Each shipped skill keeps its runtime contract local:
 The currently distributed skill folders are:
 
 - `.claude/skills/cc-roadmap/`
+- `.claude/skills/cc-next/`
+- `.claude/skills/cc-dev/`
 - `.claude/skills/cc-plan/`
 - `.claude/skills/cc-investigate/`
 - `.claude/skills/cc-do/`
 - `.claude/skills/cc-review/`
+- `.claude/skills/cc-pr-review/`
+- `.claude/skills/cc-pr-land/`
 - `.claude/skills/cc-check/`
 - `.claude/skills/cc-act/`
 - `.claude/skills/cc-spec-init/`
@@ -223,6 +264,14 @@ npm run verify:publish
 
 The main contributor guide is [`CONTRIBUTING.md`](./CONTRIBUTING.md). It explains the public surface rules, local CLI smoke tests, documentation rules, and PR expectations.
 
+## Discussion
+
+Scan the QR code to join the cc-devflow WeChat group for feedback, usage notes, and feature requests.
+
+<img src="./docs/assets/wechat-group-qr.jpg" alt="cc-devflow WeChat group QR code" width="320" />
+
+If the QR code expires, please open an issue so the maintainers can refresh it.
+
 ## Community
 
 - Star the project if the workflow is useful: [GitHub stars](https://github.com/Dimon94/cc-devflow/stargazers)

package/README.zh-CN.md

@@ -14,13 +14,42 @@ CC-DevFlow 是一个给 Agent 编程时代准备的小而明确的工作流系
 ```text
 cc-roadmap
 
+PR Harness: cc-next -> cc-dev -> cc-pr-review -> cc-pr-land
+
 PDCA: cc-plan        -> [cc-review] -> cc-do -> [cc-review] -> cc-check -> cc-act
 IDCA: cc-investigate -> [cc-review] -> cc-do -> [cc-review] -> cc-check -> cc-act
 ```
 
+```mermaid
+flowchart TD
+  Roadmap["cc-roadmap\n产品方向和阶段真相"] --> Next["cc-next\n选择下一个 Goal Packet"]
+  Next --> Dev["cc-dev\n当前 worktree 自动推进到 PR"]
+
+  Dev --> Route{"路线"}
+  Route -->|新需求或变更| Plan["cc-plan\n冻结范围和任务"]
+  Route -->|Bug 或回归| Investigate["cc-investigate\n冻结根因和修复边界"]
+
+  Plan --> PlanReview["cc-review\n可选方案 Review"]
+  Investigate --> PlanReview
+  PlanReview --> Do["cc-do\n实现并留下证据"]
+  Plan --> Do
+  Investigate --> Do
+
+  Do --> ImplReview["cc-review\n可选实现 Review"]
+  ImplReview --> Check["cc-check\n新鲜验证裁决"]
+  Do --> Check
+  Check --> Act["cc-act\n创建或更新远程 PR"]
+  Act --> PRReview["cc-pr-review\n单独会话 Review PR"]
+  PRReview --> PRLand["cc-pr-land\nRebase 合并并证明 main parity"]
+  PRReview -->|需要修复| Dev
+  PRLand --> Main["main\n本地和远程一致"]
+```
+
+![CC-DevFlow PR Harness 中文可视化流程](./docs/assets/cc-devflow-pr-harness-zh.svg)
+
 ## 为什么用 cc-devflow
 
-- **公开入口很小**：6 个核心 workflow skill、1 个可选深度 review skill，加一个负责安装和平台适配的 CLI。
+- **公开入口很小**：核心 workflow skill、PR Harness 链路、1 个可选深度 review skill，加一个负责安装和平台适配的 CLI。
 - **先证据后完成**：实现之后必须经过验证证据，才能进入 ship 或 handoff。
 - **Skill-first 分发**：公开契约写在 `.claude/skills/<skill>/SKILL.md` 和 `PLAYBOOK.md`，不依赖隐藏运行时语义。
 - **多平台产物**：一次安装，再生成 Codex、Cursor、Qwen、Antigravity 等 Agent 环境需要的输出。
@@ -56,17 +85,21 @@ npx cc-devflow@latest adapt --cwd /path/to/your/project --platform antigravity
 npx cc-devflow@latest adapt --cwd /path/to/your/project --all
 ```
 
-安装完成后，直接让 Agent 使用这些 workflow skill。产品方向先走 `cc-roadmap`，新需求走 `cc-plan`，Bug 和 regression 走 `cc-investigate`；复杂计划或根因合同冻结后可以先接 `cc-review`，再进入 `cc-do`；实现复杂时还可以再接一次实现 `cc-review`，最后进入 `cc-check` 和 `cc-act`。
+安装完成后，直接让 Agent 使用这些 workflow skill。产品方向先走 `cc-roadmap`。需要自动选择下一步时走 `cc-next`；选中目标后用 `cc-dev` 在当前 worktree 内自动跑 PDCA 或 IDCA，直到远程 PR 打开；PR 用单独会话跑 `cc-pr-review`；review 后用单独会话跑 `cc-pr-land` 合并并证明 main parity。手动核心链路仍然是：新需求走 `cc-plan`，Bug 和 regression 走 `cc-investigate`；复杂计划或根因合同冻结后可以先接 `cc-review`，再进入 `cc-do`；实现复杂时还可以再接一次实现 `cc-review`，最后进入 `cc-check` 和 `cc-act`。
 
 ## Workflow Skill
 
 | Skill | 什么时候用 | 主要产物 |
 | --- | --- | --- |
 | `cc-roadmap` | 需要产品方向、阶段范围或 backlog 顺序 | `devflow/roadmap.json`、`devflow/ROADMAP.md`、deprecated `devflow/BACKLOG.md` |
+| `cc-next` | 需要从 roadmap 和 issue truth 里选下一个 ready 目标 | 交给 `cc-dev` 的 Goal Packet |
+| `cc-dev` | 已选目标要在当前 worktree 内自动推进到远程 PR | PDCA/IDCA 产物加 PR 或 handoff |
 | `cc-plan` | 新功能或变更需要澄清范围、设计方案、冻结任务 | `planning/design.md`、`planning/tasks.md`、`task-manifest.json` |
 | `cc-investigate` | Bug 需要症状、复现、根因和修复边界 | `planning/analysis.md`、`planning/tasks.md`、`task-manifest.json` |
 | `cc-do` | 已计划或已调查的任务需要实现 | 代码、测试、checkpoint、scratch runtime |
 | `cc-review` | 复杂方案、调查根因或 diff 需要在实现前或验证前做可选深度多轮 Review | `cc-review-report.md`，可选 `cc-review-findings.json` |
+| `cc-pr-review` | 远程 PR 需要单独会话做合并前 Review | PR review packet、findings 和 landing verdict |
+| `cc-pr-land` | 已 Review PR 需要 rebase-first 合并到 main 并证明 parity | 已集成 main 和本地 / 远程一致性证据 |
 | `cc-check` | 工作需要新鲜验证证据 | `report-card.json` |
 | `cc-act` | 已验证工作需要 PR、本地 handoff、release note 或 closeout | 唯一最终 handoff 文件 |
 
@@ -83,7 +116,7 @@ Canonical language 和 durable decisions 只收敛到 cc-devflow 原生真相源
 
 `cc-plan` 会在 `cc-do` 开始前冻结更多实现决策。非 trivial 计划需要比较 minimal viable 和 ideal architecture，full-design 需要包含 implementation decision horizon 和 error/rescue map；测试计划要记录测试框架证据、public test seam、spec-style test name、public verification path、behavior assertion、mock boundary、覆盖质量、强制 regression test、interface depth、Green minimality guard、refactor candidates 和 vertical tracer-bullet slices。交接前，`cc-plan` 和 `cc-investigate` 还会校准 source roadmap item，让 RM 状态、REQ/FIX 绑定、progress 和 spec diagnosis 不再漂移。
 
-`cc-review` 是可选的深度 Review，不替代 `cc-check`。它可以接在 `cc-plan` / `cc-investigate` 后审冻结的计划或根因合同，也可以接在 `cc-do` 后审实现。它先判断输入属于计划阶段还是实现阶段，再走对应分支：计划 Review 通过渐进式 references 借鉴 strategy / design / engineering / DX 方法；实现 Review 检查 diff 范围、代码坏味道、测试、UI/runtime 行为、Browser/Computer Use 证据和日志。Finding 回到 `cc-plan` 或 `cc-do`；实现 Review 干净后再进入 `cc-check`。
+`cc-review` 是可选的深度 Review，不替代 `cc-check`。它可以接在 `cc-plan` / `cc-investigate` 后审冻结的计划或根因合同，也可以接在 `cc-do` 后审实现。它先读取上次 Review 记录和当前 git/artifact delta，写出 Review 计划，再逐节点检查并写 ledger。宿主支持 subAgent 时，选中的节点可以派给独立只读 reviewer，让 strategy、engineering、design、DX、坏味道、测试和运行时审查不共享同一个被污染的上下文。复杂实现 Review 可以把 intent/regression、security/privacy、performance/reliability、contracts/coverage 拆成独立风险 lane，再由主线程聚合和筛掉弱 findings。计划 Review 通过渐进式 references 借鉴 strategy / design / engineering / DX 方法；实现 Review 检查 diff 范围、代码坏味道、测试、UI/runtime 行为、Browser/Computer Use 证据和日志。Finding 回到 `cc-plan` 或 `cc-do`；实现 Review 干净后再进入 `cc-check`。
 
 ## 验证与交付门禁
 
@@ -120,10 +153,14 @@ node bin/cc-devflow-cli.js adapt --cwd /tmp/example-project --platform codex
 
 ```bash
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-roadmap
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-next
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-dev
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-plan
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-investigate
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-do
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-review
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-pr-review
+npx skills add https://github.com/Dimon94/cc-devflow --skill cc-pr-land
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-check
 npx skills add https://github.com/Dimon94/cc-devflow --skill cc-act
 ```
@@ -186,10 +223,14 @@ npx cc-devflow config doctor --cwd /path/to/your/project
 当前分发目录：
 
 - `.claude/skills/cc-roadmap/`
+- `.claude/skills/cc-next/`
+- `.claude/skills/cc-dev/`
 - `.claude/skills/cc-plan/`
 - `.claude/skills/cc-investigate/`
 - `.claude/skills/cc-do/`
 - `.claude/skills/cc-review/`
+- `.claude/skills/cc-pr-review/`
+- `.claude/skills/cc-pr-land/`
 - `.claude/skills/cc-check/`
 - `.claude/skills/cc-act/`
 - `.claude/skills/cc-spec-init/`
@@ -223,6 +264,14 @@ npm run verify:publish
 
 主要贡献说明见 [`CONTRIBUTING.zh-CN.md`](./CONTRIBUTING.zh-CN.md)，里面包含公开入口规则、本地 CLI 冒烟验证、文档规则和 PR 期望。
 
+## 讨论交流
+
+欢迎扫码加入 cc-devflow 交流 1 群，反馈问题、交流使用体验或提出新功能建议。
+
+<img src="./docs/assets/wechat-group-qr.jpg" alt="cc-devflow 交流 1 群微信群二维码" width="320" />
+
+如果二维码过期，请在 issue 中提醒维护者更新。
+
 ## 社区与贡献
 
 - 如果这个工作流对你有用，可以给项目一个 Star：[GitHub stars](https://github.com/Dimon94/cc-devflow/stargazers)

package/config/distributable-skills.json

@@ -1,19 +1,27 @@
 {
   "publicSkills": [
     "cc-roadmap",
+    "cc-next",
+    "cc-dev",
     "cc-plan",
     "cc-investigate",
     "cc-do",
     "cc-review",
+    "cc-pr-review",
+    "cc-pr-land",
     "cc-check",
     "cc-act"
   ],
   "distributedSkills": [
     "cc-roadmap",
+    "cc-next",
+    "cc-dev",
     "cc-plan",
     "cc-investigate",
     "cc-do",
     "cc-review",
+    "cc-pr-review",
+    "cc-pr-land",
     "cc-check",
     "cc-act",
     "cc-spec-init",

package/docs/assets/cc-devflow-pr-harness-en.svg

@@ -0,0 +1,153 @@
+<svg xmlns="http://www.w3.org/2000/svg" width="1600" height="1000" viewBox="0 0 1600 1000" role="img" aria-labelledby="title desc">
+  <title id="title">CC-DevFlow PR Harness workflow</title>
+  <desc id="desc">A visual workflow diagram showing roadmap selection, goal-driven development, PDCA and IDCA loops, PR review, and PR landing with main parity.</desc>
+  <defs>
+    <linearGradient id="bg" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#07111f"/>
+      <stop offset="0.48" stop-color="#0d2638"/>
+      <stop offset="1" stop-color="#102414"/>
+    </linearGradient>
+    <linearGradient id="blue" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#4cc9f0"/>
+      <stop offset="1" stop-color="#4361ee"/>
+    </linearGradient>
+    <linearGradient id="green" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#b8f05a"/>
+      <stop offset="1" stop-color="#2fbf71"/>
+    </linearGradient>
+    <linearGradient id="amber" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#ffd166"/>
+      <stop offset="1" stop-color="#ef8354"/>
+    </linearGradient>
+    <linearGradient id="violet" x1="0" y1="0" x2="1" y2="1">
+      <stop offset="0" stop-color="#d0a2ff"/>
+      <stop offset="1" stop-color="#7b2cbf"/>
+    </linearGradient>
+    <filter id="shadow" x="-20%" y="-20%" width="140%" height="140%">
+      <feDropShadow dx="0" dy="16" stdDeviation="16" flood-color="#000000" flood-opacity="0.35"/>
+    </filter>
+    <marker id="arrow" markerWidth="16" markerHeight="16" refX="12" refY="8" orient="auto" markerUnits="strokeWidth">
+      <path d="M2,2 L14,8 L2,14 Z" fill="#d7e3f4"/>
+    </marker>
+    <style>
+      .title{font:800 62px Inter,Arial,sans-serif;fill:#f8fbff;letter-spacing:0}
+      .subtitle{font:500 26px Inter,Arial,sans-serif;fill:#bdd0e8}
+      .label{font:800 26px Inter,Arial,sans-serif;fill:#f8fbff;letter-spacing:0}
+      .small{font:500 18px Inter,Arial,sans-serif;fill:#d7e3f4}
+      .micro{font:700 15px Inter,Arial,sans-serif;fill:#0a1421;letter-spacing:.5px}
+      .note{font:600 18px Inter,Arial,sans-serif;fill:#f8fbff}
+      .muted{font:500 16px Inter,Arial,sans-serif;fill:#9fb4cd}
+      .card{fill:#102033;stroke:#27445f;stroke-width:2;filter:url(#shadow)}
+      .lane{fill:#0b1728;stroke:#27445f;stroke-width:2}
+      .line{fill:none;stroke:#d7e3f4;stroke-width:4;marker-end:url(#arrow)}
+      .thin{fill:none;stroke:#6c819b;stroke-width:3;stroke-dasharray:8 10;marker-end:url(#arrow)}
+    </style>
+  </defs>
+  <rect width="1600" height="1000" fill="url(#bg)"/>
+  <circle cx="140" cy="125" r="220" fill="#2247ff" opacity="0.12"/>
+  <circle cx="1450" cy="820" r="260" fill="#2fbf71" opacity="0.13"/>
+
+  <text x="80" y="96" class="title">CC-DevFlow PR Harness</text>
+  <text x="84" y="136" class="subtitle">Roadmap-aware goal autopilot: pick next work, drive to PR, review separately, land with main parity.</text>
+
+  <rect x="80" y="190" width="1440" height="150" rx="18" class="lane"/>
+  <text x="110" y="225" class="note">Navigation layer</text>
+  <g transform="translate(130 250)">
+    <rect width="260" height="70" rx="16" fill="url(#blue)"/>
+    <text x="24" y="32" class="label">cc-roadmap</text>
+    <text x="24" y="56" class="small">product order and staged truth</text>
+  </g>
+  <g transform="translate(520 250)">
+    <rect width="260" height="70" rx="16" fill="url(#green)"/>
+    <text x="24" y="32" class="label">cc-next</text>
+    <text x="24" y="56" class="small">choose one ready Goal Packet</text>
+  </g>
+  <g transform="translate(910 250)">
+    <rect width="300" height="70" rx="16" fill="url(#amber)"/>
+    <text x="24" y="32" class="label">cc-dev</text>
+    <text x="24" y="56" class="small">current worktree to remote PR</text>
+  </g>
+  <path class="line" d="M390 285 H510"/>
+  <path class="line" d="M780 285 H900"/>
+
+  <rect x="80" y="390" width="675" height="335" rx="18" class="lane"/>
+  <text x="110" y="426" class="note">PDCA feature loop</text>
+  <text x="110" y="455" class="muted">For new behavior, API/UI changes, and requirement work</text>
+  <g transform="translate(120 490)">
+    <rect width="230" height="72" rx="14" class="card"/>
+    <text x="24" y="32" class="label">cc-plan</text>
+    <text x="24" y="57" class="small">scope, design, tasks</text>
+  </g>
+  <g transform="translate(455 490)">
+    <rect width="230" height="72" rx="14" class="card"/>
+    <text x="24" y="32" class="label">cc-do</text>
+    <text x="24" y="57" class="small">red, green, refactor</text>
+  </g>
+  <g transform="translate(120 615)">
+    <rect width="230" height="72" rx="14" class="card"/>
+    <text x="24" y="32" class="label">cc-check</text>
+    <text x="24" y="57" class="small">fresh evidence verdict</text>
+  </g>
+  <g transform="translate(455 615)">
+    <rect width="230" height="72" rx="14" class="card"/>
+    <text x="24" y="32" class="label">cc-act</text>
+    <text x="24" y="57" class="small">create or update PR</text>
+  </g>
+  <path class="line" d="M350 526 H445"/>
+  <path class="line" d="M570 562 V605"/>
+  <path class="line" d="M455 651 H360"/>
+
+  <rect x="845" y="390" width="675" height="335" rx="18" class="lane"/>
+  <text x="875" y="426" class="note">IDCA bug loop</text>
+  <text x="875" y="455" class="muted">For regressions, broken behavior, crashes, and flaky failures</text>
+  <g transform="translate(885 490)">
+    <rect width="270" height="72" rx="14" class="card"/>
+    <text x="24" y="32" class="label">cc-investigate</text>
+    <text x="24" y="57" class="small">repro, root cause, boundary</text>
+  </g>
+  <g transform="translate(1245 490)">
+    <rect width="230" height="72" rx="14" class="card"/>
+    <text x="24" y="32" class="label">cc-do</text>
+    <text x="24" y="57" class="small">repair with evidence</text>
+  </g>
+  <g transform="translate(885 615)">
+    <rect width="230" height="72" rx="14" class="card"/>
+    <text x="24" y="32" class="label">cc-check</text>
+    <text x="24" y="57" class="small">prove the symptom is fixed</text>
+  </g>
+  <g transform="translate(1245 615)">
+    <rect width="230" height="72" rx="14" class="card"/>
+    <text x="24" y="32" class="label">cc-act</text>
+    <text x="24" y="57" class="small">create or update PR</text>
+  </g>
+  <path class="line" d="M1155 526 H1235"/>
+  <path class="line" d="M1360 562 V605"/>
+  <path class="line" d="M1245 651 H1125"/>
+
+  <path class="thin" d="M1060 320 C950 360 830 365 685 410"/>
+  <path class="thin" d="M1060 320 C1180 360 1230 365 1260 410"/>
+
+  <rect x="250" y="790" width="1100" height="120" rx="22" fill="#101f2f" stroke="#3c5a78" stroke-width="2" filter="url(#shadow)"/>
+  <g transform="translate(305 815)">
+    <rect width="230" height="64" rx="14" fill="url(#violet)"/>
+    <text x="24" y="30" class="label">cc-pr-review</text>
+    <text x="24" y="52" class="small">separate PR review session</text>
+  </g>
+  <g transform="translate(690 815)">
+    <rect width="230" height="64" rx="14" fill="url(#green)"/>
+    <text x="24" y="30" class="label">cc-pr-land</text>
+    <text x="24" y="52" class="small">rebase and land reviewed PR</text>
+  </g>
+  <g transform="translate(1075 815)">
+    <rect width="220" height="64" rx="14" fill="url(#blue)"/>
+    <text x="24" y="30" class="label">main</text>
+    <text x="24" y="52" class="small">local and remote parity</text>
+  </g>
+  <path class="line" d="M535 847 H680"/>
+  <path class="line" d="M920 847 H1065"/>
+  <path class="thin" d="M805 815 C720 760 650 735 570 690"/>
+  <path class="thin" d="M805 815 C920 760 1110 735 1360 690"/>
+
+  <rect x="84" y="930" width="1432" height="42" rx="12" fill="#07111f" stroke="#27445f"/>
+  <text x="110" y="957" class="small">Boundary: cc-dev never creates nested worktrees and never merges PRs. Review and landing are separate sessions by design.</text>
+</svg>