القائمة
Use when planning a retikz architecture direction, version roadmap, or alpha feature that may need a long-lived ADR before implementation.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف 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 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.
Use when retikz alpha-stage work needs to execute an ADR-backed feature through long-lived design, reviewed implementation planning, code, adversarial testing, documentation, and wrapup.
| name | develop-design |
| description | Use when planning a retikz architecture direction, version roadmap, or alpha feature that may need a long-lived ADR before implementation. |
先判断当前产物是 architecture design、版本 roadmap 还是 ADR。ADR 从 Proposed 起就是长期功能与架构文档；实现细节始终写入 ignored plan，不经过“施工蓝图再压缩”的阶段。
| 产物 | 负责 | 不负责 |
|---|---|---|
| Architecture design | 长期问题、整体结构、能力归属、功能边界、关键原则与演进方向 | 版本字段、具体实现和执行步骤 |
| 版本 roadmap | 版本目标、milestone、候选 ADR、依赖顺序与退出条件 | API、算法、文件和测试 case |
| ADR | 单项功能、核心决策、基础数据结构 / 公开契约、行为边界与架构验证 | 文件清单、私有命名、业务逻辑步骤、测试 case 和执行过程 |
| Implementation plan | 文件 scope、代码与业务逻辑、任务顺序、测试、命令、commit、风险和回滚 | 改写 ADR 的公开契约、能力归属或功能边界 |
当前任务只要求 architecture design 或 roadmap 时，完成对应文档并交人工 review 后停止，不提前进入 ADR 或 plan。
AGENTS.md 的设计原则、IR / Schema / 分层规则。notes/architecture/capability-design.md 和所属能力域 completeness 文档。standard-structure 分流读取适用 standard-* skill。_notes/decisions/_template.md 与当前 milestone roadmap.md。packages/kernel/_notes/decisions/v<MAJOR>/v<MAJOR>.<MINOR>/<channel.N>/<NN>-<slug>.md
packages/viz/_notes/decisions/<FAMILY>/v<MAJOR>/v<MAJOR>.<MINOR>/<channel.N>/<NN>-<slug>.md
其它分组沿用同形态。模板来自所属分组的 _notes/decisions/_template.md；编号在 milestone 目录内从 01 起。
ADR 至少包含：
ADR 不得写：
Schema 或数据结构只有在它是基础公开契约、跨包接口或非法状态边界时进入 ADR；文件位置、Zod 拼装方式、private intermediate 和逐字段操作进入 plan。
新增或修改 authoring API 时，ADR 必须说明 React 与 Vanilla 是否表达同一契约；某套不适用时写明理由。
ADR 草案完成后、人工 ack 前，使用 develop-completeness 的 adr-gate rubric，并按 cross-review 执行并发多模型评审：
cross-review 并发派发 2–3 个 fresh 独立 reviewer；优先不同模型，只有一个非主模型时使用两个同模型 fresh 实例，同轮互不可见结论。BLOCKING / WARNING / INFO，检查问题归属、基础契约、包边界、define-registry、端到端闭环与非目标。该 Gate 是 flow-alpha 的常驻只读授权；不授权实现、commit、push、扩大功能 scope 或其它外部写操作。
人工确认 ADR 并授权进入实现后，执行者必须重新阅读全文 ADR，再把 ADR 路径中的 decisions 替换为 plans，并把 <NN>-<slug>.md 变为同名目录：
packages/viz/_notes/decisions/chart/v0/v0.1/alpha.1/01-example.md
-> packages/viz/_notes/plans/chart/v0/v0.1/alpha.1/01-example/
PLAN.md
TEST_CONTRACT.md
TASK_STATE.md # 长任务需要
REVIEW.md # 记录 Plan Gate 轮次摘要
**/_notes/plans/ 由 .gitignore 覆盖。plan、测试矩阵、状态和 review 记录默认不 stage、不 commit。
PLAN.md 至少包含：ADR 与目标、非目标、文件 scope、基础契约到代码的映射、业务逻辑与任务顺序、docs / changelog、验证命令、commit 边界、风险与回滚。详细测试矩阵由 test-contract 写入同目录 TEST_CONTRACT.md。
Plan 可以细化实现，不能改变 ADR 的公开契约、所有权和功能边界；发现冲突时停止 plan，回到 ADR 修订和 Architecture Gate。
Plan 写完后必须按 cross-review 完成 1–9 轮并发多模型 Plan Gate；通过前不得修改产品代码。具体编排由 flow-alpha 负责。
Proposed，不含施工细节或临时压缩段。