Dev Workflow

开发工作流路由与执行指南

插件路径约定

本文用 ` 表示插件仓库根目录，不是 skills/dev-workflow` 目录。

本仓库结构固定为：

/
  skills/dev-workflow/SKILL.md
  scripts/workflow-state.sh
  scripts/learnings.sh
  scripts/codegraph-judge.sh

如果当前 skill 文件路径是：

.../tiers/skills/dev-workflow/SKILL.md

那么 `` 是：

.../tiers

正确脚本路径示例：

/scripts/workflow-state.sh check

错误示例（不要这样拼）：

/skills/dev-workflow/scripts/workflow-state.sh check

执行脚本前按以下顺序解析：

1. DEV_WORKFLOW_PLUGIN_ROOT
2. CODEX_PLUGIN_ROOT
3. CLAUDE_PLUGIN_ROOT
4. CURSOR_PLUGIN_ROOT
5. 若是从本文件路径推断，则从 skills/dev-workflow/SKILL.md 上溯两级到仓库根目录

脚本自身也按同样规则自动推断，Codex 环境不要依赖 Claude 专属变量。

使用时机

每次接到新的开发任务时，先跑决策树确定级别，再按对应步骤执行。

能力模式与依赖兜底

本插件的核心路径必须在只安装本插件时可用；外部 skill、MCP、CLI 都是增强能力，不是硬依赖。

开工或排障时可运行：

/bin/doctor [--repo ] [--install-deps]

• base：只依赖本插件内置流程和必需命令。可以完成判级、spec/plan/TDD/debug/review/verify 的内置协议。
• enhanced：检测到 superpowers、codegraph 等伴侣能力时，优先调用对应 skill/CLI 增强体验。
• full：额外检测到设计保真、已建图 codegraph 等环境时，开启更完整的客观校验。

执行规则：

• 若本文点名的外部 skill 可用，优先按该 skill 执行。
• 若不可用，不要卡住或要求用户先安装；改走本文写明的内置协议。
• 不静默安装依赖。只有用户显式要求或传 --install-deps 时，才安装可脚本化依赖；MCP/登录类能力只提示下一步。
• 若用户问“为什么某功能不可用”，先跑 bin/doctor 给出能力矩阵，再决定是否安装或降级。

对抗评审关卡（provider 分层）

对抗评审是独立关卡，不绑定某个外部 CLI。目标是让至少一个“反方视角”专门找风险，主流程负责裁决。

触发规则：

• L0/L1：默认执行。
• L2：影响面大、安装/配置/数据迁移/权限相关时执行；涉及 auth / route guard / API integration / order / IM / prescription / payment / 数据写入 / 权限守卫等业务闭环时强制执行，不得用“很小的单点改动”降级；非业务闭环的很小单点改动可用内置 checklist。
• L3：复杂根因、偶现 bug、修复路径有替代解释时执行。
• L4：默认跳过。

provider 优先级：

1. 外部交叉评审（external-cross-review）：若 external-agent 可用且 bin/doctor 显示 Adversarial review: external-ready，或 external_agent.py --list 显示 ≥2 个不同家族外部 CLI 可用，优先用 ≥2 个不同家族外部 CLI 做只读 review。高风险业务闭环任务必须先尝试此项；external-partial、认证失败、空产出或只剩同家族 provider 时只算二次意见，不算完整交叉评审。
2. 平台子代理（platform-agents）：仅当外部交叉评审不可用、用户明确要求平台子代理、或作为外部 review 之外的补充时使用。不同 reviewer 用不同审查角色，例如“回归风险 reviewer”和“安装/降级路径 reviewer”。平台子代理不能替代已触发的外部交叉评审。
3. 平台多模型（multi-model）：若平台允许指定模型，且用户明确允许多模型，给 reviewer 分配不同模型；不允许或不可用时，同模型不同 prompt 也可用。
4. 内置对抗 checklist（built-in）：没有任何 provider 时也必须可执行。检查：最可能的回归点、缺依赖/缺 MCP 降级路径、安装脚本是否静默改环境、README/skill/脚本承诺是否一致、测试是否覆盖失败路径。

纪律：

