kiro-skill

需求阶段

将粗略的想法转化为结构化需求，包含用户故事和 EARS 验收标准。

流程

1. 生成初始需求

   • 创建 .kiro/specs/{feature-name}/requirements.md
   • 使用 kebab-case 命名功能（例如，“user-authentication”）
   • 根据用户的想法编写初始需求
   • 不要先逐个提问——先生成内容，再进行迭代

2. 需求结构

# Requirements Document

## Introduction

[Feature summary - what problem does this solve?]

## Requirements

### Requirement 1

**User Story:** As a [role], I want [feature], so that [benefit]

#### Acceptance Criteria

1. WHEN [event] THEN [system] SHALL [response]
2. IF [precondition] THEN [system] SHALL [response]
3. WHEN [event] AND [condition] THEN [system] SHALL [response]

### Requirement 2

**User Story:** As a [role], I want [feature], so that [benefit]

#### Acceptance Criteria

1. WHEN [event] THEN [system] SHALL [response]

EARS 格式

需求语法简易方法——结构化验收标准：

• WHEN [event] THEN [system] SHALL [response] - 事件驱动
• IF [condition] THEN [system] SHALL [response] - 条件驱动
• WHILE [state] [system] SHALL [response] - 状态驱动
• WHERE [feature] [system] SHALL [response] - 通用规则
• [system] SHALL [response] - 无条件

审核与迭代

3. 征求批准
   • 创建或更新需求后
   • 询问：“需求看起来合适吗？如果合适，我们就可以进入设计阶段。”
   • 如果用户要求修改，则进行调整
   • 持续进行反馈与修订，直到获得明确批准
   • 未获得明确批准前，不得进入设计阶段

最佳实践

• 考虑边界情况和技术约束
• 关注用户体验和成功标准
• 指出需要进一步澄清的方面
• 可以针对具体方面提出有针对性的问题
• 将复杂需求拆分为较小的部分

故障排除

如果澄清过程陷入停滞：

• 建议转而讨论其他方面
• 提供示例或选项
• 总结已确定的内容并指出空缺
• 根据现有信息继续推进，而不是停滞不前

设计阶段

根据已批准的需求创建全面的设计文档，并在设计过程中开展调研。

前提条件

• 确认 .kiro/specs/{feature-name}/requirements.md 文件存在
• 进入设计阶段前，需求必须已获批准

研究阶段

1. 确定研究需求

   • 需要调查哪些技术／模式？
   • 哪些现有解决方案可以为设计提供参考？

2. 开展研究

   • 使用可用资源（网络搜索、文档）
   • 在对话线程中逐步积累背景信息
   • 不要创建单独的研究文件
   • 总结关键发现
   • 附上相关链接作为来源引用

设计文档结构

创建 .kiro/specs/{feature-name}/design.md，包含：

概述

• 设计方案的高层描述
• 关键架构决策及其理由

架构

• 系统架构概述
• 组件关系
• 数据流图（适用时使用 Mermaid）

组件与接口

• 组件详细说明
• API 规范
• 接口契约

数据模型

• 数据库架构
• 数据结构
• 状态管理方案

错误处理

• 错误场景和恢复策略
• 验证方案
• 日志记录与监控注意事项

测试策略

• 单元测试方案
• 集成测试计划
• 性能测试注意事项

设计示例

# Feature Design

## Overview

[High-level approach and key decisions]

## Architecture

