メニュー
当需要设计数据模型、规划数据架构或设计缓存迁移方案时使用。数据架构指挥官，协调data-architecture-spec（设计）和data-architecture-impl（实现）两个子Skill的完整流程，确保数据架构合理、可迁移、高性能，设计产出经人类审查后再生成代码。关键词：数据架构、数据模型、数据迁移、缓存策略、数据库设计、数据方案、代码生成。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | data-architecture-orchestrator |
| description | 当需要设计数据模型、规划数据架构或设计缓存迁移方案时使用。数据架构指挥官，协调data-architecture-spec（设计）和data-architecture-impl（实现）两个子Skill的完整流程，确保数据架构合理、可迁移、高性能，设计产出经人类审查后再生成代码。关键词：数据架构、数据模型、数据迁移、缓存策略、数据库设计、数据方案、代码生成。 |
| metadata | {"module":"后端架构与开发","sub-module":"数据架构","type":"orchestrator","version":"4.0","domain_tags":["电商","SaaS","金融","物流","通用"],"trigger_examples":["设计数据模型","规划数据架构","设计缓存策略","规划数据迁移方案"]} |
数据是系统根基，模型决定上限，缓存决定下限。设计先行，审查后实现。
编排协议遵循 orchestrator-protocol.md 统一标准。
pipeline: data-architecture-orchestrator
version: 4.0
post_pipeline:
- action: stage-summary
output: output/phase-reports/backend/data-architecture-orchestrator.md
stages:
- id: phase-1
name: "数据架构设计规范"
skills:
- data-architecture-spec
gate:
condition: "ER图+DDL+数据字典+缓存策略+迁移方案完整 + 人类审查通过"
fail_action: "缺失项必须补充"
- id: phase-2
name: "数据层代码实现"
depends_on: [phase-1]
skills:
- data-architecture-impl
gate:
condition: "代码可编译 + Migration可执行 + API数据需求100%覆盖 + 代码自审P0=0 + 人类确认通过"
fail_action: "缺失项补充后重新验证"
Skill: data-architecture-spec
输入:
PRD: output/pm-design/design-prd/prd.md
PRD结构化数据: output/pm-design/design-prd/prd.json
API契约: output/backend-api-design/api-design-spec/openapi.yaml
database_type: 用户提供
数据量预估: 用户提供（可选）
并发量预估: 用户提供（可选）
当前Schema: 用户提供（可选）
输出: output/backend-data-architecture/data-architecture-spec/
验证: ER图+DDL+数据字典+缓存策略+迁移方案完整
模式: 🤖→👤
内部步骤:
1. 业务数据字典提取：从PRD提取业务数据实体定义
2. 实体识别与关系建模：设计ER图
3. 表结构与索引设计：DDL+索引策略
4. 缓存策略设计：多级缓存+穿透/击穿/雪崩防护
5. 数据迁移方案：迁移+回滚脚本
⏸ 设计审查卡口：ER图+DDL+数据字典+缓存策略+迁移方案完整 → 人类审查设计产出 → 审查通过后进入代码实现
Skill: data-architecture-impl
输入:
ER模型: output/backend-data-architecture/data-architecture-spec/er_model.json
缓存策略: output/backend-data-architecture/data-architecture-spec/cache_strategy.json
迁移方案: output/backend-data-architecture/data-architecture-spec/migration_plan.json（可选）
API契约: output/backend-api-design/api-design-spec/openapi.yaml
project_dir: 用户提供
tech_stack: 用户提供
database_type: 用户提供
输出: output/backend-data-architecture/data-architecture-impl/ + 代码写入 {project_dir}/src/
验证: 代码可编译，Migration可执行，API数据需求100%覆盖，代码自审P0=0
模式: 🤖→👤
内部步骤:
1. Model代码生成：models/entities+数据库配置
2. Migration和种子数据生成：迁移脚本+种子数据
3. Repository代码生成：CRUD+常用查询
4. 缓存层代码生成：Redis+CacheRepository
5. 对齐检查与代码自审：API对齐+DDL一致性+缓存对齐+N+1检查
6. 数据层测试代码生成：Model+Repository+Migration测试
遵循 orchestrator-protocol.md 阶段总结协议。
| 参数 | 值 |
|---|---|
| 子Skill输出路径 | output/backend-data-architecture/ |
| 总结输出路径 | output/phase-reports/backend/data-architecture-orchestrator.md |
下游衔接: primary: backend-architecture-orchestrator（数据架构完成后，进入后端架构设计，基于数据模型和API契约设计服务架构） alternatives: - target: api-design-orchestrator reason: 数据模型变更需要反向更新API契约 condition: 数据架构设计发现API契约需要调整时
| 卡口 | 条件 | 未通过处理 |
|---|---|---|
| 数据架构设计完成 | data-architecture-spec输出文件已生成且非空 | 缺失项必须补充 |
| 设计审查通过 | 人类审查设计产出并确认 | 人类修改意见反馈后重新设计 |
| 数据层代码实现完成 | data-architecture-impl输出文件已生成且非空 | 缺失项补充后重新验证 |
| 阶段总结已生成 | output/phase-reports/backend/data-architecture-orchestrator.md 已生成且6项结构均非空 | 补充缺失结构项后重新生成 |
| 决策点 | 触发条件 | 决策内容 |
|---|---|---|
| 范式vs反范式 | data-architecture-spec执行时 | 读写比决定，人类确认平衡点 |
| 分库分表策略 | data-architecture-spec执行时 | 影响成本和复杂度，人类确认 |
| 缓存一致性级别 | data-architecture-spec执行时 | 强一致vs最终一致，人类确认 |
| 迁移执行时间 | data-architecture-spec执行时 | 低峰期窗口，人类确认 |
| 设计审查确认 | data-architecture-spec完成后 | 审查数据架构设计是否满足需求，确认后才进入代码实现 |
| 数据迁移执行确认 | data-architecture-impl输出完成 | 迁移方案和回滚脚本生成完成，人类确认是否执行迁移 |
| 异常类型 | 处理策略 |
|---|---|
| PRD数据需求不明确 | 基于API契约推断数据实体，标注"推断值" |
| 数据量预估缺失 | 使用保守估计值，标注"预估待验证" |
| 缓存一致性策略冲突 | 标注冲突项，提供强一致和最终一致双方案，人类决策 |
| 迁移回滚脚本生成失败 | 阻塞迁移执行，必须人工编写回滚脚本 |
| 分库分表策略不确定 | 提供单表+分表双方案对比，人类决策 |
| 设计审查不通过 | 根据人类修改意见调整设计，重新审查 |
| 代码自审P0问题 | 自动修复后重新自审，无法修复则阻塞输出 |
| 阶段总结生成失败 | 基于已完成的子Skill输出生成部分总结，缺失项标注"数据缺失"，不阻塞编排完成 |
当需要评估获客渠道或优化获客漏斗时使用。用户获取指挥官，调度 acquisition-analysis（获客分析一体化），实现从渠道评估到漏斗优化的闭环。关键词：用户获取、获客渠道、漏斗优化、渠道评估、获客策略、acquisition-analysis、拉新、获客。
当需要识别和工程化Aha Moment时使用。Aha Moment自动工程化Pipeline，分析留存数据和行为数据，自动识别Aha Moment候选，测量到达率，识别最短路径，输出Onboarding优化建议。关键词：Aha Moment、激活时刻、用户激活、到达率、Onboarding优化、什么时候觉得好用、体验核心价值、爽点在哪。
当需要优化用户Onboarding流程时使用。Onboarding自动优化Pipeline，分析Onboarding数据和用户分群，自动生成个性化引导策略，设计A/B测试方案。关键词：Onboarding、新用户引导、引导优化、个性化引导、用户激活、新手引导、上手快、引导太长。
当需要识别Aha Moment或设计Onboarding流程时使用。用户激活指挥官，调度activation-aha/onboarding。关键词：用户激活、Aha Moment、Onboarding、新用户引导、新手引导、激活率。
当需要管理Sprint周期或追踪敏捷执行时使用。敏捷执行指挥官，调度 agile-sprint-planning、agile-daily-sync、agile-review 子Skill执行。agile-review 已合并 retrospective-auto 的自动回顾能力。关键词：敏捷执行、Sprint规划、每日站会、Sprint评审、敏捷管理、Sprint复盘、迭代复盘、敏捷开发、复盘报告、自动回顾。
当需要自动化Sprint评审和复盘报告时使用。Sprint评审与复盘报告一体化，Step 1完成Sprint评审（产出清单整理、Demo准备清单、反馈收集分类、数据收集、问题识别、改进建议生成），Step 2生成完整复盘报告（Sprint目标达成分析、交付质量评估、团队速率趋势、改进行动项、下一Sprint建议），Step 3完成上线复盘（效果复盘、工程质量复盘、过程复盘、改进行动项生成）。关键词：Sprint Review、Sprint Retro、迭代评审、迭代回顾、敏捷复盘、评审会、复盘报告、Sprint复盘、改进行动项、做得怎么样、上线复盘、发布复盘、效果评估、持续改进。