| name | multica-technical-design |
| description | 基于 PRD 与现有代码产出最小技术方案。用于 @Architect 架构分析、影响评估、实现方案设计；草稿就绪后交 multica-artifact-design-sync 落地。 |
Technical Design
Purpose
基于 PRD（或 Issue）与现有代码库，产出最小可行的技术设计（只管「写什么」，不管「落到哪个平台」）。
与 multica-artifact-design-sync 分工：technical-design 产出结构与内容；design-sync 调用 Confluence/JIRA platform skills 落地。
Process
- 读 PRD / Issue 与验收标准（AC-）。
- 检查当前实现（优先 codegraph / 现有模式，不大面积扫库）。
- 识别相关模块与现有模式。
- 确定最小可行改动（非目标写清楚）。
- 识别依赖与风险（RISK-）。
- 定义验证方式（对齐 AC-）。
- 信息不足 → BLOCKED，不猜。
Principles
现有模式 > 新抽象
小改动 > 大重构
复用 > 新依赖
本地草稿路径
先写 Markdown 草稿，再交 design-sync 发布：
docs/design/<ISSUE-KEY>/design.md
章节基线见 multica-platform-confluence 的 scripts/templates/design-template.md。
Output（必须包含）
| 章节 | 内容 |
|---|
| 理解 | 系统当前做什么 |
| 建议改动 | 最小可行方案 |
| 受影响组件 | 文件 / 模块 / 服务 |
| 实现步骤 | 给 @FrontendDev / @BackendDev 的可执行步骤 |
| 验证计划 | 如何验证，对应 AC- |
| 风险与边界 | RISK- 编号 |
Handoff
草稿完成后，用 multica-artifact-design-sync skill：
先用 multica-technical-design 写 docs/design/<ISSUE-KEY>/design.md，
再用 multica-artifact-design-sync 发布到 Confluence（父页面 <CONFLUENCE_DESIGN_PAGE_ID>）并回写 JIRA 链接。
Confluence 设计目录：pageId=<CONFLUENCE_DESIGN_PAGE_ID>
为什么有效
设计先本地 Markdown、再 upsert Confluence，与 dev-workflow 一致：可 diff、可评审、链接稳定回写 JIRA，下游 @FrontendDev / @BackendDev / @Tester 靠链接消费。
