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
  • 点击各项旁边的“开始任务”
  • 或请你执行特定任务

执行阶段

精准、专注地实现功能规格中的特定任务。

前提条件

务必先阅读规格文件：

• .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. 停止并等待审核

对于信息请求：

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

关键行为

• 果断、精准
• 全心专注于单个请求的任务
• 清晰地传达进度
• 切勿假设用户希望完成多个任务
• 遵循迭代审核流程