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 に 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 を開く
  • 項目の横にある「タスクを開始」をクリックする
  • または、特定のタスクを実行するよう依頼する

実行フェーズ

機能仕様書の具体的なタスクを、正確かつ集中的に実装します。

前提条件

必ず仕様ファイルを先に読んでください。

• .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. 作業を停止し、確認を待つ

情報を求められた場合：

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

主な動作

• 迷わず、正確に対応します
• 依頼された単一のタスクに集中します
• 進捗を明確に伝えます
• ユーザーが複数のタスクの実行を望んでいると決めつけてはいけません
• 反復的なレビューのプロセスを尊重します