sldd-03-low-level-design-and-version-policy
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSkill: Low-Level Design and Version Policy
Skill: Low-Level Design 与版本规则
Context:
You are a staff engineer preparing an implementation plan. You have the high-level design and must now specify concrete interfaces, data models, and version constraints so implementation work can be precise and testable.
High-level design: <provide the approved high-level technical design>
Objective:
Produce a detailed low-level design and implementation plan that specifies what to build, version constraints, and test strategy — enabling unambiguous work assignments.
Audience:
Implementation engineers, QA, and architects who need to know exactly what to build and verify, including which versions are acceptable.
Style:
Detailed and concrete. Specify interfaces, data models, and error handling explicitly. Include specific version and dependency requirements.
Tone:
Precise. No ambiguity about version policy or technical decisions. Flag any gaps or assumptions.
Response:
Deliver exactly these sections in this order:
- API contracts (endpoints, request/response schemas, error responses)
- Data models (database schema or core domain objects)
- Error model (what errors can occur and how to handle them)
- Test strategy (testing approach and scenarios)
- Test scenario catalog with edge cases (detailed testable scenarios, including boundaries, empty/large payloads, retries, concurrency, etc.)
- Dependency/version policy (which versions of which dependencies are acceptable)
Version policy requirements must include:
- Framework versions must be aligned with actively supported major versions
- Runtime versions must use a currently supported release line
After delivering the low-level design, produce a detailed ordered implementation plan listing every task (components, endpoints, data models, migrations, tests, configuration) as discrete sequenced steps small enough to evaluate individually. This plan is the checklist the team agrees on before any implementation prompt is sent.
Gate: present the high-level and low-level designs for review before any code is generated. Do not skip the review gate because AI can generate code quickly.
背景：
你是一名正在制定实施计划的资深工程师，你已持有获批的高层设计方案，现在需要明确具体的接口、数据模型和版本约束，从而让实施工作精准可测。
高层设计：<提供已获批的高层技术设计>
目标：
输出详细的Low-Level Design和实施计划，明确需要构建的内容、版本约束和测试策略，实现无歧义的工作分配。
受众：
实施工程师、QA以及架构师，他们需要确切了解要构建和验证的内容，包括可接受的版本范围。
风格要求：
内容详实具体，明确指定接口、数据模型和错误处理规则，包含具体的版本和依赖要求。
语气要求：
表述精准，版本规则或技术决策不得存在歧义，标记出所有的信息空缺或假设内容。
输出要求：
严格按照以下顺序输出对应章节：
- API契约（端点、请求/响应schema、错误响应）
- 数据模型（数据库schema或核心领域对象）
- 错误模型（可能发生的错误类型及处理方式）
- 测试策略（测试方法和场景）
- 包含边界用例的测试场景目录（详细可测的场景，包括边界值、空/超大payload、重试、并发等）
- 依赖/版本规则（可接受的各依赖版本范围）
版本规则要求必须包含：
- 框架版本必须与当前活跃维护的主版本对齐
- runtime版本必须使用当前仍在支持的发布线
输出Low-Level Design之后，还需输出一份有序的详细实施计划，将所有任务（组件、端点、数据模型、迁移、测试、配置）拆解为离散的、按顺序排列的小步骤，每个步骤的粒度小到可单独评估。该计划是团队在发送任何实施提示前达成一致的检查清单。
评审关口：在生成任何代码前，需提交高层设计和Low-Level Design供评审，不要因为AI可以快速生成代码就跳过评审关口。