sop-dev

name	sop_dev
description	Use this skill when you are a Dev agent and need to produce a technical design document for a feature. Triggers: receiving a feature requirement or task assignment with clear acceptance criteria. Do NOT use for writing requirement documents, doing integration/E2E testing, or modifying task assignments.

Dev 技术设计 SOP

概述

本 SOP 定义 Dev 接收任务单后的标准技术设计流程，确保每个功能有可实现、可测试的技术方案。

---

步骤 1：任务单完整性检查

在开始设计之前，确认以下字段均已明确：

检查项	说明	缺失时的处理
功能描述	要实现什么功能	向 Manager 提出澄清请求
输入/输出格式	接口的输入和输出数据结构	向 Manager 提出澄清请求
验收标准（DoD）	做到什么程度算完成	必须有，没有则退回 Manager
技术约束	语言、框架、性能要求	按团队约定推断，有疑义时确认

⚠️ 验收标准缺失时，输出澄清请求，不进行技术设计。

---

步骤 2：架构分析

分析功能在系统中的定位：

• 模块归属：这个功能属于哪个模块，依赖哪些已有模块
• 复杂度评估：简单工具函数 / 独立模块 / 需要新增服务
• 关键风险：外部依赖（API/数据库）、并发、错误处理

---

步骤 3：接口设计

定义清晰的接口边界（选择适用的格式）：

函数接口：

def parse_schedule(text: str, base_date: datetime) -> dict[str, Any]:
    """
    解析自然语言日程描述。

    Args:
        text: 用户输入的中文日程描述
        base_date: 相对时间的基准日期

    Returns:
        {
            "title": str,
            "start_time": str,  # ISO 8601 格式
            "end_time": str,
            "location": str,
            "attendees": list[str]
        }

    Raises:
        ParseError: 输入无法解析为有效日程
    """

---

步骤 4：实现要点

列出核心逻辑的关键决策点（不是完整代码，是实现路线图）：

• 技术方案选型及理由
• 核心算法或处理流程（可用伪代码）
• 错误处理策略
• 性能优化考量（如需）

---

步骤 5：单元测试用例

覆盖：正常路径（2-3个）+ 边界用例（2-3个）+ 异常路径（1-2个）

| 用例ID | 用例名称 | 输入 | 期望输出 | 类型 |
|--------|---------|------|---------|------|
| UT-01  | 标准日程解析 | "明天下午3点开会" | {start: "2026-...", ...} | 正常 |
| UT-02  | 时间范围解析 | "2点到4点代码评审" | {start: ..., end: ...} | 正常 |
| UT-03  | 相对时间-下周 | "下周一上午10点" | ... | 边界 |
| UT-04  | 无效输入 | "随便说点什么" | ParseError | 异常 |

---

步骤 6：输出 tech_design.md

使用标准四段格式输出，保存至 /workspace/tech_design.md：

# 技术设计 - {功能名称}

## 1. 架构说明

## 2. 接口定义

## 3. 实现要点

## 4. 单元测试用例

---

步骤 7：保存输出

调用 memory-save skill，将 tech_design.md 保存至 /workspace/tech_design.md。