意図駆動開発

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

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

起動タイミング

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

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

動作の仕組み

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

例

簡易キャプチャ — 「ダッシュボードにCSVエクスポートを追加」

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

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

完全受入ブリーフのトリガー — 「ユーザー認証をOAuthに移行」

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

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

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

運用ルール

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

深さの選択

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

簡易キャプチャ

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

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

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

完全受入ブリーフ

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

既存仕様レビュー

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

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

ワークフロー

1. 目標とリスクの確立

以下を抽出または質問します:

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

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

2. コンテキストの発見

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

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

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

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

3. スコープの定義

以下を記述:

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

4. 受入基準の記述

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

該当する各基準には以下を含めます:

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

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

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

以下のカテゴリを検討しますが、該当するカテゴリのみを含めます:

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

6. 提示と続行

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

出力テンプレート

完全受入ブリーフにはこのテンプレートを使用します。簡易キャプチャでは無関係なセクションを省略します。

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

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

## 改訂ログ

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

## 目標

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

## スコープ

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

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

## コンテキスト

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

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

**前提条件**
- <確認または検証する未検証の主張>

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

## リスクレビュー

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

## 受入基準

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

## ブロッキング判断

- [ ] <安全または正しい進行を妨げる判断のみ>

## 検証計画

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

合格/不合格の例

スキルが実際に検証可能なブリーフを作成したかどうかを判断するために使用します。計画的な散文ではありません。

不合格の受入基準

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

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

合格の受入基準

AC-001: エクスポートにより、フィルタリングされたデータを含むCSVファイルがダウンロードされる
- シナリオ: ユーザーが認証され、ダッシュボードに表示されている
- アクション: 「CSVエクスポート」ボタンをクリック
- 期待値: ブラウザがステータス200でファイルをダウンロードし、Content-Typeが text/csv
- 禁止: バックエンドが1秒以上ブロックする、または非表示カラムを含まない
- 検証: 統合テストは curl を使用しステータスコードとContent-Typeをチェック、手動テストでブラウザダウンロードを確認
- 優先度: 必須

合格 — 各要素が観測可能で、検証方法が挙げられ、禁止が明示的です。