• 不为对抗评审静默安装 provider；需要安装时只提示 bin/doctor --install-deps 或登录步骤。
• 只读 review 默认不允许写文件。外部或子代理输出是证据，不是结论，主流程必须逐条裁决。
• 若用户未授权平台子代理/外部 agent，则走内置 checklist，不阻塞交付；但高风险业务闭环任务必须在 final 里标明“外部交叉评审未完成”，不能写成已过完整对抗评审。
• 收尾时必须展示采用的 provider、review 摘要、主流程裁决；若本应外部交叉评审但未完成，必须明确写出阻塞原因，禁止静默降级后声明“已完成”。

---

开工前：进化检查 + 强制显式判级 + 续行检查

接到任何开发需求，动手前必须先做这三件事，不许闷头直接开干：

1. 进化扫描（见下方「自主进化」）。读数据区（learnings.sh 自动定位），把 status: pending 的条目按 category 计数；若某 category ≥ 2，先输出固化提案等用户确认，否则保持沉默。
2. 读续行状态（见下方「跨 session 续行」）。若检测到未完成任务，先提示用户「继续 / 换新任务」，不要无视。
3. 显式输出一行判级结论，格式固定：

`` 级别 = Lx｜理由 = ``

这一行让判断可见、可被用户当场纠正。没有这一行就开始改代码 = 流程违规。

判级 tie-breaker（拿不准时）： 在两级之间犹豫，一律走更严的那级。

• L1/L2 之间拿不准 → 按 L1（走 SDD）
• L2/L3 之间拿不准 → 按有回归风险处理，补测试
• L3/L4 之间拿不准 → 按 L3（先复现再改）

宁可多一道流程，不漏一次回归。

---

决策树

Q0: 涉及多个已有模块的结构性重组或架构迁移？
  → 是 → L0
  → 否 → Q1

Q1: 新增了别人没有预期过的行为或结构？
  → 是 → L1
  → 否 → Q2

Q2: 如果改错了，有可能回归现有功能？
  → 是 → L2 或 L3（有测试要求）
  → 否 → L4

L2 vs L3 的区分：新功能逻辑改动 → L2，线上 bug 修复 → L3。

---

理解度关卡（各级通用）

动手改代码 / 写测试前，先过一道与本级匹配的理解度自检。共同退出标准：能否在基本不返工的前提下进入下一步。拿不准默认走更严的处理（同 tie-breaker）；过不了关卡不是只有"往深挖"一条路——也可能是判级错了，回去重判。

| 级别 | 动手前要"懂"的对象 | 没懂时 | |---|---|---| | L1 | 需求 / 设计（决策树分支、边界） | 进 grill-me；想跳过需用户点头（详见 L1 HARD-GATE） | | L2 | 改动的影响面 / 回归边界 / 能否写出覆盖测试 | 跑 codegraph-judge assess 看 affected flow / test gap，或直接读消费方；影响面超预期（跨模块/结构性）→ 回去重判级（可能 L1/L0） | | L3 | bug 的真正根因（不是症状冒出点） | 留在 systematic-debugging，别急着改；"修复"其实是在加新行为 → 重判级（可能 L2） | | L4 | （风险≈0，免） | — |

---

设计保真验收关卡（各级通用，收尾 HARD-GATE）

理解度关卡守"动手前懂没懂"，这道关守"做完后是否按设计源完成"。凡产出可见 UI 且有设计稿（Figma 等）的任务，不论判到 L1/L2/L3/L4，收尾标 done 前必过此关。 纯逻辑改动、无设计稿的 UI 文案微调豁免。

> ⛔ HARD-GATE（保真收尾强制，优先级高于"渲染无报错就算完"的直觉） > 凭「页面可渲染 / 关键标题在场 / 视觉上大致接近」不算对齐设计稿，禁止据此声明 done。必须做完下面两步，缺一不算过： > > 1. 整屏完整性核对 — 逐区块对设计稿核对「有无漏做整块区域 / 组件范式是否一致」。防止只看到局部元素就误判整屏已完成。 > 2. 逐元素量化比对 — 关键元素的设计稿量化值（尺寸 / 圆角（含单角圆角）/ 色值 / 字号字重 / 间距 / 描边）用 DOM inspect / 实测逐项对设计真值，禁凭"看着像 / 渲染无报错"放行。 > > 取数与执行纪律： > - 设计真值由取数中枢 REST 直取（Figma REST 等：图片导出 + 节点树量化值），不要依赖视觉印象或二手描述猜测。 > - 实现可委派，但验收必须由主流程本端完成（preview 逐区 inspect），不能只依赖实现方自报"已对齐"。 > - 配套方法见 skill figma-fidelity-verification（含 REST 取真值 → 写 death-spec → 派 agent 实现 → 逐区量化验收的完整 loop，本文不重复其内容）。 > > 未过此关不得标 done。 自检红旗：当你准备说"对齐设计稿了 / 这个页面做完了"，但本任务还没做整屏核对 + 逐元素 inspect——立即停下，回到关卡。

