意図駆動開発

意図駆動開発 は何をしますか？

仕様策定を儀式にすることなく、有用な受入条件を作成します。まず利用可能なコンテキストを調査し、真の曖昧さを露呈させ、作業とそのリスクに適合した検証方法を選択します。

起動条件

• ユーザーが、実装前に機能の明確化、受入条件の定義、または変更のリスク低減を依頼した場合
• リクエストがセキュリティ、認証、永続データ、マイグレーション、外部API、またはコンプライアンスに触れる場合
• ユーザーが別のエージェントやチームへの引き継ぎ成果物を準備したい場合
• リクエストが曖昧で、期待される成果がまだ観測可能またはテスト可能でない場合
• ユーザーが /intent-driven-development で明示的にこのスキルを呼び出した場合

軽微な編集、単純な1行修正、アクティブなデバッグセッション、コードレビューの依頼、または受入条件が既に明確な実装リクエストでは起動しないでください。

仕組み

1. まずコンテキストを調査 — 質問をする前に、リポジトリ、ドキュメント、スキーマ、テストインフラから技術的事実を読み取ります。製品/ビジネス上の制約は、ユーザーまたは製品成果物のみが提供できるものとして扱います。
2. 深さを選択 — リスクプロファイルに基づいて、Quick Capture（3〜7個の基準、低/中リスク）またはFull Acceptance Brief（セキュリティ、データ、マイグレーション、クロスシステム変更）を選択します。
3. 最小限の質問 — 推論できず、かつスコープや動作を実質的に変更する質問のみを行います。
4. 観測可能な基準を記述 — 各AC-NNNは、開始条件、トリガー、期待される結果、禁止される副作用、検証方法、優先度を記述します。「正しく」「安全に」といった証拠のない曖昧な言葉は使いません。
5. 実行または引き継ぎ — 明確なリクエストでブロッキングリスクがない場合は、基準を記録して続行します。リスクのある変更の場合は、ブロッカーを提示し、確認を待ちます。
6. 改訂の処理 — 実装中にアーキテクチャ上の制約でACを満たせなくなった場合、[revised] とマークし、スコープまたは検証方法を更新し、改訂番号をインクリメントして、変更された基準のみを再提示します。

例

Quick Capture — 「ダッシュボードにCSVエクスポートを追加」

目標: 認証済みユーザーがダッシュボードデータをCSVファイルとしてダウンロードできる。
スコープ内: 現在フィルタリングされている行のエクスポート、ファイル名に日付を含む。
スコープ外: スケジュールエクスポート、メール配信、Excel形式。
前提: 最大行数は10k未満、エクスポートフィールドにPIIは含まれない。

AC-001: エクスポートが正しいヘッダーでファイルを生成する
- シナリオ: 認証済みユーザー、少なくとも1つのデータ行が表示されている
- アクション: 「CSVエクスポート」をクリック
- 期待結果: ブラウザが [id, name, created_at] のカラムを持つファイルをダウンロード
- 禁止: 内部フィールドや他のユーザーに属する行を公開しない
- 検証: 自動統合テスト + 手動スキーマスポットチェック
- 優先度: 必須

Full Acceptance Brief トリガー — 「ユーザー認証をOAuthに移行」

認証変更 + 外部依存 + 既存セッションデータ → リスクレビューテーブル、セッション無効化戦略に関するブロッキング決定、明示的なロールバックACを含む完全なブリーフ。

既存仕様のレビュー — ユーザーがPRDを貼り付けた場合

スキルは、スコープの欠落、検証不可能な要件（「システムは高速であること」）、暗黙の前提をレビューし、発見を再開せずに修正または補足の基準を返します。

運用ルール

