cc-devflow 4.5.7 → 4.5.9

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

@@ -1,5 +1,11 @@
 # Roadmap Skill Changelog
 
+## v5.3.0 - 2026-05-11
+
+- add the Roadmap Funnel Protocol with fixed F0-F9 rounds for direction mode, demand reality, status quo, specific human/sponsor, wedge/lake boundary, observation signal, future fit, premise challenge, alternatives, and route approval
+- persist the funnel transcript in `devflow/roadmap.json` and render it into `devflow/ROADMAP.md` so route decisions survive beyond chat
+- upgrade backlog handoff fields so ready RM items carry source funnel rounds, frozen decisions, do-not-re-decide constraints, and remaining blocking questions for downstream `cc-plan`
+
 ## v5.2.0 - 2026-05-09
 
 - add project-direction routing and brand-neutral founder guardrails

package/.claude/skills/cc-roadmap/PLAYBOOK.md

@@ -20,6 +20,8 @@
 8. 先判断 planning posture 和 evidence maturity，再决定追问哪些问题；不要用同一套问题硬套 idea、已有用户、付费客户、infra 和 recovery 场景。
 9. developer-facing / operator-facing 路线必须写清 target user、time to first value、magic moment 和 adoption bottleneck。
 10. 先对齐 `devflow/specs/`、roadmap/backlog 和历史 design decision，再命名 stage、capability、RM 和 backlog；术语或决策冲突必须成为显式路线风险。
+11. Roadmap Funnel Protocol 必须固定推进：方向、真实需求、现状、具体人、wedge/lake、观察信号、future fit、premise challenge、alternatives、route approval。
+12. 每轮要么由证据回答，要么问用户一个 `D<N>` 决策题，要么写明 skipped reason；不能让关键轮次停在聊天记忆里。
 
 ## Local Kit
 
@@ -48,6 +50,31 @@
 
 先把这些材料压成 `Context Snapshot`，再追问用户。
 
+## Roadmap Funnel Protocol
+
+固定轮次：
+
+1. `F0 Direction Mode`
+2. `F1 Demand / Operator Reality`
+3. `F2 Status Quo`
+4. `F3 Specific Human / Sponsor`
+5. `F4 Narrowest Wedge / Lake Boundary`
+6. `F5 Observation / Feedback Signal`
+7. `F6 Future Fit`
+8. `F7 Premise Challenge`
+9. `F8 Alternatives`
+10. `F9 Route Approval`
+
+执行规则：
+
+1. 一次只推进一轮；需要用户时只问一个 `D<N> - <decision title>`。
+2. 每个问题必须有推荐答案、证据来源、选项影响和 STOP。
+3. 用户回答后先更新 `roadmapFunnel.rounds[]`，再继续下一轮。
+4. 用户要求跳过时，最多再问 2 个最关键剩余问题，然后必须仍然跑 `F7` 和 `F8`。
+5. `F7` 把隐含前提写成可同意 / 反对的句子；反对时回到受影响轮次重算。
+6. `F8` 至少给最小路径和理想架构路径；非平凡项目给第三条 lateral / decomposition 路径。
+7. `F9` 才能冻结 route、stage、ready RM 和 `cc-plan` handoff。
+
 ## Force Reality First
 
 至少逼清这 5 件事：
@@ -119,10 +146,12 @@
 `devflow/roadmap.json`
 - single editable roadmap state
 - output policy, meta, context, evidence, route, stages, items, handoff, and architecture
+- `context.roadmapFunnel.rounds[]` stores every fixed round, answer source, evidence, skipped reason, and decision impact
 - flat `architecture.nodes` / `architecture.edges` used to generate Mermaid
 
 `devflow/ROADMAP.md`
 - version / skill version / context snapshot / evidence ledger
+- Roadmap Funnel Transcript with F0-F9 answers and skipped reasons
 - 1-3 个阶段
 - 独立子系统拆分判断
 - 每阶段目标
