Back to Details

kiro-skill

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Kiro: Spec-Driven Development Workflow

Kiro：Spec驱动的开发工作流

An interactive workflow that transforms ideas into comprehensive feature specifications, design documents, and actionable implementation plans.
一个将想法转化为全面的功能规格说明、设计文档和可执行实施计划的交互式工作流。

Quick Start

快速开始

When you mention creating a feature spec, design document, or implementation plan, this skill helps guide you through:
  1. Requirements → Define what needs to be built (EARS format with user stories)
  2. Design → Determine how to build it (architecture, components, data models)
  3. Tasks → Create actionable implementation steps (test-driven, incremental)
  4. Execute → Implement tasks one at a time
Storage: Creates files in 
.kiro/specs/{feature-name}/
directory (kebab-case naming)
当你提及要创建功能规格说明、设计文档或实施计划时，本技能将引导你完成以下步骤：
  1. 需求阶段 → 定义需要构建的内容（含用户故事的EARS格式）
  2. 设计阶段 → 确定如何构建（架构、组件、数据模型）
  3. 任务阶段 → 创建可执行的实施步骤（测试驱动、增量式）
  4. 执行阶段 → 逐个完成任务
存储：在
.kiro/specs/{feature-name}/
目录下创建文件（使用短横线分隔命名法kebab-case）

When to Use

适用场景

  • Creating a new feature specification
  • Defining requirements with acceptance criteria
  • Designing system architecture
  • Planning feature implementation
  • Executing tasks from a spec
  • 创建新的功能规格说明
  • 定义带有验收标准的需求
  • 设计系统架构
  • 规划功能实施
  • 执行规格说明中的任务

Kiro Identity & Philosophy

Kiro的定位与理念

Read 
helpers/kiro-identity.md
before responding. It defines tone, language preference, and minimal-code philosophy.
If you need visual phase gates or flow references, see 
helpers/workflow-diagrams.md
.
<details> <summary>📋 Phase 1: Requirements Gathering</summary>
在回复前请阅读
helpers/kiro-identity.md
，其中定义了语气、语言偏好和极简代码理念。
如果需要可视化阶段门或流程参考，请查看
helpers/workflow-diagrams.md
。
<details> <summary>📋 阶段1：需求收集</summary>

Requirements Phase

需求阶段

Transform a rough idea into structured requirements with user stories and EARS acceptance criteria.
将初步想法转化为结构化的需求，包含用户故事和EARS验收标准。

Process

流程

  1. Generate Initial Requirements
    • Create 
      .kiro/specs/{feature-name}/requirements.md
    • Use kebab-case for feature name (e.g., "user-authentication")
    • Write initial requirements based on user's idea
    • Don't ask sequential questions first - generate then iterate
  2. Requirements Structure
markdown
undefined
  1. 生成初始需求
    • 创建
      .kiro/specs/{feature-name}/requirements.md
      文件
    • 功能名称使用短横线分隔命名法kebab-case（例如："user-authentication"）
    • 根据用户的想法编写初始需求
    • 不要先逐个提问，先生成内容再迭代优化
  2. 需求结构
markdown
undefined

Requirements Document

需求文档

Introduction

概述

[Feature summary - what problem does this solve?]
[功能概述 - 解决了什么问题？]

Requirements

需求列表

Requirement 1

需求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]
  1. WHEN [事件] THEN [系统] SHALL [响应]
  2. IF [前置条件] THEN [系统] SHALL [响应]
  3. WHEN [事件] AND [条件] THEN [系统] SHALL [响应]

Requirement 2

需求2

User Story: As a [role], I want [feature], so that [benefit]
用户故事：作为一个[角色]，我想要[功能]，以便[收益]

Acceptance Criteria

验收标准

  1. WHEN [event] THEN [system] SHALL [response]
undefined
  1. WHEN [事件] THEN [系统] SHALL [响应]
undefined

EARS Format

EARS格式

Easy Approach to Requirements Syntax - structured acceptance criteria:
  • WHEN [event] THEN [system] SHALL [response]
    - Event-driven
  • IF [condition] THEN [system] SHALL [response]
    - Conditional
  • WHILE [state] [system] SHALL [response]
    - State-driven
  • WHERE [feature] [system] SHALL [response]
    - Ubiquitous
  • [system] SHALL [response]
    - Unconditional
Easy Approach to Requirements Syntax（需求语法简易方法）——结构化验收标准：
  • WHEN [事件] THEN [系统] SHALL [响应]
    - 事件驱动
  • IF [前置条件] THEN [系统] SHALL [响应]
    - 条件触发
  • WHILE [状态] [系统] SHALL [响应]
    - 状态驱动
  • WHERE [功能] [系统] SHALL [响应]
    - 通用场景
  • [系统] SHALL [响应]
    - 无条件要求

