project-specification

委任

詳細な仕様書の作成ワークフローでは、このスキルは標準的な実装として spec-kit:spec-writing に委任します。簡易な仕様が必要な場合はこのスキルを使用し、詳細な仕様書が必要な場合は spec-kit を使用してください。

使用するタイミング

• ブレインストーミングのフェーズが完了した後
• プロジェクト概要はあるものの、詳細な要件が必要な場合
• 実装に向けてテスト可能な受け入れ基準が必要な場合
• 検証およびテスト戦略を計画する場合
• ビジネス要件を技術仕様に変換する場合
• スコープの境界と対象外の項目を定義する場合

使用しないタイミング

• まだ課題領域を探索している場合（代わりに Skill(attune:project-brainstorming) を使用してください）
• すでに詳細な仕様がある場合（代わりに Skill(attune:project-planning) を使用してください）
• 既存の実装を改善する場合（コードレビューのスキルを使用してください）
• 戦略的な判断を行う場合（複雑な選択には Skill(attune:war-room) を使用してください）

統合

spec-kit を使用する場合：

• 方法論について Skill(spec-kit:spec-writing) に委任します
• spec-kit のテンプレートと検証を使用します
• 明確化のワークフローを利用できます

spec-kit を使用しない場合：

• 単独で使用できる仕様策定フレームワーク
• 要件テンプレート
• 受け入れ基準のパターン

ドキュメントの対象読者

概要の Doc audience フィールドを仕様書に引き継ぎ、注記ではなく要件として扱ってください。このフィールドによって、プロジェクトの README、ガイド、チュートリアルに含められる内容が決まります。概要に設定されていない場合は、推測せずに質問してください。

最初のドキュメントを作成する前に情報を切り出せるよう、対象読者と併せて詳細説明の掲載先も指定してください。スキルの場合は modules/、リポジトリのドキュメントの場合は docs/deep-dive/<topic>.md を使用します。階層テーブルと削除基準については、scribe:slop-detector モジュールの audience-targeting.md を参照してください。

トレードオフの記録（decision journal）

仕様策定で実質的な選択肢がある設計上の判断（選択したデータモデル、インターフェース境界、受け入れた制約など）が確定した場合は、次に進む前に docs/tradeoffs.md に記録してください（下書きを作成し、確認を得ます）。

• leyline がインストールされている場合は、Skill(leyline:decision-journal) を呼び出してトレードオフの項目（判断内容、比較検討した選択肢、断念した内容）を追記し、phase を specify に設定します。下書きを表示し、確認後に追記してください。
• フォールバック（leyline がない場合）：ファイル内の ENTRY TEMPLATE を使用して docs/tradeoffs.md に追記し、次の TR-NNN ID を割り当てます。

完了後：ワークフローの継続（必須）

自動トリガー：Quality Checks に合格し、docs/specification.md を保存した後、次のフェーズを必ず自動で呼び出してください。

継続を呼び出す場合：

1. docs/specification.md が存在し、空でないことを確認します
2. ユーザーにチェックポイントメッセージを表示します：

   Specification complete. Saved to docs/specification.md.
   Proceeding to planning phase...
   

3. 次のフェーズを呼び出します：

   Skill(attune:project-planning)
   

スキップ条件（次のいずれかに該当する場合に限り、継続をスキップします）：

• ユーザーが --standalone フラグを指定した
• docs/specification.md が存在しない、または空である（フェーズ失敗）
• ユーザーが仕様策定後に停止するよう明示的に求めている

ユーザーに確認を求めないでください：これは軽量なチェックポイントであり、対話型の承認プロセスではありません。必要であれば、ユーザーはいつでも中断できます。

終了条件

• docs/specification.md が存在し、空ではなく、Quality Checks に合格している。
• すべての機能要件にテスト可能な受け入れ基準がある。
• ドキュメントの対象読者の階層が明記されており、概要から引き継がれているか、概要にない場合は確認されている。
• 実質的な選択肢がある設計上の判断は docs/tradeoffs.md に記録されている（または、意味のある設計上の分岐がなかった）。
• スキップ条件に該当しない限り、次のフェーズが自動で呼び出される。

関連スキル

• Skill(spec-kit:spec-writing) - spec-kit の方法論（利用可能な場合）
• Skill(attune:project-brainstorming) - 前のフェーズ
• Skill(attune:project-planning) - 仕様策定後に自動で呼び出される次のフェーズ
• Skill(attune:mission-orchestrator) - ライフサイクル全体のオーケストレーション

関連コマンド

• /attune:specify - このスキルを呼び出す
• /attune:specify --clarify - 明確化のワークフローを実行する
• /attune:blueprint - ワークフローの次のステップ

例

完全な例については、/attune:specify コマンドのドキュメントをご覧ください。