@@ -139,6 +168,7 @@
 - deprecated compatibility projection; edit `devflow/roadmap.json` instead
 - 只保留会真的进入下一轮 `cc-plan` 的事项
 - 每项注明来源阶段、优先级、证据、`Depends On`、`Parallel With`、当前未知点、下一决策、是否 ready
+- ready 项必须带 `Source funnel rounds`、`Frozen decisions`、`Do not re-decide` 和 `Remaining blocking question`
 - developer-facing / operator-facing 条目要带 target user、time to first value、magic moment 和 adoption bottleneck，方便 `cc-plan` 继续做 DX 设计
 - `Backlog Meta`、`Queue`、`Dependency Handoff`、`Ready For Req-Plan`、`Parked` 由 `devflow/roadmap.json` 回渲染，避免 roadmap truth 和 backlog handoff 分叉
 

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

@@ -1,6 +1,6 @@
 ---
 name: cc-roadmap
-version: 5.2.0
+version: 5.3.0
 description: "Use when defining, resetting, or narrowing project direction, stage order, or backlog priority before a concrete requirement enters the PDCA loop."
 triggers:
   - "帮我定路线图"
@@ -42,6 +42,7 @@ entry_gate:
   - "If the ask contains multiple independent subsystems, decompose them into stages and RM candidates before refining any implementation detail."
   - "Do not decompose implementation tasks while the roadmap is still being decided."
   - "Apply the AI Leverage Route Lens before route approval: name the reachable user/operator, current workaround, human-vs-agent effort, complete-lake boundary, ocean boundary, first success signal, and kill signal."
+  - "Run the Roadmap Funnel Protocol as fixed one-question rounds; every round must either be answered from repo evidence, asked to the user, or explicitly skipped with reason."
   - "If AI makes a complete same-blast-radius route cheap and verifiable, prefer boil-lake over a timid MVP slice."
   - "If the route cannot name a real user/operator and current workaround, mark it as needs-evidence instead of producing implementation-ready RM handoff."
 exit_criteria:
@@ -50,6 +51,7 @@ exit_criteria:
   - "The roadmap shows an explicit RM dependency graph so serial blockers and parallel-ready work are obvious."
   - "The user-approved recommendation is explicit and grounded in current evidence."
   - "Each Stage 1 or ready-for-cc-plan item records an AI Leverage Route Lens verdict: boil-lake, sharp-wedge, needs-evidence, or pivot."
+  - "The Roadmap Funnel Transcript is persisted in `devflow/roadmap.json`, rendered into `devflow/ROADMAP.md`, and each ready RM carries the source funnel rounds, frozen decisions, and remaining blocking question."
 reroutes:
   - when: "The user is already discussing one concrete requirement, bug, or execution task."
     target: "cc-plan"
@@ -240,6 +242,39 @@ Verdict 只允许四种：
 5. 每条路线都要用一个具体 scenario 压测：谁在什么约束下，今天如何绕路，Stage 1 完成后哪一步不再发生。
 6. 硬决策才沉淀：只有 hard to reverse、surprising without context、real trade-off 三者同时成立，才进入 capability spec delta、roadmap decision note 或本次 design decision log。
 