> 状态机（L1/L2 维护 workflow-state 时）：收尾前补一个 fidelity-verify 阶段标记，两步都过再 set phase done。见下方「跨 session 续行」。

业务闭环验收关卡（L1/L2/L3 通用，收尾 HARD-GATE）

凡涉及 auth / route guard / API integration / order / IM / prescription / payment / 数据写入 / 权限守卫等真实业务链路，收尾标 done 前必须证明业务闭环真实成立。页面能打开、组件能渲染、mock 数据可见、类型检查通过，都不能替代业务闭环验收。

> ⛔ HARD-GATE（业务闭环完成强制） > 必须给出本端执行过的证据，缺一项就不能说完成： > > 1. 入口与守卫 — 未登录、已登录、深链/刷新、无权限或过期态按需求表现；不能出现未登录可进受保护首页这类绕守卫路径。 > 2. 真实请求 — 关键动作必须触发预期真实接口；记录方法、URL/路由、状态码、关键 request/response 字段。若环境只能 mock，必须明说“未过真实请求验收”，不能标 done。 > 3. 端到端结果 — UI 状态、服务端/持久化状态、错误态/401/403/失败路径至少覆盖任务核心分支。 > 4. 证据清单 — final 输出必须列出测试命令、浏览器/接口演练、codegraph 结果、对抗评审 provider 与裁决、仍未覆盖的风险。 > > 高风险业务闭环任务（auth、路由守卫、API 写入、订单、IM、处方、支付、权限）在完成前还必须跑 codegraph-judge assess；若 codegraph 不可用，只能记录“codegraph 降级为人工影响面审查”的证据，不能省略影响面审查。人工影响面审查至少要列：改动文件清单、每个文件影响、受影响业务 flow、测试缺口、为什么仍满足 L1/L2/L3 判级。 > > 状态机（L0/L1 维护 workflow-state 时）：涉及业务闭环的任务收尾前必须 set phase business-verify，证据清单齐全后才允许 set phase done；若同时有设计稿，再按顺序进入 fidelity-verify。

---

codegraph 辅助判级与收尾证据（三层降级）

L2 及以上、或判级拿不准时，跑 codegraph 守卫获取客观信号；高风险业务闭环任务在收尾前必须把 codegraph 结果或降级原因写进证据清单：

/scripts/codegraph-judge.sh [--repo ] [--base ] assess

• 退出码 0：已输出风险摘要，按下表校准级别。
• 退出码 3：codegraph 不可用 → 降级为纯人工判级，继续流程。

判级校准阈值（提示非硬覆盖，冲突偏严，与 tie-breaker 一致）：

| 图信号 | 判级含义 | |---|---| | risk ≥ 0.4 / 改动文件 ≥ 8 / 有 affected flow | 至少 L1，判更低要重审 | | 有 test gap 且改了已有函数 | 锁 L2/L3，必须补测试，禁 L4 | | risk≈0 且 0 changed functions | L4 可放心 |

TDD 靶向：detect-changes 点名的 untested 函数 = TDD 首批测试目标。

打通自主进化：若图风险与你判级明显背离（判 L4 但 risk=0.55），按一次「判级被数据纠正」记入：

/scripts/learnings.sh add 判级/图风险背离  ""

L4 微调不跑（风险≈0，白跑）。

---

L0 — 大型改造（gstack 完整 sprint）

触发条件： 跨多模块重构、架构迁移、大范围技术债清理。

执行步骤：

1. 用强制提问重新审视问题范围，避免过度工程（若有 /office-hours 工具则用）
2. 战略范围分析，确认值不值得做、做多少（若有 /plan-ceo-review 则用）
3. 架构方案验证，识别风险点和测试需求（若有 /plan-eng-review 则用）
4. 用户已授权某个外部 Agent 时，可用 external-agent 调 agy / cursor-agent / grok 做一次独立架构挑战；输出只作证据，主 Agent 负责核验与决策
5. 实现阶段：按 plan 拆分，每个子任务可独立用 worktree + 并行 Agent
6. 真实浏览器测试，自动生成 fix commit（若有 /qa 工具则用）
7. CI 自动化 + PR 创建（若有 /ship 工具则用）

