kiro-skill

要件フェーズ

大まかなアイデアを、ユーザーストーリーとEARS受け入れ基準を含む構造化された要件へと変換します。

プロセス

1. 初期要件を作成する

   • .kiro/specs/{feature-name}/requirements.md を作成します
   • 機能名にはケバブケースを使用します（例：「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形式

Easy Approach to Requirements Syntax — 構造化された受け入れ基準です。

• 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 に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 が存在し、承認されていることを確認する
• 要件と設計がタスクの背景情報となること

タスク生成の指示

基本原則：設計を、コード生成 LLM が各ステップをテスト駆動で実装するためのプロンプトに変換します。

重視すること：

• 早期テストを取り入れた段階的な進行
• 前のタスクを土台にすること。孤立したコードを作らない
• コードの記述、変更、テストを伴うタスクのみ
• 複雑さを一気に大きく増やさない

除外すること：

• ユーザー受け入れテストやフィードバックの収集
• 本番環境またはステージング環境へのデプロイ
• パフォーマンス指標の収集
• 手動テストのためのアプリケーションの実行（自動化されたエンドツーエンドテストの作成は可）
• ユーザートレーニングやドキュメントの作成
• ビジネスプロセスの変更
• マーケティングやコミュニケーション活動

タスクの形式

.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...]

タスクの要件

構成：

• 階層は最大 2 段階（タスクとサブタスク）
• サブタスクには小数表記を使用する（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. 実装

   • 一度に 1 つのタスクのみ — 承認なしに複数のタスクを実装してはいけません
   • 最小限のコード — 現在のタスクに必要なものだけを記述します
   • 設計に従う — アーキテクチャ上の決定を順守します
   • 要件を検証する — 実装が仕様を満たしていることを確認します

3. 完了手順

   • タスクが完了したら、停止してユーザーに伝えます
   • 自動的に次のタスクへ進んではいけません
   • ユーザーのレビューと承認を待ちます
   • 明示的に依頼された場合にのみテストを実行します

効率化の原則

• 並列操作：独立した操作を同時に実行します
• 編集の一括処理：同じファイルに複数の変更を加える場合は MultiEdit を使用します
• 手順の最小化：最少の操作でタスクを完了します
• 作業の確認：実装が要件を満たしていることを検証します

回答パターン

実装の依頼の場合：

1. 関連する仕様ファイルを読む
2. 特定のタスクを特定する
3. 必要最小限のコードで実装する
4. 停止してレビューを待つ

情報の依頼の場合：

• 実装を開始せず、直接回答します
• 例：「次のタスクは何ですか？」「残っているタスクは何ですか？」

主な動作

• 断固かつ正確に対応します
• 依頼された 1 つのタスクに集中します
• 進捗を明確に伝えます
• ユーザーが複数のタスクの実行を望んでいると決めつけません
• 段階的なレビューのプロセスを尊重します