+## Roadmap Funnel Protocol
+
+路线图必须像 office-hours 一样固定推进多轮，但输出必须是 source-neutral 的 `cc-roadmap` 产物，不暴露外部来源。
+
+每轮只允许处理一个 route-changing unknown。能从仓库证据回答就写 `answered-by-evidence`；不能回答才问用户；用户催促跳过时最多保留 2 个最关键问题，然后进入 premise challenge 和 alternatives。每个问题都必须给推荐答案、证据、反对时会改变的路线，并在回答后更新 `Roadmap Funnel Transcript`。
+
+固定轮次：
+
+1. `F0 Direction Mode`：确认项目目标模式，说明为什么不是其它模式。
+2. `F1 Demand / Operator Reality`：确认真实用户或操作者，以及他们今天是否真的痛。
+3. `F2 Status Quo`：确认现状 workaround、成本、失败方式；没有 workaround 默认 `needs-evidence`。
+4. `F3 Specific Human / Sponsor`：把类别词压成可命名角色、具体约束、职业/组织后果。
+5. `F4 Narrowest Wedge / Lake Boundary`：比较最窄 wedge、完整 same-blast-radius lake、ocean boundary。
+6. `F5 Observation / Feedback Signal`：确认看过真实使用、失败日志、运营证据或可复现实验；没有观察就写 Stage 1 observation task。
+7. `F6 Future Fit`：确认 6-12 个月后为什么更需要这条路，而不是只靠今天的热词。
+8. `F7 Premise Challenge`：把本轮隐含前提写成 2-4 条，逐条确认或修正。
+9. `F8 Alternatives`：至少给 2 条路线，非平凡项目给 3 条；必须包含最小路径与理想架构路径。
+10. `F9 Route Approval`：冻结推荐路线、拒绝路线、第一成功信号、kill signal、下一批 ready RM。
+
+STOP 规则：
+
+- 每次需要用户判断时只问一个 `D<N> - <decision title>`。
+- 选项只用 `A` / `B` / `C`，推荐项必须标 `(recommended)`。
+- 问完必须停止等待，不能同一轮继续生成最终 roadmap。
+- 用户回答后，先更新 transcript，再决定是否进入下一轮。
+
+产物规则：
+
+- `devflow/roadmap.json.context.roadmapFunnel.rounds[]` 记录每轮 `id`、`question`、`answerSource`、`answer`、`evidence`、`decisionImpact`、`status`。
+- `devflow/ROADMAP.md` 必须渲染 `## Roadmap Funnel Transcript`，让后续读者知道路线不是拍脑袋。
+- `devflow/BACKLOG.md` 的 ready RM 必须记录 `Source funnel rounds`、`Frozen decisions`、`Do not re-decide`、`Remaining blocking question`。
+- 没有闭合 `F7` 和 `F8` 时，不允许把任何 RM 标成 ready for `cc-plan`，除非用户给出已成形且有证据的计划；即便如此也要把跳过理由写入 transcript。
+
 ## Founder Advice Guardrail
 
 创业建议只能服务于 roadmap 质量，不是推广内容。遇到 `founder-business` 或 `internal-company`：
@@ -319,13 +354,15 @@ Verdict 只允许四种：
 1. 没有 `Context Snapshot`，不准给路线推荐。
 2. 没有 project direction mode、planning posture、evidence maturity 和 framing check，不准给路线推荐。
 3. 没有 native language / durable decision scan，不准给路线推荐；如果缺少 `devflow/specs/` 或历史决策材料，写成 `not present`，不要假装已对齐。
-4. 没有 2-3 条路线对比，不准直接拍脑袋定主线。
-5. 没有 exit signal / kill signal / non-goals，不算阶段冻结。
-6. 没有明确成功信号和下一决策，不准把事项放进 `Ready For Req-Plan`。
-7. developer-facing / operator-facing item 没有 target user、time to first value 或 adoption bottleneck，不准标成 ready。
-8. 没有 `RM dependency graph` 或 parallel-ready wave，不准宣称事项可以并发推进。
-9. 没有独立子系统拆分判断，不准把大而混杂的方向伪装成单一主线。
-10. 没有用户批准，不准把 roadmap item 下放到 `cc-plan`。
+4. 没有 `Roadmap Funnel Transcript`，不准给路线推荐。
+5. 没有 `F7 Premise Challenge` 和 `F8 Alternatives`，不准把事项标成 ready。
+6. 没有 2-3 条路线对比，不准直接拍脑袋定主线。
+7. 没有 exit signal / kill signal / non-goals，不算阶段冻结。
+8. 没有明确成功信号和下一决策，不准把事项放进 `Ready For Req-Plan`。
+9. developer-facing / operator-facing item 没有 target user、time to first value 或 adoption bottleneck，不准标成 ready。
+10. 没有 `RM dependency graph` 或 parallel-ready wave，不准宣称事项可以并发推进。
+11. 没有独立子系统拆分判断，不准把大而混杂的方向伪装成单一主线。
+12. 没有用户批准，不准把 roadmap item 下放到 `cc-plan`。
 
 ## Review Loop
 

