メニュー
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.
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 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-refactor |
| description | 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. |
面向不新增公开能力的重构：搬迁、拆分、合并、重命名、依赖收敛、内部抽象调整、测试或类型结构整理。若需要新增 DSL / API / IR / schema / renderer 可见行为，停止并转 flow-alpha / develop-design；若来自 beta roadmap TODO，按 flow-beta 对齐 scope。
长任务执行前先按根规则判定风险。非 ADR、scope 明确且仅涉及文档、文案、链接、格式或机械性调整，并且不改变公开契约、schema、runtime 行为或跨包边界时，可跳过 subagent review 并记录理由。需要或适合评审时再问用户：
用户未确认前不派 subagent / 外部模型。用户同意 review 后按 cross-review 使用同一固定快照、2–3 个 fresh 独立 reviewer 并发评审；优先不同模型，只有一个非主模型时使用两个同模型 fresh 实例并标注降级。用户拒绝时由主 AI 自审并说明退化路径。只有一个 fresh 独立 reviewer 完成时不称为交叉评审；仅可选 plan / 完工 review 可由人工决定是否接受单 reviewer 退化，flow-long-task 的批量自动 commit gate 不允许退化。
superpowers:writing-plans。.gitignore 已覆盖的临时目录：notes/plans/ 或就近 **/_notes/plans/，默认不 stage / commit。cross-review 或主 AI 自审，再润色 plan；同轮模型并发且互不可见结论，无问题时立即 PASS，只有修订后才用 fresh agents 复审。未经 review / 自审润色不进入实现。评审只看 plan 或代码 diff，不替主 AI 做最终决策。重点检查：
flow-long-task 与 cross-review 并发评审固定 staged diff，重点查文件结构、命名规范、barrel 是否默认用 export * 而非 export { ... }、JSDoc 完备性和中文注释。用户明确认可的小任务单次 commit 不触发该要求；改动面大或核心功能不适用该豁免。cross-review 并发使用 2–3 个 fresh 独立 reviewer，并按异模型优先或同模型双实例降级规则选择阵容；不得串行把一个 reviewer 的结论喂给同轮其它 reviewer。按根 AGENTS.md 的受影响模块策略验证。常见组合：
pnpm --filter <pkg> exec eslint . --fix
pnpm --filter <pkg> exec tsc --noEmit
pnpm --filter <pkg> exec vitest run [test-file]
纯文档或 notes 改动至少跑 git diff --check。用户可见行为变化必须补 docs 或转对应 docs skill。
cross-review 或主 AI 自审。