1. ローカルで発見可能な技術的事実について質問する前に、利用可能なリポジトリ、ドキュメント、課題、デザイン、テストコンテキストを調査すること。
2. 製品やビジネスの制約をコードから推測しないこと。ビジネスルール、コンプライアンスおよび規制上の義務、契約上のSLA、価格設定、データ保持ポリシー、優先順位付け、ターゲットユーザーはリポジトリから読み取れません。ユーザーまたは権威ある製品成果物（PRD、契約、ポリシードキュメント）が提供するまで不明として扱います。それらを確認が必要な前提として記録し、発見された事実として決して扱わないでください。リポジトリは、システムが今日どのように動作するかを示しますが、ビジネスが何を要求するかは示しません。
3. 回答が必要で安全に推論できない質問のみを行うこと。関連する短い質問は、不必要なターンを節約できる場合にグループ化すること。
4. デフォルトで実装をブロックしないこと。ユーザーが十分に明確な変更の実装を依頼した場合、主要な前提と受入条件を簡潔に記録し、その後実行するか、実装ワークフローに引き継ぐこと。
5. 未解決の決定が、重大なセキュリティ露出、データ損失、元に戻せないマイグレーション、契約/APIの破損、意味のあるコスト、または破壊的な外部アクションを生み出す可能性がある場合にのみ、明示的なユーザー確認を要求すること。
6. ユーザーが要求するか、アクティブなリポジトリワークフローが明示的に要求しない限り、受入文書をリポジトリに書き込んだり、プロジェクトファイルを変更したり、ブランチを作成したり、コミットしたり、別のスキルを呼び出したりしないこと。
7. 自動テストを証拠として扱いますが、真実としては扱わないこと。信頼性があり釣り合いが取れている場合は自動化を優先しますが、自動化で結果を確立できない場合は、手動のUX、アクセシビリティ、セキュリティ、リーガル、または運用検証を許可すること。
8. 実際のシークレット、認証情報、トークン、秘密鍵、個人データ、または機密性の高い本番ペイロードを受入条件、フィクスチャ、例、または保存された成果物に決して含めないこと。編集済みまたは合成値を使用すること。
9. 明示的な承認と特定された安全な環境なしに、破壊的なテスト、マイグレーション、セキュリティプローブ、ロードテスト、有料の外部呼び出し、または本番/ライブデータに対する操作を実行しないこと。
10. 実装中に発見されたアーキテクチャ、プラットフォーム、または外部の制約のために受入条件を満たせない場合、黙って削除したり回避したりしないこと。影響を受ける基準を更新し（[revised] とマークし、制約を明記し、スコープまたは検証方法を調整する）、改訂番号をインクリメントし、変更された基準のみをユーザーに再提示してから続行すること。改訂がブロッキング決定を変更したり、安全性や正確性の保証を実質的に低下させたりする場合にのみ、明示的な確認を要求すること。

適切な深さを選択

最小限の有用な出力を使用します。

Quick Capture

明確だが重要ではない、低または中リスクの変更に使用します。以下を作成します：

• 目標
• スコープ内 / スコープ外
• 前提
• 検証方法を含む3〜7個の受入条件
• ブロッキング質問（ある場合）

運用ルールからのブロッキングリスクが存在するか、ユーザーが特に最初に仕様を要求した場合を除き、承認のために実装を遅らせないでください。

Full Acceptance Brief

曖昧、クロスシステム、セキュリティ-sensitive、データ変更、マイグレーション、コンプライアンス、または高コストの変更、またはユーザーが引き継ぎ成果物を要求した場合に使用します。以下の完全なテンプレートを作成し、リスクのある実装の前に未解決のブロッキング決定について確認を要求します。

既存仕様レビュー

ユーザーがすでにPRD、課題、計画、または受入条件を提供している場合：

1. 発見を再開する代わりにそれをレビューします。
2. 欠落しているスコープ境界、安全でない前提、矛盾、検証不可能な要件を特定します。
3. 修正または補足の基準を返します。

ワークフロー

1. 目標とリスクを確立

以下の情報を抽出または質問します：

• ユーザーまたはシステムにとって観測可能な成果。
• 影響を受けるアクター。
• 主な障害の結果。
• 実際に適用されるリスクの次元：セキュリティ/プライバシー、永続データ、互換性/API、マイグレーション、外部依存関係、コスト、並行性、パフォーマンス、ユーザビリティ/アクセシビリティ。

無関係なリスクについて一般的な質問をすることは避けてください。

2. コンテキストを発見

ローカルまたは接続された成果物が利用可能な場合、必要なものだけを調査します：

• 既存の動作と直接関連するファイルまたはインターフェース。
• リポジトリの規約、製品ドキュメント、API契約、データスキーマ、またはマイグレーション履歴。
• 既存の検証インフラストラクチャと現実的なコマンド。
• 外部依存関係と、それらが分離してテスト可能かどうか。

発見された事実は、ユーザーが提供した前提とは別に記録します。コンテキストを調査できない場合は、何が不明かを述べ、焦点を絞った質問をします。

リポジトリは技術的事実（システムが今日どのように動作するか、その規約、契約）を明らかにします。製品やビジネスの制約（ビジネスルール、コンプライアンスおよび規制上の義務、契約上のSLA、価格設定、データ保持ポリシー、優先順位付け、ターゲットユーザー）は明らかにしません。これらをコードや命名から再構築しないでください。ユーザーまたは権威ある製品成果物からのみ取得し、確認が必要な前提としてリストアップしてください。

3. スコープを定義

以下を明記します：

• 目標：意図された成果を表す一文。
• スコープ内：この変更が提供しなければならない動作。
• スコープ外：明示的に除外される、魅力的な隣接作業。
• 前提：まだ証明されていない主張。
• ブロッキング決定：安全性または動作に実質的に影響を与える未解決の選択。

4. 受入条件を記述

AC-001、AC-002 などを使用します。各条件は観測可能な動作と適切な検証方法を記述しなければなりません。条件とテストは1対1でマッピングする必要はありません。

該当する各条件について以下を含めます：

• シナリオまたは開始条件。
• アクションまたはトリガー。
• 期待される観測可能な動作。
• 意味のある場合の禁止される副作用。
• 検証方法：自動テスト、統合チェック、手動UXレビュー、アクセシビリティチェック、セキュリティレビュー、運用チェック、またはステークホルダー承認。
• 検証がデータ、サービス、コスト、またはシークレットに影響を与える可能性がある場合の環境/安全制約。
• 優先度：必須、重要、またはオプション。