注意： L0 改造必须拆分为可独立合并的子任务，不要做一个超大 PR。

---

L1 — 大功能（SDD → TDD）

触发条件： 新增模块、新增完整用户流程、跨多文件的全新设计。

> ⛔ HARD-GATE（L1 强制时序，优先级高于被插入 skill 自身的终态指令） > brainstorming skill 的终态指令是「下一步 invoking writing-plans，不要调用其他 skill」——这条对 L1 不成立，必须无视。L1 在 brainstorming 之后、写/定稿 spec 之前，必须先通过「理解度关卡」，禁止从 brainstorm 直接跳到 spec/plan。 > 关卡判定：摆出决策树各分支已落到的结论、识别到的边界情况、仍未问清的开口，自评对需求的理解度（能否写出基本不返工的 spec）。 > - 理解不足，或拿不准 → 进 grill-me 追问，收敛到理解足够才退出。未通过关卡禁止写 spec / 调 writing-plans / 建 specs 目录。 > - 自评已足够（决策树全分支有结论、边界已探、无开口）→ 仍须显式向用户提议「理解已足够，建议跳过深度 grill 直接写 spec」并取得用户点头，方可跳过 grill。未经检验的信心不算通过；自己拍板跳过 = 流程违规。 > 自检红旗：当你发现自己"准备写 spec / 准备调 writing-plans / 准备建 specs 目录"，但本任务还没过理解度关卡——立即停下，回到关卡。

执行步骤：

1. brainstorming skill（若可用）— 澄清需求，提出 2-3 方案，用户确认，起草设计文档到 docs/superpowers/specs/。若不可用，执行内置 brainstorm 协议：读项目上下文 → 提出 2-3 个方案和推荐项 → 向用户确认范围 → 写一份简短 spec 到同目录。
2. 理解度关卡（必经） — 按上方 HARD-GATE 判定：理解不足/拿不准 → 进第 3 步 grill；自评足够 → 向用户提议跳过、取得点头后直接进第 4 步。
3. grill-me skill（理解度不足时触发，本插件内置） — 对着设计文档追问，逐个解决决策树分支、暴露边界情况，把答案回填进文档，理解收敛达标才退出。

> 内置 grill-me 是零依赖基线。若用户自行装了更强的追问 skill（如 mattpocock/skills 的 grill-with-docs，锚定 CONTEXT.md/ADR、边问边更新文档），则优先用它。

1. writing-plans skill（若可用）— 基于已收敛的设计文档写 plan 到 docs/superpowers/plans/。若不可用，执行内置 plan 协议：列文件影响面、逐任务写 Red/Green/Refactor 步骤、每步给命令和验收点。
2. test-driven-development skill（若可用）— 先写失败测试，再实现，测试通过后提交。若不可用，执行内置 TDD 协议：先写最小失败测试并确认失败原因正确，再写实现，最后跑目标测试和全量测试。
3. requesting-code-review skill（若可用）— 请求代码审查；随后按「对抗评审关卡」选择 provider。若 review skill 不可用，执行内置 review checklist：检查行为回归、缺失测试、安装/降级路径、文档承诺是否与实现一致。
4. 若涉及业务闭环，按「业务闭环验收关卡」完成真实请求与守卫演练；缺证据不得标 done。
5. verification-before-completion skill（若可用）— 验证功能符合 spec 后关闭任务。若不可用，执行内置 verification checklist：重跑相关测试、演练缺依赖场景、确认 README/skill/脚本口径一致。

> L0 的范围审视/架构验证阶段同样可以用 grill-me 追问设计；L2 只有轻量 spec，一般不必；L3/L4 无设计文档，跳过。

---

L2 — 中型迭代（轻量 spec → TDD）

触发条件： 修改已有逻辑，影响 ≥3 个文件，但不是全新模块。

执行步骤：

1. 写一段简短的需求说明（不需要完整 brainstorming，3-5 句话描述目标和边界）
2. 理解度关卡（轻量，见上） — 一句话自检：谁在消费这块 / 回归边界在哪 / 能写出覆盖测试吗？拿不准 → codegraph-judge assess 或读消费方；影响面超预期 → 回去重判级。
3. test-driven-development skill（若可用）— 先写覆盖改动点的失败测试；若不可用，走内置 TDD 协议：先红、再绿、再清理。
4. 实现，让测试通过
5. （可选）requesting-code-review skill；命中对抗评审触发规则时按 provider 分层执行；不可用时用内置 review checklist
6. 若涉及业务闭环，按「业务闭环验收关卡」完成真实请求与守卫演练；缺证据不得标 done

