Product Technical Architecture

Use this skill to turn a completed PRD into technical architecture documents that product managers can understand and developers can implement.

Positioning

This skill sits after PRD generation and before demo development.

Correct order:

1. PRD: define what to build.
2. Technical architecture: define how to build it.
3. Demo: build and verify the runnable version.
4. Testing or evaluation: find issues and iterate.

Do not write a new PRD. Do not directly generate demo code unless the user explicitly asks after the architecture is complete.

Required Input

Ask for missing information only when it is needed:

1. PRD file path.
2. Product name.
3. Product flow summary, if the PRD is unclear.
4. Output scope: full architecture only, or also interface design, database design, task breakdown, risks, and acceptance criteria.

When the user provides a PRD path, read the PRD first. If the user also provides competitor analysis or demo files, use them only as supporting context; the PRD remains the main source.

Workflow

1. Read the PRD.
2. Extract product goal, target users, core workflow, input, processing, output, and success criteria.
3. Identify required modules: frontend, backend, Agent or AI orchestration, data storage, third-party services, logs, and permissions.
4. Output a concise technical element summary first.
5. Ask the user to confirm whether to continue.
6. Generate the requested documents in Markdown.
7. Save output files to the PRD directory unless the user specifies another path.

Writing Style

Write for product managers first, developers second.

Use simple Chinese. Prefer concrete flow, module, interface, data, boundary, and exception descriptions. Avoid abstract architecture jargon unless it is necessary.

Good style:

• "用户上传 CSV 或 Excel 后，系统先校验文件格式和大小，再解析表头、字段类型、样本数据和基础统计。"
• "SQL 执行前必须经过安全校验，只允许 SELECT 查询，禁止删除、修改、建表等操作。"

Avoid:

• "系统采用高内聚低耦合架构。"
• "通过智能中台实现能力沉淀。"

Core Output

Default file:

<产品名>-技术架构设计.md

Recommended chapters:

1. 产品技术架构定位
2. 用户使用流程
3. 系统整体架构
4. 前端模块设计
5. 后端模块设计
6. Agent 调用链路
7. 数据存储设计
8. 接口设计
9. 安全与权限设计
10. 异常处理与兜底机制
11. 部署与运行方案
12. 开发任务拆解
13. 验收标准
14. 技术风险

Optional Outputs

Generate these only when useful or requested:

1. <产品名>-接口设计说明.md
2. <产品名>-数据库设计说明.md
3. <产品名>-开发任务拆解.md
4. <产品名>-技术风险与验收标准.md

Architecture Content Requirements

Product Architecture Positioning

Explain what problem the product solves, what the user inputs, what the system processes, and what the user receives.

User Flow

Describe the main path from user entry to final result. Include key states such as uploading, parsing, confirming, generating, completed, and error when applicable.

System Architecture

Split the system into understandable modules. Common modules include:

1. Frontend interaction module
2. File upload or input module
3. Data parsing module
4. Agent orchestration module
5. Generation module
6. Execution or tool module
7. Result display module
8. Log and evaluation module

Agent Call Chain

If the product uses Agent or AI capabilities, explain:

1. Which Agent controls the main process.
2. Which Skills, tools, or models are called.
3. What input each step receives.
4. What output each step returns.
5. Where user confirmation is required.
6. What happens when AI output is uncertain or wrong.

Data Design

Explain what data must be stored and why:

1. User input data
2. Uploaded files or parsed content
3. Intermediate generation results
4. Final outputs
5. Operation logs
6. Error logs
7. Evaluation or feedback records

Keep database explanations product-readable. Tables can be listed with field name, meaning, and purpose.

Interface Design

For each important interface, write:

1. Interface name
2. Usage scenario
3. Request parameters
4. Response fields
5. Error handling

Do not over-design low-value interfaces.

Security and Boundaries

State risks and controls clearly. Common controls include:

1. File type and size limits
2. User data isolation
3. Sensitive information masking
4. SQL safety checks
5. Permission checks
6. Model output review
7. Rate limiting

Exception Handling

For each core failure scenario, give a product-facing fallback:

1. File upload failure
2. File parsing failure
3. Field recognition uncertainty
4. Agent generation failure
5. Tool execution failure
6. Result rendering failure
7. Download failure

Development Tasks

Break tasks by frontend, backend, Agent, data, testing, and deployment. Each task should be concrete enough for a developer or product owner to track.

Acceptance Criteria

Write measurable acceptance criteria. Include normal flow, abnormal flow, output quality, security, and performance where relevant.

Final Response

After generating files, tell the user:

1. What was generated.
2. The absolute local file path.
3. Which source PRD was used.
4. Whether any assumptions were made.

Keep the final response short.