「正しく」「安全に」「高速」「直感的」「堅牢」などの言葉は、観測可能な証拠を定義するか、人間によるレビューの判断として記録しない限り使用しないでください。

5. 関連する境界のみをカバー

以下のカテゴリを考慮しますが、該当するカテゴリのみを含めます：

カテゴリ	含める条件	典型的な証拠
ハッピーパス	新規または変更されたユーザー可視動作	成功したワークフローまたは状態遷移
バリデーション	変更が入力を受け付ける	不正な形式または境界値を変更なしで拒否
認証/プライバシー	データまたはアクションにアクセス境界がある	アクセス拒否、機密情報の開示なし
永続化/マイグレーション	保存データまたはスキーマが変更される	後方読み取り、マイグレーション、ロールバックまたはバックアップ動作
互換性	公開API、ファイル、イベント、またはクライアントが壊れる可能性がある	既存の契約またはフィクスチャが有効のまま
障害回復	ネットワーク、サービス、または非同期障害が存在する	部分的な状態がない、または明確なリトライ/縮退動作
冪等性/並行性	繰り返しまたは同時書き込みが発生しうる	重複する副作用や無効な最終状態がない
パフォーマンス	ユーザーまたはサービスのしきい値が重要	定義された測定条件としきい値
UX/アクセシビリティ	人間が結果と対話する	キーボード、フィードバック、エラー回復、ビジュアル/手動レビュー

6. 提示して続行

• 明確化/仕様リクエストの場合、ブリーフを提示し、リストされたブロッカーについてのみ決定を求めます。
• ブロッカーなしの実装リクエストの場合、作業の一部としてコンパクトな基準サマリーを提示し、実装を続行します。
• 別のエージェントまたはチームへの引き継ぎの場合、要件を発明することなく行動できるように十分なコンテキストと検証の詳細を含めます。
• 要求された場合のみ、ブリーフをファイルに保存します。リポジトリで承認されたパスが存在する場合はそれを使用し、それ以外の場合は、書き込む前に選択された保存先を尋ねるか明示します。

出力テンプレート

Full Acceptance Brief にはこのテンプレートを使用します。Quick Capture では無関係なセクションを省略します。

# 受入ブリーフ: <変更名>

**ステータス:** ドラフト | 承認済み | 実装済み | 検証済み
**改訂:** <番号>
**作成対象:** <ユーザー/チーム/エージェント、既知の場合>
**リスク作業前に承認が必要:** はい | いいえ - <理由>

## 改訂ログ

| 改訂 | 日付 | 変更された基準 | 理由 |
| --- | --- | --- | --- |
| 1 | <日付> | — | 初版ドラフト |

## 目標

<観測可能な成果を一文で。>

## スコープ

**スコープ内**
- <含まれる動作>

**スコープ外**
- <除外される隣接作業>

## コンテキスト

**発見された事実**（技術的、リポジトリまたは成果物から検証済み）
- <システムが今日どのように動作するか、規約、契約>

**製品/ビジネス制約**（ユーザーまたは製品成果物から提供され、コードから決して推測されない）
- <ビジネスルール、コンプライアンス/SLA義務、保持ポリシー、優先順位、ターゲットユーザー — または「まだ提供されていない」>

**前提**
- <確認または検証すべき未検証の主張>

**依存関係と制約**
- <外部サービス、ローカル規約、互換性義務、環境制限>

## リスクレビュー

| リスク領域 | 該当? | 必要な対応 |
| --- | --- | --- |
| セキュリティ/プライバシー | はい/いいえ | <編集、認可、レビューなど> |
| 永続データ/マイグレーション | はい/いいえ | <互換性、バックアップ、ロールバックなど> |
| 外部影響/コスト | はい/いいえ | <サンドボックス/テスト環境/認可> |
| 互換性/API | はい/いいえ | <保存またはバージョン管理する契約> |
| UX/アクセシビリティ | はい/いいえ | <手動または自動の証拠> |

## 受入条件

### AC-001: <観測可能な動作>
- **シナリオ:** <開始条件>
- **アクション:** <単一のトリガー>
- **期待結果:** <観測可能な結果>
- **禁止:** <該当する場合、禁止される副作用>
- **検証:** <方法と意図する証拠>
- **環境/安全:** <該当する場合、制約>
- **優先度:** 必須 | 重要 | オプション

## ブロッキング決定

- [ ] <安全または正しい進捗を妨げる決定のみ>

## 検証計画

| 基準 | 検証証拠 | ステータス |
| --- | --- | --- |
| AC-001 | <テスト/チェック/レビューコマンドまたは証拠タイプ> | 保留中 |

合格/不合格例

スキルが実際に検証可能なブリーフを生成したかどうかを判断するために、計画的な散文ではなく、これらを使用します。

不合格の受入条件

AC-001: エクスポートは正しく動作し、安全です。

不合格 — 「正しく動作する」と「安全」は観測可能ではなく、シナリオ、トリガー、期待される結果がありません。

[truncated for translation remains truncated]