Menu
Use when retikz beta-stage roadmap TODO work needs refactoring, renaming, test hardening, error-message, performance, or documentation cleanup after alpha feature work.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Use when changing any retikz apps/docs content, route data, i18n, demo, SourceLinks, or schema reference before loading the matching page-type skill.
Use when retikz needs multiple independent LLMs to review the same fixed code, ADR, implementation plan, test contract, commit, or working-tree snapshot before a gate or delivery decision.
Use when an Alpha ADR needs a pre-implementation capability gate, or a Beta milestone needs code-based completeness and package-boundary auditing.
Use when planning a retikz architecture direction, version roadmap, or alpha feature that may need a long-lived ADR before implementation.
Use when retikz work is primarily refactoring, reorganization, renaming cleanup, modularization, or internal simplification and should start from a reviewed implementation plan before code changes.
Use when retikz implementation, adversarial testing, and docs are complete, and an ADR or beta TODO needs changelog, contract consistency review, roadmap status updates, or final human acknowledgement.
| name | flow-beta |
| description | Use when retikz beta-stage roadmap TODO work needs refactoring, renaming, test hardening, error-message, performance, or documentation cleanup after alpha feature work. |
flow-beta 是 beta 期 plan TODO 编排器。beta 只做修改类工作：重构、命名、注释、测试加固、错误信息、性能、文档整理。它允许破坏性改名，但不接新功能。
启动前确认：
发现需要新功能时立即 halt，登记到下个 alpha 窗口，改走 flow-alpha。
长重构或 scope 不清时，先走 develop-refactor 写 plan；启动时询问用户 plan 写完是否评审、代码写完是否评审。
| # | 阶段 | 执行 | 通过条件 |
|---|---|---|---|
| 0 | 全局入口审计 | develop-completeness code-audit | 三能力域报告完成；候选 TODO scope 经人工确认 |
| 1 | 实现 | develop-implement 简化路径 | 受影响模块 lint / tsc / 测试全过 |
| 2 | TODO 评估 | 本 skill 按用户选择调度 | BLOCKING 清空，WARNING 经人工裁决 |
| 3 | TODO 收尾 | develop-wrapup 简化路径 | roadmap TODO 标完成；breaking / visible 按需 changelog；人工授权 commit |
| 4 | 全局出口复审 | develop-completeness code-audit | 最新三能力域审计均 PASS；或熔断后等待人工裁决 |
beta 不开新功能 ADR，不走 alpha 的设计 / adversarial 自测 / 必选文档阶段。用户可见改动仍按 docs skills 补文档。Stage 0 / 4 是 milestone 级门禁，不替代每条 TODO 的 Stage 2。
任何 beta TODO 实施、建批量 worktree 或修改 roadmap 状态前，自动并行派遣三个新的只读 subagent：
| 能力域 | develop-completeness 参数 | 范围 |
|---|---|---|
| Drawing | code-audit + beta-entry + Drawing | math / core / render / react / vanilla / tex |
| Data | code-audit + beta-entry + Data | data 及其消费边界 |
| Visualization | code-audit + beta-entry + Visualization | plot / plot-react / plot-vanilla 及上下游接口 |
三个审计使用同一 HEAD 基线，各自写 ignored report，不修改产品文件、roadmap 或暂存区。派遣时显式记录每个 subagent 的实际模型，优先避开主 agent 的模型，并在调度能力支持时使用 reasoning_effort: max；有三个不同模型时分别分配，没有时允许跨能力域复用，但不得伪造不存在的模型。三个能力域互相独立，同轮并发执行，不把任一域结论先喂给其它域。主 AI 汇总：
BLOCKING / WARNING / INFO / ESCALATE_ALPHA。候选 TODO scope 必须经人工确认后才能进入 Stage 1。ESCALATE_ALPHA 不得伪装成 beta cleanup；交人工决定退回 Alpha 或延期。三个报告完成且无冲突时当前轮立即结束；只有需修订或报告冲突时才进入下一轮。总计最多 9 轮，每轮都使用新的 subagent、同一轮固定 HEAD，并重新记录实际模型；第 9 轮仍不收敛则 halt 交人工。
| Level | 范围 | 收尾要求 |
|---|---|---|
| internal | 内部搬迁、私有重命名、注释、类型层重构，不改 public surface | commit message 说明即可 |
| visible | 错误信息、默认行为、性能或 docs 变化，用户可观察但不改 public export | 视影响写 changelog / docs |
| breaking | 修改、重命名或移除既有 public API、schema 字段、组件、公开 type / 函数签名 | 必写 BREAKING changelog + 迁移路径 |
beta 允许调整既有契约的 breaking，不允许用 breaking 包装净新增能力、组件、IR、schema 字段或用户可见行为契约；后者转 Alpha。
test-contract 补行为、不变量、反例与最低测试层。beta 的核心风险是重构回归和 breaking 漏迁移。Stage 2 始终评估，但是否派 TODO review subagent / 外部模型先按风险判定：breaking、用户可见行为、跨包契约、核心能力、大范围或高风险改动必须先取得用户确认再评审；非 ADR、scope 明确且仅涉及文档、文案、链接、格式或机械性调整，并且不改变公开契约、schema、runtime 行为或跨包边界时，可由主 AI 自审并记录跳过理由；其余情况先询问用户。必须评审的改动若用户拒绝或工具不可用，则由主 AI 自审并说明退化路径，且结论须经人工明确接受后才能通过 Stage 2。至少准备以下评估材料：
test-contract 矩阵与每行证据。packages/*/*/src/index.ts。评估角色：
| 角色 | 何时必跑 | 关注点 |
|---|---|---|
| 等价性审计 | 所有 level | 未声明回归、public surface 漏迁移、schema / 默认值变化、测试弱化 |
| 收益审计 | breaking / visible 必跑，internal 可选 | 是否真的解决 TODO、是否过度工程、是否更贴合项目惯例 |
用户也可手动跑评估并把结论贴回。主 AI 合并为 BLOCKING / WARNING / INFO：
用户同意评审后，Stage 2 复用 cross-review：固定 TODO、完整 diff / commit range、public surface diff 与测试证据，同轮并发派遣 2–3 个 fresh 独立 reviewer，互不传递结论；优先不同模型，只有一个非主模型时使用两个同模型 fresh 实例并标注降级。主 AI 只在全部结果返回后归并；只有一个 fresh 独立 reviewer 完成时 halt 交人工决定是否接受单 reviewer 退化。
Stage 2 最多 9 轮，不因 finding 改名、拆分或出现新 ID 重新计数；最新一轮无 BLOCKING、WARNING 已处置时立即 PASS。只有修订发生后才使用 fresh agents 评审新的固定快照；第 9 轮仍有任一 BLOCKING 时 halt，交给人工决定继续、缩 scope 或放弃。
所有获批 TODO 完成并集成到同一 beta milestone 分支后，自动执行：
code-audit + beta-exit 审计 Drawing、Data、Visualization；三者必须使用该轮同一 HEAD，不能复用 Stage 0 或上一轮主体。显式记录实际模型，优先避开主 agent 的模型，并在调度能力支持时使用 reasoning_effort: max；有三个不同模型时分别分配，可用模型不足时允许跨能力域复用但必须如实记录。审计期间 HEAD 变化则本轮作废并计入轮次。ESCALATE_ALPHA 时立即 halt，交人工决定退回 Alpha 或延期。PASS，且 WARNING 已记录处置或风险归属，Stage 4 才通过。任何修复都必须由下一轮新的三域审计验证，不能由主 AI 自审放行。自动授权只覆盖 Stage 0 / 4 的只读审计 subagent。主 AI 的 beta 范围修复仍不得自动 commit、push、改变发布授权或实施 ESCALATE_ALPHA 项。
批量逻辑复用 flow-alpha 的 worktree 规则，把 “ADR” 替换为 “plan TODO”。Stage 0 在建立 worktree 前对共同 base 执行；Stage 4 只在人工 review 并集成所有 worktree 后对 milestone 分支执行。单个 worktree 只跑 Stage 1-3，并仍需：
REVIEW.md 并 halt。REVIEW.md。flow-long-task 判定风险；需要评审时再用 cross-review 固定 staged diff，并发使用 2–3 个 fresh 独立 reviewer，并按异模型优先或同模型双实例降级规则选择阵容。低风险明确改动可跳过，改动面大、核心功能或高风险 commit 不得豁免。