define-vision

スキル：ビジョンを定義する

目的

ビジョンを定義し、記録します。ビジョンとは、プロジェクトが実現を目指す長期的な未来です。ビジョンステートメントは「私たちはどのような未来を築いているのか？」に答え、ミッションと一致します。指標、目標、マイルストーンは定義しません。

ビジョンと異なるもの：

• ミッション：プロジェクトが存在する根本的な目的（define-mission を使用）。
• ノーススター：価値の提供を表す単一の指標（define-north-star を使用）。
• 戦略目標：ビジョンを実現するための 3–5 個の成果（design-strategic-goals を使用）。
• マイルストーン：実行におけるフェーズごとのチェックポイント（define-roadmap を使用）。

---

中核目標

最優先の目標：ミッションと一致し、ユーザーの承認を得たビジョンステートメントを作成し、プロジェクトで合意されたパスに永続化します。

成功基準（すべて満たす必要があります）：

1. ✅ ビジョンステートメントがある：望ましい未来の状態のみを記述した 1～3 文（指標、OKR、ロードマップを含まない）。
2. ✅ ミッションと一致している：ビジョンがミッションと矛盾していないこと。ミッションがない場合は、まず define-mission を実行するよう提案するか、想定する目的を明示します。
3. ✅ ユーザーが承認している：ユーザーが明確に承認している（例：「承認しました」「よさそうです」「続けてください」または同等の表現）。
4. ✅ ドキュメントが永続化されている：合意されたパスに書き込まれている（デフォルトは docs/project-overview/vision.md またはプロジェクトの規約に従います）。
5. ✅ 範囲を守っている：ノーススター指標、戦略目標、マイルストーンを定義していない。
6. ✅ YAGNI/DRY/簡潔さ：spec §4 のドキュメント成果物の原則に従います。ビジョンステートメントを中心に据え、不要な任意の段落（例：ミッションとの整合性や期間の明示的な説明）は避けます。

受け入れテスト：読者は、プロジェクトがどのような長期的な未来を実現しようとしているのかを理解し、それがミッションと一致していることを確認できますか？

引き継ぎポイント：ビジョンの承認と永続化の後、define-north-star または design-strategic-goals に引き継ぎます。ビジョンだけを求められている場合は終了します。

---

範囲の境界

このスキルが行うこと

• プロジェクトまたは製品が目指す長期的な未来の状態を明確にします。
• ビジョンステートメントを作成します（1～3 文）。
• ミッションとの一致を確認します（define-mission の出力または既存のドキュメントからミッションを読み取ります）。
• プロジェクトで合意されたパスに永続化します（デフォルトは docs/project-overview/vision.md）。

このスキルが行わないこと

• 根本的な目的を定義する（define-mission を使用）。
• ノーススター指標または戦略目標を定義する（define-north-star、design-strategic-goals を使用）。
• マイルストーンを定義する（define-roadmap を使用）。
• ロードマップ、要件、またはタスクを書く（capture-work-items などを使用）。

---

ビジョンの品質ガイドライン

優れたビジョンステートメントには、次の要素が必要です。

• 簡潔：1～3 文で未来の状態に焦点を当てます。
• ミッションとの一致：ミッションの根本的な目的を支え、新たな目的を持ち込みません。
• 想像しやすい：2–5 年後の成功を描き、読者が具体的な情景を思い浮かべられます。
• 指標がない：KPI、OKR、数値目標を含めません。指標は define-north-star または design-strategic-goals で扱います。

ビジョンでは、次の要素を避けます。

• 実装の詳細：技術、成果物、または「どのように」実現するか。
• 流行語：未来の状態を明確にできない曖昧な用語。

---

使用例

• ミッションの完了後：「私たちが存在する理由」を明確にした後、「私たちが築く未来」を定義します。
• 戦略や方向性の見直し：長期目標に向けてチームの方向性を再調整します。
• ロードマップに目的がない場合：ロードマップと目標を一致させるため、明確なビジョンを作成します。
• 戦略チェーンの第 2 層：完全な階層構造を構築する場合、define-mission の後に実行します。

---

動作

対話方針

• デフォルト：プロジェクト規約で定められた出力パス（docs/ARTIFACT_NORMS.md または .ai-cortex/artifact-norms.yaml）を使用します。それがない場合は docs/project-overview/vision.md を使用します。docs/project-overview/mission.md またはユーザーからミッションを推測します。
• 候補の選択肢：実現可能な未来が複数ある場合は、候補となるステートメントを 1～3 個提示し、ユーザーに選択または改善を求めます。
• 確認：既存のビジョンファイルを上書きする前、および最終的に永続化する前に確認します。ミッションがない場合は、目的を想定してよいか確認するか、まず define-mission を実行するよう提案します。

実行手順