---

L3 — Bug 修复（调试优先）

触发条件： 线上问题、行为回归、测试失败的已知 bug。

执行步骤：

1. systematic-debugging skill（若可用）— 系统性定位根因，不要凭感觉猜；若不可用，走内置 debugging 协议：复现 → 缩小范围 → 提出根因假设 → 用日志/测试验证假设 → 再修复。
2. 根因关卡（轻量，见上） — 写修复前自检：我定位到真正根因了，还是在改症状冒出点？答不上 → 留在 systematic-debugging 别动手；若"修复"其实是加新行为 → 回去重判级（可能 L2）。
3. 写一个能复现 bug 的失败测试（先红）
4. 修复，让测试变绿
5. 若修复涉及业务闭环，按「业务闭环验收关卡」补跑守卫、真实请求、错误态演练；缺证据不得标 done
6. 确认没有引入新回归后提交

---

L4 — 文案/样式微调（直接写）

触发条件： 纯 UI 文字、颜色、间距调整，不涉及任何逻辑变化。

执行步骤：

1. 直接修改，无需 spec 或测试
2. 视觉确认改动符合预期后提交

---

可委派的协作 CLI（各级可选杠杆）

把子任务委派给外部编码 agent CLI（搜集信息 / 实现 / 交叉审核），统一走 external-agent skill —— 一个 runner、一套路由策略。详见该 skill 的 SKILL.md，这里只给路由速记：

python3 /scripts/external_agent.py --agent  --cd "$PWD" \
  --PROMPT "bounded task" [--mode review|delegate] [--format text|json] [--SESSION_ID id] [--context git]

| agent | 家族 | 默认角色 | |---|---|---| | codex | OpenAI | 执行（算法 / 补丁 diff） | | cursor | 多模型 | 执行 / 审查（仓库感知） | | grok | xAI | 搜集 / 交叉审查（联网） | | antigravity(agy) | Google | 搜集 / 审查（gemini 个人版已停用的继任者） | | mimo | 小米 | 国内兜底 |

• 搜集 → --mode review（只读）：联网→grok，啃大库→antigravity。
• 执行 → --mode delegate（可写，需用户授权）：仓库内→cursor/codex，纯算法→codex，国内→mimo。
• 交叉审核 → --mode review，同一产物丢给 ≥2 个不同家族 的 agent（如 codex+grok+antigravity），主 Agent 汇总裁决。
• 派之前 --list 查可用性；--SESSION_ID 多轮续接。

纪律：委派不降级流程——判级、理解度关卡、TDD、人工评审仍由本工作流主导；agent 产出是证据、不是免检的最终答案，必须过本级关卡校验。--mode delegate（可写）须用户授权、且只在 --cd 内。--model 非用户明确指定不要传。

---

常见判断边界

| 情况 | 正确级别 | |---|---| | 新增一个已有模式的 API 接口 | L2（改已有逻辑，有回归风险） | | 新增全新的问卷流程 | L1（新行为，需要 SDD） | | 把多个 store 合并重构 | L0（结构性重组） | | 修复某个按钮点击没反应 | L3（bug） | | 改按钮颜色 / 文案 / 间距 | L4 | | 改按钮点击后的跳转逻辑 | L3 或 L2（看是否有回归风险，拿不准按 L2） | | 给已有接口加一个可选参数 | L2（有回归风险） | | 改已有接口的返回结构 / 字段含义 | L2（下游可能回归，必须补测试） | | 调整某个 store 的字段或 action | L2（多处消费，有回归风险） | | 新增一个独立的工具函数（无人依赖） | L4（无回归面）；一旦被多处引用就升 L2 | | 改数据库迁移 / schema | L2 起步，跨表结构性调整升 L0 | | 复制现有页面改文案做一个新页面 | L4（纯文案）；若新增逻辑分支则 L2 | | 修一个偶现的线上 bug | L3（必须先复现再改） | | 升级依赖 / 改构建配置 | L2（可能回归），波及面大升 L0 | | auth / route guard / API integration / order / IM / prescription / payment / 权限守卫闭环 | L2 起步；新增完整流程或跨模块业务编排升 L1；完成前必须过业务闭环验收、codegraph 证据、外部交叉评审 |

---

跨 session 续行（脚本独占接口）

