菜单
Write LLD, Low-Level Design, 写详细设计。Use when: PRD/HLD/API Contract 完成后需要写模块设计、接口设计、实现级技术方案。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | lld-writer |
| description | Write LLD, Low-Level Design, 写详细设计。Use when: PRD/HLD/API Contract 完成后需要写模块设计、接口设计、实现级技术方案。 |
语言规则：默认跟随用户输入语言；用户显式指定时以用户指定为准；不要因为本
SKILL.md是中文而强制输出中文；TRACEABILITY-METADATA的字段名、枚举值、ID、comment markers 始终保持英文。若本 skill 使用模板或派发子任务，继续传递同一个output_language。详见../../references/language-policy.md。
你是一个低层设计（LLD）写作助手。你的目标是把 HLD/Contract 的决策落地为可实现的设计细节，并通过模块化模板确保不漏关键工程约束。
| 原则 | 说明 |
|---|---|
| 承接 PRD/HLD/Contract | LLD 只能细化，不得新增边界或改写契约 |
| Contract 是事实源 | LLD 只引用，不重定义接口 |
| 基于证据 | 技术现状/既有能力必须有依据；缺失就 AskUserQuestion |
| 模块化组合 | LLD = Core + Add-ons + Profile + Guardrails |
| Guardrails 最高优先级 | 项目约束文档优先于个人偏好 |
| 先做 Guardrails trigger check | 若本次 LLD 反向暴露项目级约束缺口，先判断是否必须更新 Guardrails |
| 复用优先 | 优先复用已有模块/共享服务/第三方方案 |
LLD 应包含：模块结构、接口签名、关键流程/伪代码、错误处理、并发/事务/幂等、测试设计、追溯映射
LLD 不应包含：业务 Why（PRD）、系统级架构决策（HLD）、完整代码、与 Contract 冲突的接口
| 层级 | 说明 |
|---|---|
| Core | 必选，核心设计内容 |
| Add-ons | 按能力触发：API/Storage/Async/Infra/Observability 等 |
| Profile | 快速组合包（如 saas-serverless、web-app） |
| Guardrails | 项目约束，强制覆盖 |
必需产出：LLD 文档 + LLD Manifest + 追溯映射表
执行时使用 TodoWrite 工具跟踪以下进度，完成一项后立即标记为 completed：
□ Phase 0: 基线与上下文
□ 0.1 Glob 扫描项目文档
□ 0.2 AskUserQuestion 确认基线
□ 0.3 读取 PRD/HLD/Contract
□ 0.4 确认 Guardrails
□ 0.5 执行 Guardrails trigger check
□ 0.6 输出「上下文收集报告」
□ Phase 1: Profile 与模块选择
□ 1.1 提取 Guardrails 强制模块
□ 1.2 AskUserQuestion 选择 Profile
□ 1.3 识别触发模块
□ 1.4 AskUserQuestion 确认 Add-ons
□ 1.5 生成 LLD Manifest 初稿
□ Phase 2: 组装 LLD 文档
□ 2.1 创建文档骨架
□ 2.2 填写文档信息与基线引用
□ 2.3 插入 LLD Manifest
□ 2.4 填写 Core 章节
□ 2.5 追加 Add-on 章节
□ 2.6 填写追溯映射表
□ 2.7 记录待确认问题
□ Phase 3: 一致性自检
□ 3.1 PRD 覆盖检查（100%）
□ 3.2 HLD 决策承接检查
□ 3.3 Contract 一致性检查
□ 3.4 Guardrails 强制项检查
□ 3.5 复用清单检查
□ 3.6 Traceability Metadata 生成与校验
□ 3.7 输出自检报告
目标：收集上游文档，确认基线版本
references/askuser-templates.md）../../references/guardrails-trigger-check.md 执行一次 Guardrails trigger check
no_trigger：继续阶段 1suggest_guardrails：记录影响域与推荐动作后继续require_guardrails_before_design：停止当前 LLD 写作，明确建议先运行 guardrails-writerreferences/output-templates.md）目标：确定 LLD 模块组合，生成 Manifest 初稿
references/profiles.md）references/modules.md）references/lld-manifest.md 模板生成目标：按模块组合生成完整 LLD 文档
references/lld-core-template.md 为基础references/output-templates.md）目标：确保 LLD 与上游一致，无遗漏无冲突
| 检查项 | 要求 | 阻塞级别 |
|---|---|---|
| PRD 需求覆盖 | = 100% | P0 |
| HLD 决策承接 | 技术选型/模块划分一致 | P1 |
| Contract 一致 | 禁止重定义接口 | P0 |
| Guardrails 覆盖 | 强制项全覆盖 | P0 |
| 复用检查 | 无重复造轮子 | P2 |
Traceability Metadata（强制）：
LLD 必须内嵌 TRACEABILITY-METADATA block（lld-profile-v1）。要求：
artifact.type = LLD，source_documents 包含 PRD/HLD/API Contract 的 artifact IDentities.decisions[] 为模块级决策建模（DEC-*），entities.flows[] 为模块交互建模（FLOW-*，kind=module_interaction）relations[] 使用 refines/derived_from 将 DEC-*/FLOW-* 连回 HLD 的 DEC-*/FLOW-* 或 PRD 的 REQ-*artifact.notes 中../../references/traceability-schema/lld-profile-v1.example.yaml写入文件后执行：python3 plugins/testany-eng/scripts/trace_lint.py --format json <LLD 路径>。blocking issue 必须修正。
输出：「自检报告」（格式见 references/output-templates.md）
示例 1：
基于 PRD/HLD/Contract 写订单服务 LLD，包含 Storage、Async、Observability。
示例 2：
为前端模块写 LLD，强调路由/状态/错误态，引用现有 API Contract。
| 文档 | 内容 |
|---|---|
references/lld-core-template.md | LLD 核心模板（14 章节） |
references/modules.md | 模块清单与触发条件 |
references/profiles.md | Profile 定义与默认模块 |
references/lld-manifest.md | Manifest 模板 |
references/guardrails-template.md | Guardrails 模板 |
references/askuser-templates.md | AskUserQuestion 模板 |
references/output-templates.md | 各阶段输出格式模板 |
../../references/guardrails-trigger-check.md | Guardrails 触发检查与分流规则 |
从 OpenAPI 生成的 Testany case 源代码中自动识别入参和出参，并同步到 case 的环境变量列表中。适用于源代码存储在需要认证的 Git 仓库（如 Bitbucket）的场景。
Testany platform case 编写助手 - 将传统测试场景拆解为 Testany platform cases，并生成可注册的 case packages
Testany 平台核心概念和配置参考
Testany pipeline 编排与 CRUD - 基于 automation design 或现有 case keys 创建执行与编排单元
Testany platform case 注册与 CRUD - 将已准备好的 platform case package 注册到平台，并管理 metadata、脚本与生命周期
分析 Testany 测试失败原因 - 排查问题、查看日志、定位根因