Review & Iteration

评审与迭代

  1. Ask for Approval
    • After creating/updating requirements
    • Ask: "Do the requirements look good? If so, we can move on to the design."
    • Make modifications if user requests changes
    • Continue feedback-revision cycle until explicit approval
    • DO NOT proceed to design without clear approval
  1. 请求审批
    • 创建/更新需求后
    • 询问：“需求文档是否符合要求？如果没问题，我们可以进入设计阶段。”
    • 根据用户要求进行修改
    • 持续进行反馈-修订循环，直到获得明确批准
    • 未获得明确批准前，不得进入设计阶段

Best Practices

最佳实践

  • Consider edge cases and technical constraints
  • Focus on user experience and success criteria
  • Suggest areas needing clarification
  • May ask targeted questions about specific aspects
  • Break down complex requirements into smaller pieces
  • 考虑边缘情况和技术约束
  • 关注用户体验和成功标准
  • 提出需要澄清的内容
  • 可针对特定方面提出针对性问题
  • 将复杂需求拆分为更小的模块

Troubleshooting

故障排除

If clarification stalls:
  • Suggest moving to different aspect
  • Provide examples or options
  • Summarize what's established and identify gaps
  • Continue with available information rather than blocking
</details> <details> <summary>🎨 Phase 2: Design Document Creation</summary>
如果澄清过程停滞：
  • 建议转向其他方面
  • 提供示例或选项
  • 总结已确定的内容并指出空白
  • 利用现有信息继续推进，而非停滞不前
</details> <details> <summary>🎨 阶段2：设计文档创建</summary>

Design Phase

设计阶段

Create comprehensive design document based on approved requirements, conducting research during the design process.
基于已批准的需求创建全面的设计文档，在设计过程中开展调研工作。

Prerequisites

前置条件

  • Ensure requirements.md exists at 
    .kiro/specs/{feature-name}/requirements.md
  • Requirements must be approved before design phase
  • 确保
    .kiro/specs/{feature-name}/requirements.md
    文件存在
  • 需求已获得批准方可进入设计阶段

Research Phase

调研阶段

  1. Identify Research Needs
    • What technologies/patterns need investigation?
    • What existing solutions can inform the design?
  2. Conduct Research
    • Use available resources (web search, documentation)
    • Build up context in conversation thread
    • Don't create separate research files
    • Summarize key findings
    • Cite sources with relevant links
  1. 确定调研需求
    • 需要调研哪些技术/模式？
    • 哪些现有解决方案可为设计提供参考？
  2. 开展调研
    • 利用可用资源（网络搜索、文档）
    • 在对话线程中积累上下文信息
    • 不要创建单独的调研文件
    • 总结关键发现
    • 引用相关来源并附上链接

Design Document Structure

设计文档结构

Create 
.kiro/specs/{feature-name}/design.md
with:
Overview
  • High-level description of design approach
  • Key architectural decisions and rationales
Architecture
  • System architecture overview
  • Component relationships
  • Data flow diagrams (use Mermaid when appropriate)
Components and Interfaces
  • Detailed component descriptions
  • API specifications
  • Interface contracts
Data Models
  • Database schemas
  • Data structures
  • State management approach
Error Handling
  • Error scenarios and recovery strategies
  • Validation approaches
  • Logging and monitoring considerations
Testing Strategy
  • Unit testing approach
  • Integration testing plan
  • Performance testing considerations
创建
.kiro/specs/{feature-name}/design.md
文件，包含以下内容：
概述
  • 设计方法的高层描述
  • 关键架构决策及其理由
架构
  • 系统架构概述
  • 组件关系
  • 数据流图（适当情况下使用Mermaid绘制）
组件与接口
  • 详细的组件描述
  • API规格说明
  • 接口契约
数据模型
  • 数据库 schema
  • 数据结构
  • 状态管理方案
错误处理
  • 错误场景与恢复策略
  • 验证方法
  • 日志与监控考虑因素
测试策略
  • 单元测试方法
  • 集成测试计划
  • 性能测试考虑因素

Design Example

设计示例

markdown
undefined
markdown
undefined

Feature Design

功能设计文档

Overview

概述

[High-level approach and key decisions]
[高层设计方法与关键决策]

Architecture

架构

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

Components and Interfaces

组件与接口

Component A

Component A

  • Purpose: [What it does]
  • Interfaces: [APIs it exposes]
  • Dependencies: [What it needs]
  • 用途：[功能描述]
  • 接口：[暴露的API]
  • 依赖：[所需资源]