让一个 L0/L1 任务跨多个对话不丢进度。脚本独占接口（学 Comet comet-state.sh）。禁手改 YAML。

状态文件： 每个项目按需生成 docs/superpowers/.workflow-state.yaml（加进 .gitignore，属工作态、不进版本库）。仅 L0/L1 需要维护；L2–L4 太短，可跳过。

格式（字段结构刻意设计成将来脚本可直接接管）：

task: 一句话描述当前需求
level: L1
phase: spec          # brainstorm | grill | spec | plan | tdd | review | business-verify | fidelity-verify | done
artifacts:
  spec: docs/superpowers/specs/YYYY-MM-DD-xxx-design.md
  plan: ""
updated: YYYY-MM-DD
next: 下一步具体该做什么

维护约定：

1. 开工时：跑 /scripts/workflow-state.sh check。如果输出「无续行状态」，直接继续判级；如果已有状态，再 get phase / get task / get next。若 phase != done 且非空，提示续行：「检测到未完成的 {level} 任务【{task}】，停在 {phase}，下一步 {next}。继续，还是换新任务？」
2. 定级后：跑 workflow-state.sh init（首次创建），再 set task/level/phase。

> L1 阶段流转：brainstorm →（理解度关卡）→ 理解不足则 set phase grill、收敛后再 set phase spec；自评足够且用户点头可直接 set phase spec。禁止 brainstorm 不经关卡判定直接跳 spec。

1. 每过一个阶段：set phase/next，有 spec/plan 则 set artifacts.spec/artifacts.plan。
2. 收尾（仅 L0/L1）：若本任务涉及业务闭环，先 set phase business-verify，过「业务闭环验收关卡」后才可继续；若本任务产出可见 UI 且有设计稿，再 set phase fidelity-verify，过「设计保真验收关卡」两步后再 set phase done；无对应 gate 才能直接 set phase done。脚本自动更新 updated。

---

自主进化（全局，跨项目）

让这套工作流参考真实使用方式自我演进。事实源是数据区（learnings.sh 自动定位），全局共享，计数与记录由脚本确定性完成，不靠对话记忆。模式：自主发现、人工放行。

配套工具（均在 /scripts/）：

• learnings.sh —— 记录/计数 helper：count / ready / categories / add / list。add 会校验 category 取自词表、原子追加，并回报当前计数是否达阈值。
• detect-judging-correction.py —— Claude/Codex 上挂在 UserPromptSubmit（由 plugin.json 声明，启用插件即生效）：用户提交消息时回看上一轮，若疑似纠正判级则注入提醒。仅 Claude/Codex 有此提醒：Cursor 的 beforeSubmitPrompt 不能向模型注入上下文，故 Cursor 上不安装此 hook —— 此时由我主动履行下面的记录职责，不等提醒。

记录（被动积累）

每当用户纠正我一次判级，或某 tie-breaker 事后被证伪/证实，立即用脚本记录。这是我的固定职责，不依赖 hook 提醒——Claude/Codex 上 hook 会顺手提醒一句，Cursor 上没有提醒，但只要本 skill 在跑，判级被纠正时我就必须记：

/scripts/learnings.sh add   ""

• category 必须取自词表（脚本会拒绝非法值）；同类纠正务必贴同一标签，否则计数失效。确属新类时先在数据区（learnings.sh 自动定位）词表补一行再 add。
• note 写清「我原判 Lx → 用户纠正为 Ly，因为…」。

hook 只是"提醒"不是"代劳"——它从不自动写记录，记不记永远由我执行 add。这是本机制保留的人工环节，也保证了去掉 hook（如 Cursor）功能依旧完整。

检查与提案（开工时触发）

每次本 skill 被调用，作为「开工前」第 1 步：跑 /scripts/learnings.sh ready（等价于按 category 数 pending）-> 任一 category ≥ 2 即输出提案，否则沉默：

> 📈 工作流进化提案：`` 类已被你纠正 N 次（项目 A、项目 B）。建议把「」固化进边界表 / tie-breaker。确认固化吗？

固化（人工放行后）

• 用户确认 → 编辑本 SKILL.md（把规则写进边界表或 tie-breaker），并把相关条目 status 改为 folded。
• 用户否决 → 相关条目 status 改为 dropped，不再计入。

固化是改全局核心 skill 的动作，必须用户点头，绝不自动重写。

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: whrjunluo
• Source: whrjunluo/tiers
• License: MIT

Install and usage instructions live in the source repository linked above.