intent

インテント

インテントは、造船所の内部受付です。サポート／運用スタッフは製品の問題を最初に把握しますが、エンジニアリング仕様を書くことはできません。インテントスキルは、スタッフとの会話を目標レベルの YAML＋Markdown 成果物に変換します。担当者がレビューして署名することで、エンジニアリングチームに曖昧さのないミッションが渡されます。このスキルは検証可能性の境界に立っています。エージェントは質問し、記録し、草案を作成します。人間は提出し、検証し、署名します。

設計の由来：ここでのすべての決定は、wayfinder マップ（7 件のチケット）によって確定され、実装前にデモリポジトリで最初から最後まで実施されました。

役割の契約

• 貢献者（例：サポートスタッフ）は、生のフィードバックやチャットログを貼り付けます。エージェントは事実を決して作り出さず、不明点は明示的な 待确认 項目になります。
• 決定するのは人間です。貢献者は文言を確認し、スーパーバイザーは提出し、プロダクトオーナーは事実を検証して承認／却下に署名します。エージェントが署名することも、誰かに代わって却下することも、レビュー担当者の代わりを務めることもありません。
• 停止ゲートは完了ゲートであり、曖昧さのスコアではありません。deep-interview から計算方法を借りることはありません。品質基準として再利用するのは、Goal と Constraint の明確さの判断のみです。

会話（番号付き一括質問）

1. 初回の棚卸し：問題を一文で言い換えた後、5 つのセクションの棚卸し（セクションごとの既知／不足）を提示します。
2. 番号付き一括質問：不足項目をすべて、番号付きの質問として一括で列挙します。貢献者は番号で回答します（1 是; 2 不确定）。不明な回答は 待确认 として記録し、未解決の質問に加えます。推測を求めて回答を迫ることは決してありません。
3. 再棚卸し：回答を反映します。不足が残っている場合は、次の番号付き質問をまとめて提示します。1 ラウンドは 1 回の一括質問です。
4. 停止ゲート（5 つのセクションすべてが合格する必要があります）：
   • 問題：観察可能な現象であり、解決策が含まれていない
   • 目標：一文で、限定表現がなく、対象と関係を明示している（deep-interview の Goal Clarity 基準）
   • ユーザーとシステム：ユーザーとシステムの実名を記載。不明点は 待确认 と記述し、未解決の質問として数える
   • 制約：境界、制限、対象外事項が明示されている（deep-interview の Constraint Clarity 基準）
   • 未解決の質問：リストが空でないか、明示的に 无 と記載されている
5. ソフトリミット：6 ラウンド目にソフトプロンプトを表示します（「現在の明確さで草案を作成しますか？」）。上限は 12 ラウンドです。早期終了を妨げることは決してありません。情報が薄いセクションは未解決の質問が長くなって表れ、レビューで却下するかどうかを判断します。
6. 草案作成：エージェントは docs/intents/<slug>/intent.md（以下のテンプレート）を status: draft で作成します。提出前に、貢献者が文言を確認します。

intent.md テンプレート

---
intent: <slug>
title: <one-line title>
author: <name (role)>
date: <YYYY-MM-DD>
status: draft | in-review | accepted | rejected
round: <tracker review round>
---

## 问题
<observable phenomena, no solution>

## 目标
one sentence, no qualifiers

## 用户和系统
<who the users are, which systems, real names; unknowns as 待确认>

## 约束
<boundaries, non-goals; cite Rules pillar files when a constraint comes from them>

## 未决问题
- [阻塞|非阻塞] <question>   ← agent suggests, product owner finalizes

未解決の質問の評価

阻塞 の判断基準は、「これに回答しなくても、仕様を承認できるか」です。いいえの場合はブロッキング、はいの場合は非ブロッキング（追跡され、開発に持ち越される場合があります）です。草案作成エージェントが評価案を提示し、プロダクトオーナーが仕様承認時に最終決定します。

レビューへの引き継ぎ（harbor の 4 つの記録）

レビューはリポジトリのトラッカー上で行います。トラッカーのみを記録の情報源とし、intent.md の frontmatter にはステータスのみを反映します。インテントごとに記録ファイルを 1 つ作成し、同じファイル内に各ラウンドの記録を蓄積します。各記録の必須項目：署名者、日付、判定、intent.md へのリンク、ラウンド、却下理由（却下時は必須）。

• 提案 = スーパーバイザーがインテントを提出（intent.md → status: in-review）
• 検証 = プロダクトオーナーが判断前にリポジトリの根拠と照合して事実を確認します。エージェントは事実確認の表の草案を作成できますが、署名するのはレビュー担当者です。確認すべきリポジトリの根拠がない場合は、その確認が不要だった理由を検証記録に残します。
• 決定 = 承認または却下。却下には理由が必要であり、再提出時の重要な入力となります。
• 実行結果 = このインテントの仕様生成が完了したことを示します。

却下 → 修正 → 次のラウンド番号で同じファイルに再提出します。履歴は追跡可能な状態で保持されます。

Launch への引き継ぎ

承認済みのインテント（status: accepted）は、有効なミッションブリーフです。Launch の仕様統合では、次の4段階の契約に従います。

1. docs/intents/<slug>/intent.md を読む（承認済みで、最新ラウンドであること）
2. 既存のコードベースと組み合わせる
3. Rules ピラー（CLAUDE.md + docs/standards/ + docs/business/）に従う
4. すべての疑問点とルールの競合を列挙する — 仕様の確認待ちセクションで評価する

インテントの未解決の質問は、確認待ちのステータスを維持したまま、そのまま仕様に引き継ぎます。

修正

承認後に明らかになった新しい情報（通常は最初の仕様で表面化します）は修正として扱います。誰でも開始でき、提出者が署名し、軽微な変更として免除されることなく、常に新しいラウンドとして完全なレビューに再度入ります。インテントが変更されると、生成済みの仕様は古くなります。新しいインテントに基づいて仕様を再生成し、再承認を受けます。修正専用の記録タイプはなく、ラウンドで扱います。

競合の沈殿

仕様の確認待ちセクションにある競合の結論は、先例に基づいて振り分けます。そのケースに限る回答は仕様に残します。後続のインテントを拘束する結論は Rules ピラーに沈殿させます（ビジネスルールは docs/business/、動作ルールは docs/standards/）。元に戻しにくい技術的なトレードオフは ADR にします。二重に記録してはいけません。アーカイブを先送りしてはいけません。結論を先例とするかどうかはプロダクトオーナーが判断し、保存先はテックリードが助言します。