Data Models

数据模型

typescript
interface UserModel {
  id: string;
  email: string;
  role: UserRole;
}
[Continue with other sections...]
typescript
interface UserModel {
  id: string;
  email: string;
  role: UserRole;
}
[继续其他章节...]

Review & Iteration

评审与迭代

  1. Ask for Approval
    • After creating/updating design
    • Ask: "Does the design look good? If so, we can move on to the implementation plan."
    • Make modifications if user requests changes
    • Continue feedback-revision cycle until explicit approval
    • DO NOT proceed to tasks without clear approval
  1. 请求审批
    • 创建/更新设计文档后
    • 询问：“设计文档是否符合要求？如果没问题，我们可以进入实施计划阶段。”
    • 根据用户要求进行修改
    • 持续进行反馈-修订循环，直到获得明确批准
    • 未获得明确批准前，不得进入任务阶段

Key Principles

核心原则

  • Research-driven: Inform decisions with research
  • Comprehensive: Address all requirements
  • Visual when helpful: Include diagrams
  • Decision documentation: Explain rationales
  • Iterative refinement: Incorporate feedback
  • 调研驱动：基于调研结果做出决策
  • 全面覆盖：满足所有需求
  • 可视化辅助：必要时包含图表
  • 决策留痕：记录决策理由
  • 迭代优化：纳入反馈意见

Troubleshooting

故障排除

If design becomes too complex:
  • Break down into smaller components
  • Focus on core functionality first
  • Suggest phased approach
  • Return to requirements to prioritize if needed
</details> <details> <summary>✅ Phase 3: Implementation Task List</summary>
如果设计过于复杂：
  • 将其拆分为更小的组件
  • 优先关注核心功能
  • 建议采用分阶段方法
  • 必要时回到需求阶段重新排序优先级
</details> <details> <summary>✅ 阶段3：实施任务列表</summary>

Tasks Phase

任务阶段

Convert approved design into actionable, test-driven implementation tasks.
将已批准的设计转化为可执行的、测试驱动的实施任务。

Prerequisites

前置条件

  • Ensure design.md exists and is approved
  • Requirements and design provide context for tasks
  • 确保design.md文件存在且已获得批准
  • 需求和设计文档为任务提供上下文信息

Task Generation Instructions

任务生成说明

Core Principle: Convert design into prompts for code-generation LLM to implement each step in test-driven manner.
Focus:
  • Incremental progress with early testing
  • Build on previous tasks - no orphaned code
  • ONLY tasks involving writing, modifying, or testing code
  • No big jumps in complexity
Exclude:
  • User acceptance testing or feedback gathering
  • Deployment to production/staging
  • Performance metrics gathering
  • Running application for manual testing (but OK to write automated end-to-end tests)
  • User training or documentation creation
  • Business process changes
  • Marketing or communication activities
核心原则：将设计转化为代码生成LLM的提示词，以测试驱动的方式实现每个步骤。
重点：
  • 增量式推进，尽早开展测试
  • 基于已有任务构建，避免孤立代码
  • 仅包含涉及编写、修改或测试代码的任务
  • 避免复杂度大幅跳跃
排除内容：
  • 用户验收测试或反馈收集
  • 部署到生产/预发布环境
  • 性能指标收集
  • 运行应用进行手动测试（但可编写自动化端到端测试）
  • 用户培训或文档创建
  • 业务流程变更
  • 营销或沟通活动

Task Format

任务格式

Create 
.kiro/specs/{feature-name}/tasks.md
with:
markdown
undefined
创建
.kiro/specs/{feature-name}/tasks.md
文件，格式如下：
markdown
undefined

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...]
undefined
  • 1. 搭建项目结构与核心接口
    • 创建models、services、repositories目录结构
    • 定义划分系统边界的接口
    • 对应需求：1.1
  • 2. 实现数据模型与验证逻辑
    • 2.1 创建核心数据模型接口与类型
      • 编写所有数据模型的TypeScript接口
      • 实现数据完整性验证函数
      • 对应需求：2.1, 3.3, 1.2
    • 2.2 实现带验证的User模型
      • 编写包含验证方法的User类
      • 为User模型验证编写单元测试
      • 对应需求：1.2
  • 3. 创建存储机制
    • 3.1 实现数据库连接工具
      • 编写连接管理代码
      • 创建错误处理工具
      • 对应需求：2.1, 3.3
[更多任务...]
undefined

Task Requirements

任务要求