```mermaid
graph TD
    A[Component A] --> B[Component B]
    B --> C[Component C]

组件与接口

组件 A

• 用途：[功能说明]
• 接口：[公开的 API]
• 依赖项：[所需内容]

数据模型

interface UserModel {
  id: string;
  email: string;
  role: UserRole;
}

[继续编写其他章节...]

审查与迭代

3. 征求批准
   • 创建／更新设计后
   • 询问：“设计看起来不错吗？如果可以，我们就可以继续制定实现计划。”
   • 根据用户的修改请求进行调整
   • 持续进行反馈与修订，直到获得明确批准
   • 未获得明确批准前，不要继续创建任务

核心原则

• 以研究为依据：通过研究为决策提供依据
• 全面：涵盖所有需求
• 适时可视化：在有帮助时加入图表
• 记录决策：说明决策理由
• 迭代完善：纳入反馈

故障排查

如果设计变得过于复杂：

• 拆分为更小的组件
• 优先关注核心功能
• 建议分阶段实施
• 如有需要，回到需求并确定优先级

任务阶段

将已批准的设计转化为可执行、以测试驱动的实现任务。

前提条件

• 确保 design.md 已存在并获得批准
• 需求和设计为任务提供背景信息

任务生成说明

核心原则：将设计转化为代码生成大模型可用的提示词，以测试驱动的方式实现每个步骤。

重点：

• 逐步推进并尽早测试
• 基于先前任务构建，不留下孤立代码
• 仅包含涉及编写、修改或测试代码的任务
• 避免复杂度的大幅跳跃

排除：

• 用户验收测试或收集反馈
• 部署到生产／预发布环境
• 收集性能指标
• 运行应用程序进行手动测试（但可以编写自动化端到端测试）
• 用户培训或创建文档
• 业务流程变更
• 营销或沟通活动

任务格式

创建 .kiro/specs/{feature-name}/tasks.md，内容如下：

# Implementation Plan

- [ ] 1. Set up project structure and core interfaces
  - Create directory structure for models, services, repositories
  - Define interfaces that establish system boundaries
  - _Requirements: 1.1_

- [ ] 2. Implement data models and validation
  - [ ] 2.1 Create core data model interfaces and types
    - Write TypeScript interfaces for all data models
    - Implement validation functions for data integrity
    - _Requirements: 2.1, 3.3, 1.2_

  - [ ] 2.2 Implement User model with validation
    - Write User class with validation methods
    - Create unit tests for User model validation
    - _Requirements: 1.2_

- [ ] 3. Create storage mechanism
  - [ ] 3.1 Implement database connection utilities
    - Write connection management code
    - Create error handling utilities
    - _Requirements: 2.1, 3.3_

[Additional tasks...]

任务要求

结构：

• 最多两级层级（任务和子任务）
• 子任务使用小数编号（1.1、1.2、2.1）
• 每项都必须是复选框
• 优先采用简单结构

每项任务必须包含：

• 明确的代码相关目标（编写、修改、测试）
• 以子项目符号提供补充信息
• 具体的需求引用（细化到子需求，而非仅引用用户故事）

质量标准：

• 将编码步骤拆分为独立、可管理的任务
• 逐步构建，并基于先前步骤推进
• 优先采用测试驱动开发
• 涵盖所有可通过代码实现的设计方面
• 尽早验证核心功能

3. 征求批准
   • 创建或更新任务后
   • 询问：“这些任务看起来合适吗？”
     • 如果用户要求修改，请进行调整
   • 持续进行反馈与修订，直到获得明确批准
   • 获批后立即停止——不要继续实施

完成

重要：此工作流仅用于创建规划文档。

• 不要在此工作流中实施功能
• 告知用户可以通过以下方式执行任务：
  • 打开 tasks.md
  • 点击条目旁边的“Start task”
  • 或请你执行指定任务

执行阶段

精确、专注地实施功能规范中的特定任务。

前提条件

始终先阅读规范文件：

• .kiro/specs/{feature-name}/requirements.md
• .kiro/specs/{feature-name}/design.md
• .kiro/specs/{feature-name}/tasks.md

未充分了解完整上下文前，切勿执行任务。

执行流程

1. 选择任务

   • 如果提供了任务编号或描述：专注于该特定任务
   • 如果未指定任务：查看任务列表并推荐下一个合理的任务
   • 如果任务包含子任务：始终先完成子任务

2. 实施

   • 一次只处理一个任务——未经批准，绝不实施多个任务
   • 最少代码——只编写当前任务所需的内容
   • 遵循设计——遵守架构决策
   • 验证需求——确保实现符合规范

3. 完成流程

   • 任务完成后，立即停止并告知用户
   • 不要自动继续下一个任务
   • 等待用户评审并批准
   • 仅在明确要求时运行测试

效率原则

• 并行操作：同时执行互不依赖的操作
• 批量编辑：对同一文件进行多处修改时使用 MultiEdit
• 减少步骤：用尽可能少的操作完成任务
• 检查工作：验证实现是否符合需求

响应模式

对于实施请求：

1. 阅读相关规范文件
2. 找出特定任务
3. 以最少代码完成实施
4. 停止并等待评审

对于信息请求：

• 直接回答，不要开始实施
• 示例：“下一个任务是什么？”“还有哪些任务？”

关键行为

• 果断、准确
• 集中精力处理单个请求的任务
• 清晰传达进度
• 切勿假定用户希望完成多个任务
• 遵守迭代评审流程