1. ミッションを読み込む：docs/project-overview/mission.md またはユーザーが提示した要約からミッションを読み取ります。
2. 引き出す：2–5 年後の「成功」とはどのような状態ですか？ユーザーのためにどのような世界を作っていますか？
3. 草案を作成する：ビジョンステートメント（1～3 文）。指標や KPI を含めず、未来の状態のみを記述します。
4. 整合性を確認する：ビジョンがミッションを支えていることを確認します。必要に応じてユーザーと一緒に改善します。
5. 永続化する：プロジェクトで合意されたパスに書き込みます。存在しない場合は docs/project-overview/ を作成します。

---

入力と出力

入力：

• 必須：ミッション（ミッションドキュメントの内容またはパス）。プロジェクト／製品の背景。
• 任意：既存のビジョン草案、期間、対象者。

出力：

• 成果物：ビジョンステートメント（1～3 文）。
• 場所：docs/project-overview/vision.md（またはプロジェクト規約に従います）。
• 内容：ビジョンステートメント。任意（YAGNI：本当に必要な場合のみ）で「ミッションとの一致」「期間」の説明。
• ライフサイクル：継続的に更新します（戦略の方向性が変わったときに更新）。

---

制約

厳守する境界

• ビジョンステートメントにノーススター指標、戦略目標、OKR、マイルストーンを含めないでください。
• ユーザーの明確な承認なく、既存のビジョンファイルを上書きしないでください。
• 複数のビジョンドキュメントを作成しないでください。このスキルで作成するのはビジョン成果物のみです。
• YAGNI：ビジョンドキュメントではステートメントを中心に据え、不要な任意の段落を追加しないでください。

スキルの境界（重複を避ける）

次の作業は行わないでください（別のスキルが担当します）：

• ミッション：根本的な目的 → define-mission を使用
• ノーススター指標：単一の主要指標 → define-north-star を使用
• 戦略目標：3–5 個の成果 → design-strategic-goals を使用
• マイルストーン：フェーズごとのチェックポイント → define-roadmap を使用
• ロードマップ、要件、またはタスク → capture-work-items などを使用

停止して引き継ぐタイミング：

• ユーザーが「承認しました」または同等の表現をした場合 → ビジョンの作成を完了し、define-north-star または design-strategic-goals に引き継ぎます
• ユーザーが「指標」または「ノーススター」を求めた場合 → define-north-star に引き継ぎます
• ユーザーが目標またはマイルストーンについて尋ねた場合 → design-strategic-goals または define-roadmap に引き継ぎます

---

セルフチェック

中核となる成功基準（すべて満たす必要があります）

• ビジョンステートメントがある：未来の状態のみを記述した 1～3 文（指標、目標、マイルストーンを含まない）。
• ミッションと一致している：ミッションと矛盾していない。または、ミッションがないことを明示し、ユーザーの確認を得ている。
• ユーザーが承認している：ユーザーが「承認しました」「よさそうです」「続けてください」または同様の表現をしている。
• ドキュメントが永続化されている：合意されたパス（デフォルトは docs/project-overview/vision.md またはプロジェクト規約）に書き込まれている。
• 範囲を守っている：ステートメントにノーススター、目標、マイルストーンが含まれていない。
• YAGNI/DRY/簡潔さ：spec §4 のドキュメント成果物の原則に従っている。

プロセスの品質確認

• ミッションを使用している：ビジョンの草案を作成する前に、ミッションを読んだか、提示を求めたか？
• 未来の状態のみ：指標や OKR を混在させていないか？
• 品質ガイドライン：ビジョンの品質ガイドライン（簡潔さ、ミッションとの一致、想像しやすさ、流行語がないこと）を適用したか？
• ドキュメント成果物の原則：YAGNI、DRY、簡潔さ（spec §4）に従っているか？

受け入れテスト

読者は、プロジェクトがどのような長期的な未来を実現しようとしているのかを理解し、それがミッションを支えていることを確認できますか？

いいえの場合：ビジョンが不完全か、ミッションとずれています。ミッションに沿って内容を練り直し、再確認してください。 はいの場合：ビジョンは完成です。引き継ぐか、終了してください。

---

例

例 1：ミッションがすでにある場合にビジョンを定義する

背景：ミッションは「エンジニアリングチームが、コードから本番環境へサービスをデプロイするための、信頼できる単一の方法を提供するために存在します」です。ユーザーはビジョンの定義を求めています。

手順：2–5 年後の目標について聞き出します。たとえば「すべてのチームがワンクリックだけで、包括的な監査とロールバック機能を備え、5 分以内に本番環境へデプロイできる」などです。ビジョンの草案を作成し、ミッションを支えているか確認します。ユーザーの承認を得ます。docs/project-overview/vision.md に書き込みます。

結果：ビジョンが永続化され、define-north-star（たとえば「5 分以内に成功した週あたりのデプロイ数」）または design-strategic-goals に引き継ぎます。

示例 2：使命尚未定义（边界场景）

背景：用户要求「定义我们的愿景」，但不存在使命文档。

流程：询问是否从 README 或上下文中假定目的，或建议先运行 define-mission。若用户同意继续，在愿景文档中注明假定目的；起草愿景并与用户确认。持久化；建议稍后补充使命以完善战略链。

结果：愿景持久化，附可选「假定目的」注释；用户可稍后运行 define-mission 完成链。