Structure:
  • Maximum two-level hierarchy (tasks and sub-tasks)
  • Use decimal notation for sub-tasks (1.1, 1.2, 2.1)
  • Each item must be a checkbox
  • Simple structure preferred
Each Task Must Include:
  • Clear objective involving code (writing, modifying, testing)
  • Additional info as sub-bullets
  • Specific requirement references (granular sub-requirements, not just user stories)
Quality Standards:
  • Discrete, manageable coding steps
  • Incremental builds on previous steps
  • Test-driven development prioritized
  • Covers all design aspects implementable through code
  • Validates core functionality early
结构：
  • 最多两级层级结构（任务与子任务）
  • 子任务使用十进制编号（1.1, 1.2, 2.1）
  • 每个项必须为复选框
  • 优先采用简洁结构
每个任务必须包含：
  • 明确的代码相关目标（编写、修改或测试）
  • 作为子项目符号的附加信息
  • 特定的需求引用（细化的子需求，而非仅用户故事）
质量标准：
  • 独立、可管理的编码步骤
  • 基于已有步骤增量构建
  • 优先采用测试驱动开发
  • 覆盖所有可通过代码实现的设计内容
  • 尽早验证核心功能

Review & Iteration

评审与迭代

  1. Ask for Approval
    • After creating/updating tasks
    • Ask: "Do the tasks look good?"
      • Make modifications if user requests changes
    • Continue feedback-revision cycle until explicit approval
    • Stop once approved - do not proceed to implementation
  1. 请求审批
    • 创建/更新任务列表后
    • 询问：“任务列表是否符合要求？”
      • 根据用户要求进行修改
    • 持续进行反馈-修订循环，直到获得明确批准
    • 获得批准后即停止——不得进入实施环节

Completion

完成说明

Important: This workflow is ONLY for creating planning artifacts.
  • DO NOT implement the feature as part of this workflow
  • Inform user they can execute tasks by:
    • Opening tasks.md
    • Clicking "Start task" next to items
    • Or asking you to execute specific tasks
</details> <details> <summary>⚙️ Phase 4: Task Execution</summary>
重要提示：本工作流仅用于创建规划文档。
  • 不得作为本工作流的一部分实现功能
  • 告知用户可通过以下方式执行任务：
    • 打开tasks.md文件
    • 点击任务项旁的“Start task”
    • 或要求你执行特定任务
</details> <details> <summary>⚙️ 阶段4：任务执行</summary>

Execute Phase

执行阶段

Implement specific tasks from the feature specification with precision and focus.
精准、专注地实现功能规格说明中的特定任务。

Prerequisites

前置条件

ALWAYS read spec files first:
  • .kiro/specs/{feature-name}/requirements.md
  • .kiro/specs/{feature-name}/design.md
  • .kiro/specs/{feature-name}/tasks.md
Never execute tasks without understanding full context.
务必先阅读规格文件：
  • .kiro/specs/{feature-name}/requirements.md
  • .kiro/specs/{feature-name}/design.md
  • .kiro/specs/{feature-name}/tasks.md
绝不能在未理解完整上下文的情况下执行任务。

Execution Process

执行流程

  1. Task Selection
    • If task number/description provided: Focus on that specific task
    • If no task specified: Review task list and recommend next logical task
    • If task has sub-tasks: Always complete sub-tasks first
  2. Implementation
    • ONE task at a time - Never implement multiple without approval
    • Minimal code - Write only what's necessary for current task
    • Follow the design - Adhere to architecture decisions
    • Verify requirements - Ensure implementation meets specifications
  3. Completion Protocol
    • Once task complete, STOP and inform user
    • DO NOT proceed to next task automatically
    • Wait for user review and approval
    • Only run tests if explicitly requested
  1. 任务选择
    • 如果提供了任务编号/描述：专注于该特定任务
    • 如果未指定任务：查看任务列表并推荐下一个逻辑任务
    • 如果任务包含子任务：务必先完成子任务
  2. 实施过程
    • 一次只执行一个任务——未获批准绝不能同时实现多个任务
    • 极简代码——仅编写当前任务所需的代码
    • 遵循设计——严格遵守架构决策
    • 验证需求——确保实现符合规格说明
  3. 完成流程
    • 任务完成后立即停止并告知用户
    • 不得自动进入下一个任务
    • 等待用户评审与批准
    • 仅在明确要求时运行测试

Efficiency Principles

效率原则

  • Parallel operations: Execute independent operations simultaneously
  • Batch edits: Use MultiEdit for multiple changes to same file
  • Minimize steps: Complete tasks in fewest operations
  • Check your work: Verify implementation meets requirements
  • 并行操作：同时执行独立操作
  • 批量编辑：使用MultiEdit对同一文件进行多处修改
  • 最小步骤：用最少的操作完成任务
  • 自查工作：验证实现是否符合需求

