القائمة
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.
التثبيت باستخدام 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 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 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-wrapup |
| description | 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. |
把已实现、已测试、已文档化的改动封口：changelog、对账、人工确认、ADR / roadmap 状态更新。commit / push / publish 仍按根 AGENTS 的当次授权规则。
Proposed 的 ADR、实现 / 测试 / 文档 diff、Bug Hunter 结果。PLAN.md、TEST_CONTRACT.md、TASK_STATE.md / REVIEW.md。用户可见改动起草 apps/docs/src/modules/docs/data/changelog.ts 条目，zh / en 同步。changelog 是数据驱动；不要维护旧的 changelog MDX 页面。
写法按 package-publish 中当前 changelog 数据结构；若该 skill 与 types.ts 不一致，以源码类型为准。
internal-only 改动通常不写 changelog；breaking 必写迁移说明。
Alpha 红黄改动建议做第二关对账。调用 subagent / 外部模型前仍按根规则取得授权；一旦执行，必须按 cross-review 对固定快照并发使用 2–3 个 fresh 独立 reviewer，并按异模型优先或同模型双实例降级规则选择阵容，不能串行传递同轮结论。目标不是找代码 bug，而是检查六方一致：
PLAN.md 与执行偏差。输入给 ADR、plan、测试契约矩阵、changelog 草稿、commit / diff、相关 docs、schema / public API / tests diff。只有一个非主模型可用时启动两个该模型的 fresh 独立实例并记录降级；只有一个 reviewer 实例完成时不得宣称交叉评审，按根授权由人工决定是否接受单 reviewer 退化。
结果处理：
| 结果 | 处理 |
|---|---|
| BLOCKING | 修 ADR / changelog / docs / 实现中真正不一致的一方；修完重跑 Auditor |
| WARNING | 本轮修或登记 backlog，由人工裁决 |
| INFO | 可并入 changelog 措辞 |
Contract 偏差通常涉及承诺取舍；1 轮后仍不一致时，halt 给人工，不让 AI 自行调和。
ADR 从 Proposed 起就应是长期功能与架构记录。收尾不执行“施工蓝图压缩”，只做一致性对账：
收到人工确认后再改最终状态文件：
Proposed -> Accepted，补完工摘要；对应 roadmap 勾选或标完成；changelog 写入最终稿。这些文件可按逻辑分块提交。每块提交前展示文件清单和建议 message；没有当前对话授权不提交。
本 skill 不执行 npm publish、tag 或 push。需要发版时另走 package-publish。