package/.claude/skills/cc-roadmap/assets/BACKLOG_TEMPLATE.md

@@ -27,6 +27,10 @@
 ## Adoption Handoff
 
 - Project direction mode:
+- Source funnel rounds:
+- Frozen decisions:
+- Do not re-decide:
+- Remaining blocking question:
 - Direction-specific first question:
 - Founder / builder / infra guardrail:
 - Planning posture:
@@ -56,6 +60,10 @@
   - Expected spec delta:
   - Open risks:
   - First planning question:
+  - Source funnel rounds:
+  - Frozen decisions:
+  - Do not re-decide:
+  - Remaining blocking question:
   - Evidence maturity:
   - Target developer / operator:
   - Time to first value:

package/.claude/skills/cc-roadmap/assets/ROADMAP_TEMPLATE.md

@@ -53,6 +53,28 @@
 | Feasibility |  | High / Med / Low |  |  |
 | Distribution |  | High / Med / Low |  |  |
 
+## Roadmap Funnel Transcript
+
+| Round | Question | Answer source | Answer / decision | Evidence | Decision impact | Status |
+|-------|----------|---------------|-------------------|----------|-----------------|--------|
+| F0 Direction Mode |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+| F1 Demand / Operator Reality |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+| F2 Status Quo |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+| F3 Specific Human / Sponsor |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+| F4 Narrowest Wedge / Lake Boundary |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+| F5 Observation / Feedback Signal |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+| F6 Future Fit |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+| F7 Premise Challenge |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+| F8 Alternatives |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+| F9 Route Approval |  | repo-evidence / user-answer / skipped |  |  |  | pending |
+
+- Premises confirmed:
+- Premises rejected / revised:
+- Alternatives reviewed:
+- Approved route:
+- Open concerns:
+- Skipped rounds and reasons:
+
 ## AI Leverage Route Lens
 
 - Real user / operator:

package/.claude/skills/cc-roadmap/assets/TRACKING_TEMPLATE.json

@@ -5,7 +5,7 @@
   },
   "meta": {
     "roadmapVersion": "roadmap.v1",
-    "skillVersion": "5.2.0",
+    "skillVersion": "5.3.0",
     "status": "active",
     "lastUpdated": "2026-05-01",
     "currentFocusStage": "Stage 1"
@@ -32,6 +32,33 @@
       "verdict": "needs-evidence",
       "missingEvidence": []
     },
+    "roadmapFunnel": {
+      "status": "in-progress",
+      "currentRound": "F0",
+      "approvedRouteRound": "",
+      "rounds": [
+        {
+          "id": "F0",
+          "title": "Direction Mode",
+          "question": "What project-direction mode are we in, and why not the other modes?",
+          "answerSource": "repo-evidence | user-answer | skipped",
+          "answer": "",
+          "evidence": [],
+          "decisionImpact": "Selects the question set and default route shape",
+          "status": "pending",
+          "skippedReason": ""
+        }
+      ],
+      "premiseChallenge": [],
+      "alternativesReviewed": [],
+      "routeApproval": {
+        "approved": false,
+        "approvedRoute": "",
+        "approvedBy": "",
+        "approvedAt": "",
+        "openConcerns": []
+      }
+    },
     "canonicalTerms": [],
     "durableDecisionSources": []
   },
@@ -69,6 +96,10 @@
         "entryConstraints": "",
         "openRisks": "",
         "firstPlanningQuestion": "",
+        "sourceFunnelRounds": [],
+        "frozenDecisions": [],
+        "doNotRedecide": [],
+        "remainingBlockingQuestion": "",
         "requiredContextToLoad": "",
         "whyReadyNow": "",
         "parked": false,

package/.claude/skills/cc-roadmap/references/roadmap-dialogue.md

@@ -3,28 +3,27 @@
 ## Order
 
 0. 先做 `Context Snapshot`：现有 roadmap / backlog、capability specs、历史 design/analysis、最近提交、forcing functions、项目语言 / durable decisions
