Back to Details

established-pattern-delivery

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Established-Pattern Delivery Skill

既定模式交付Skill

Purpose

用途

Use this skill for full implementation when the product direction, technical approach, and interface shape are sufficiently known.
This is the delivery path for low-uncertainty work or for uncertain work after spikes have reduced the major risks.
当产品方向、技术方案和接口形态已足够明确时，使用此Skill进行完整实现。
这是低不确定性工作的交付路径，或是在探索（spike）已降低主要风险后的不确定性工作的交付路径。

When To Use

使用场景

Use this skill when:
  • The feature follows an existing architecture or implementation pattern.
  • The team has already agreed on product direction and interface shape.
  • A spike or demo has proven the risky parts.
  • The remaining work is implementation, tests, polish, and verification.
Do not use this skill to skip discovery when the direction is uncertain.
使用此Skill的场景：
  • 功能遵循现有架构或实现模式。
  • 团队已就产品方向和接口形态达成共识。
  • 探索（spike）或演示已验证了高风险部分。
  • 剩余工作为实现、测试、优化和验证。
当方向不明确时，请勿使用此Skill跳过探索阶段。

Confirm The Pattern

确认模式

Before coding, state the established pattern being followed.
Examples:
  • Another CRUD endpoint following the existing service/repository/route shape
  • Another UI panel following existing component conventions
  • Another tool using the existing tool schema and transcript pattern
  • Another provider adapter following existing adapter boundaries
If there is no real existing pattern, route back to product, technical, or interface spike.
Useful checkpoint shape:
Pattern: Add another settings panel following 
AccountSettingsPanel
with route-level loader, form action, Zod validation, and component-local pending state. Scope: UI component, route action, targeted validation tests, and one browser smoke. Not changing: persistence schema, public API shape, or navigation model. Verification between tasks: targeted test after validation, curl/action smoke after route wiring, screenshot after UI integration.
编码前，明确要遵循的既定模式。
示例：
  • 遵循现有service/repository/route结构的另一个CRUD端点
  • 遵循现有组件规范的另一个UI面板
  • 遵循现有工具 schema 和转录模式的另一个工具
  • 遵循现有适配器边界的另一个提供商适配器
如果没有实际存在的模式，则回到产品探索、技术探索或接口探索阶段。
实用的检查点格式：
Pattern: Add another settings panel following 
AccountSettingsPanel
with route-level loader, form action, Zod validation, and component-local pending state. Scope: UI component, route action, targeted validation tests, and one browser smoke. Not changing: persistence schema, public API shape, or navigation model. Verification between tasks: targeted test after validation, curl/action smoke after route wiring, screenshot after UI integration.

Task Breakdown

任务拆分

Break work into area-focused tasks. Do not force every task to be a complete vertical slice.
Prefer tasks like:
  • Types/schemas
  • Persistence/repository
  • Service/domain logic
  • API route
  • UI component shape
  • UI integration
  • Tests
  • E2E/manual verification
This keeps implementation inspectable and prevents one giant patch from mixing product, API, UI, and persistence changes.
将工作拆分为聚焦特定领域的任务。不要强行让每个任务都成为完整的垂直切片。
优先选择以下类型的任务：
  • 类型定义/schema
  • 持久化/仓库层
  • 服务/领域逻辑
  • API路由
  • UI组件形态
  • UI集成
  • 测试
  • 端到端/手动验证
这能让实现过程可检查，避免单个巨型补丁同时混合产品、API、UI和持久化变更。

UI Work

UI工作

For UI changes, agree on the rough UI shape before coding.
Use:
  • text walkthroughs
  • low-fidelity mocks
  • screenshots
  • component sketches
  • browser screenshots after implementation
When 
superpowers:brainstorming
, 
grill-me
, or adversarial-review skill is available, use one of them before finalizing significant UI shape. Choose the one that best fits the user's installed skills and the shape of the work.
对于UI变更，在编码前就大致的UI形态达成共识。
可使用：
  • 文本走查
  • 低保真原型
  • 截图
  • 组件草图
  • 实现后的浏览器截图
当
superpowers:brainstorming
、
grill-me
或adversarial-review Skill可用时，在确定重要UI形态前使用其中一种。选择最适合用户已安装Skill和工作形态的方式。

TDD And Tests

测试驱动开发（TDD）与测试

Use TDD for full implementation where practical:
  • Write or update a failing targeted test.
  • Implement the behavior.
  • Run the targeted test.
  • Add edge-case tests where they protect real risks.
  • Run broader verification before final completion.
Do not write tests that only prove implementation details while missing the product behavior.
If TDD is not practical for a task, state why and choose the smallest verification loop that can catch the real risk.
在可行的情况下，使用TDD进行完整实现：
  • 编写或更新一个失败的针对性测试。
  • 实现功能。
  • 运行针对性测试。
  • 添加能防范实际风险的边界用例测试。
  • 在最终完成前进行更全面的验证。
不要编写仅验证实现细节却忽略产品功能的测试。
如果某任务不适合使用TDD，说明原因并选择能捕捉实际风险的最小验证循环。

Manual And Integration Checks Between Tasks

任务间的手动与集成检查

Between tasks, use curl/manual/e2e/visual checks where applicable.
Examples:
  • curl route after API implementation
  • DB/persistence check after repository changes
  • screenshot after UI work
  • e2e flow after wiring
  • live smoke after SDK/provider changes
Manual checks are not a substitute for tests, but they often reveal missing assumptions earlier than tests.
If no manual or integration check applies, state why before moving to final verification.
在任务之间，酌情使用curl/手动/端到端/视觉检查。
示例：
  • API实现后使用curl测试路由
  • 仓库层变更后检查数据库/持久化
  • UI工作完成后截图
  • 连接完成后端到端流程测试
  • SDK/提供商变更后进行线上冒烟测试
手动检查不能替代测试，但它们往往比测试更早发现遗漏的假设。
如果没有适用的手动或集成检查，在进入最终验证前说明原因。

Interface And Schema Changes

接口与Schema变更

If implementation reveals a need for new or changed API/schema/domain concepts:
  • classify the change by risk
  • update the interface/schema deviation ledger
  • route back to interface design if the change is high risk or changes product semantics
Do not silently introduce new persisted fields, public contracts, source-of-truth models, or domain entities while "just implementing."
如果实现过程中发现需要新增或修改API/schema/领域概念：
  • 按风险等级对变更分类
  • 更新接口/schema偏差记录
  • 如果变更风险高或改变了产品语义，则回到接口设计阶段
请勿在“只是实现”的过程中悄悄引入新的持久化字段、公共契约、事实源模型或领域实体。

Exit Criteria

退出条件

Leave this skill only when:
  • The implementation follows the agreed pattern.
  • Targeted tests cover the behavior.
  • Relevant manual/integration checks have been run.
  • Any review comments have been triaged.
  • Verification gates are ready to run.
只有满足以下条件时，才可结束使用此Skill：
  • 实现符合已达成共识的模式。
  • 针对性测试覆盖了功能。
  • 已完成相关的手动/集成检查。
  • 所有评审意见已分类处理。
  • 验证环节已准备就绪。