Response Patterns

响应模式

For implementation requests:
  1. Read relevant spec files
  2. Identify the specific task
  3. Implement with minimal code
  4. Stop and await review
For information requests:
  • Answer directly without starting implementation
  • Examples: "What's the next task?", "What tasks are remaining?"
对于实施请求：
  1. 阅读相关规格文件
  2. 确定特定任务
  3. 用极简代码实现
  4. 停止并等待评审
对于信息请求：
  • 直接回答，无需启动实施
  • 示例：“下一个任务是什么？”、“还有哪些任务未完成？”

Key Behaviors

核心行为

  • Be decisive and precise
  • Focus intensely on single requested task
  • Communicate progress clearly
  • Never assume user wants multiple tasks done
  • Respect the iterative review process
</details>
  • 果断且精准
  • 高度专注于单个请求任务
  • 清晰沟通进展
  • 绝不假设用户希望完成多个任务
  • 尊重迭代评审流程
</details>

Workflow Rules

工作流规则

  • Never skip phases - Always progress sequentially
  • Explicit approval required - Get user approval after each document
  • No combined steps - Don't merge multiple phases
  • Iterative refinement - Continue feedback-revision until approved
  • One task at a time - During execution, focus on single task
  • 绝不能跳过阶段——必须按顺序推进
  • 需要明确批准——每个文档完成后需获得用户批准
  • 不得合并步骤——不要合并多个阶段
  • 迭代优化——持续进行反馈-修订直到获得批准
  • 一次一个任务——执行阶段专注于单个任务

Workflow Diagram

工作流图

mermaid
stateDiagram-v2
  [*] --> Requirements

  Requirements --> ReviewReq : Complete
  ReviewReq --> Requirements : Changes
  ReviewReq --> Design : Approved

  Design --> ReviewDesign : Complete
  ReviewDesign --> Design : Changes
  ReviewDesign --> Tasks : Approved

  Tasks --> ReviewTasks : Complete
  ReviewTasks --> Tasks : Changes
  ReviewTasks --> [*] : Approved

  Execute : Execute Single Task
  [*] --> Execute : Task Request
  Execute --> [*] : Complete
mermaid
stateDiagram-v2
  [*] --> Requirements

  Requirements --> ReviewReq : Complete
  ReviewReq --> Requirements : Changes
  ReviewReq --> Design : Approved

  Design --> ReviewDesign : Complete
  ReviewDesign --> Design : Changes
  ReviewDesign --> Tasks : Approved

  Tasks --> ReviewTasks : Complete
  ReviewTasks --> Tasks : Changes
  ReviewTasks --> [*] : Approved

  Execute : Execute Single Task
  [*] --> Execute : Task Request
  Execute --> [*] : Complete

Detection Logic

检测逻辑

Determine current state by checking:
bash
undefined
通过以下方式确定当前状态：
bash
undefined

Check for .kiro directory

检查.kiro目录

if [ -d ".kiro/specs" ]; then

List features

ls .kiro/specs/

For specific feature, check phase

FEATURE="$1" if [ -f ".kiro/specs/$FEATURE/requirements.md" ]; then echo "Requirements exists" fi if [ -f ".kiro/specs/$FEATURE/design.md" ]; then echo "Design exists" fi if [ -f ".kiro/specs/$FEATURE/tasks.md" ]; then echo "Tasks exists - ready for execution" fi fi
undefined
if [ -d ".kiro/specs" ]; then

列出所有功能

ls .kiro/specs/

针对特定功能，检查阶段

FEATURE="$1" if [ -f ".kiro/specs/$FEATURE/requirements.md" ]; then echo "Requirements exists" fi if [ -f ".kiro/specs/$FEATURE/design.md" ]; then echo "Design exists" fi if [ -f ".kiro/specs/$FEATURE/tasks.md" ]; then echo "Tasks exists - ready for execution" fi fi
undefined

Summary

总结

Kiro provides a structured, iterative approach to feature development:
  • Start with requirements (what to build)
  • Progress to design (how to build it)
  • Create tasks (implementation steps)
  • Execute tasks one at a time
Each phase requires explicit user approval before proceeding, ensuring alignment and quality throughout the development process.
Kiro提供了一种结构化的迭代式功能开发方法：
  • 从需求开始（要构建什么）
  • 推进到设计（如何构建）
  • 创建任务（实施步骤）
  • 执行单个任务
每个阶段在进入下一阶段前都需要获得明确的用户批准，确保整个开发过程的一致性与质量。