-1. 先判断 project direction mode：founder-business / internal-company / hackathon-demo / open-source-research / learning / side-project / infrastructure / recovery
-2. 用户是谁
-3. 今天靠什么笨办法活着
-4. 最强需求证据是什么
-5. 为什么现在必须解决
-6. deadline / capacity / dependency / distribution 约束是什么
-7. 当前最大的 adoption / trust / delivery 卡点是什么
-8. 核心术语是否已有 canonical definition，是否和现有 capability spec / roadmap decision 冲突
-9. 最窄突破口是什么
-10. 6-12 个月后会长成什么
-11. 给出 2-3 条路线图形状并明确推荐
-12. 冻结 1-3 个阶段，写 exit signal / kill signal / non-goals
-13. 画出 `RM dependency graph`，标出串行主链和 parallel-ready wave
-14. 标出哪些事项真的 ready for `cc-plan`
+1. `F0 Direction Mode`：project direction mode，为什么不是其它模式
+2. `F1 Demand / Operator Reality`：用户是谁，最强需求或运营证据是什么
+3. `F2 Status Quo`：今天靠什么笨办法活着，成本和失败方式是什么
+4. `F3 Specific Human / Sponsor`：具体人、具体角色、具体组织后果
+5. `F4 Narrowest Wedge / Lake Boundary`：最窄突破口、完整 lake、ocean boundary
+6. `F5 Observation / Feedback Signal`：真实观察、运行证据、demo 使用或待补证据任务
+7. `F6 Future Fit`：6-12 个月后为什么更需要它
+8. `F7 Premise Challenge`：核心前提、canonical language、capability/spec 冲突
+9. `F8 Alternatives`：给出 2-3 条路线图形状并明确推荐
+10. `F9 Route Approval`：冻结 1-3 个阶段、dependency graph、parallel wave、ready RM
 
 ## Question Rules
 
 - 一次只推进一个关键未知点
 - 每个问题附带推荐答案、证据来源，以及用户反对时会改变哪条路线
+- 问题编号使用 `D<N> - <decision title>`；选项只用 `A` / `B` / `C`，推荐项标 `(recommended)`
+- 每轮回答必须落入 `Roadmap Funnel Transcript`
 - 能从 repo / capability spec / roadmap / design / git history 得到答案时先查证，不问用户
 - 没证据时明确写 assumption
 - 用户没批准前，不把事项偷下放成 requirement
+- 用户催促跳过时，最多补问 2 个关键问题，但不能跳过 `F7 Premise Challenge` 和 `F8 Alternatives`
 
 ## Project Direction Modes
 
@@ -54,3 +53,4 @@
 - backlog 只收下一轮真会进入 `cc-plan` 的事项
 - ready 项必须带成功信号、下一决策、`Depends On`、`Parallel With`
 - ready 项必须带 canonical terms、capability spec context 或明确的 language / decision conflict
+- ready 项必须带 Source funnel rounds、Frozen decisions、Do not re-decide、Remaining blocking question

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,30 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [4.5.9] - 2026-05-11
+
+### Added
+
+- Added project-level AI postmortem contracts under `devflow/postmortems/`, with `cc-act` writing progressive incident, index, and principle records that include Git evidence and verification facts.
+
+### Changed
+
+- Updated `cc-plan`, `cc-investigate`, and `cc-do` to search project postmortems before freezing plans, finalizing root-cause hypotheses, or executing individual tasks.
+- Updated `cc-act` so `post-merge-closeout` must run `cc-devflow archive-change <change-key>` and prove the archive path, instead of leaving archive as an optional next action.
+- Updated `cc-next` so unarchived `devflow/changes/<REQ|FIX>-*` directories are next-work candidates, including done-but-unarchived closeout work.
+
+## [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

@@ -11,16 +11,11 @@
 
 CC-DevFlow is a small, explicit workflow system for agent coding. It gives an AI agent one roadmap entry point, then routes every change through either a feature loop or a bug-investigation loop before work can be called done.
 
-```text
-cc-roadmap
-
-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
-```
+![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 +51,57 @@ 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 Map
+
+```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"]
+```
 
 ## 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, unarchived local changes, 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 +118,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 +155,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 +225,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 +266,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)