機能ごとに要件・設計・タスクを書き、承認を得てから作る

## プロジェクト全体の指針と、機能ごとの仕様を分けて持つ 開発ガイダンスを意図的に二つの層へ分けて維持します。プロジェクト指針には、長期的に有効な製品の背景、技術選定、リポジトリ構成、ポリシー、規約を記録します。機能仕様では、範囲を限定した一つの変更を定義し、その要件、設計、タスク、調査、検証証拠を保持します。 機能の作業前に関連するプロジェクト指針を読み込み、安定した制約が変わった時は指針を最新に保ちます。機能固有の判断によってプロジェクト全体のガイダンスが暗黙に書き換わることを決して許してはいけません。有効な仕様を特定して現在のフェーズを明示し、中断後の作業を推測ではなく記録済みの状態から再開できるようにします。 ## まず範囲を調べ、仕様1つか、ロードマップで分けるかを決める 最初に短い調査を行い、アイデア、影響を受けるシステム、依存関係、期待する結果を明確にします。範囲を限定した一つの機能では、単一の仕様を直接立ち上げます。広範な取り組みでは、概要書とロードマップを作成し、作業をまとまりのある複数の仕様へ分け、依存関係を記録して、その関係に基づく段階ごとに実装を計画します。 既存システムを変更する場合は、設計前に現在の実装を調べ、差異、互換性の制約、再利用可能なコンポーネントを記録します。迅速化した進行経路は意図的に選んだ場合に限って使用し、その場合も不可欠な要件、設計、タスク、検証の成果物を作成しなければなりません。 ## 要件・設計・タスクを順に書き、各段階で承認を得る 仕様の各フェーズを次の順序で進めます。 1. 振る舞い、境界、制約、受け入れ条件を定義する、テスト可能な要件を作成します。 2. 要件を設計の根拠として扱う前に、人によるレビューを受けます。 3. 各要件をアーキテクチャ、インターフェース、データフロー、リスク、検証へ対応付ける設計を作成します。 4. 設計をレビューした後、依存関係と完了確認を含む順序付きの実装タスクを導き出します。 5. 意図的な迅速化によって一連の工程全体がすでに承認されている場合を除き、実装前にタスク計画の承認を得ます。 範囲が大きく変わった場合は、古くなった計画へ場当たり的な変更を加えるのではなく、影響を受けるフェーズへ戻り、後続の成果物を再検証します。 ## 承認済みのタスクだけを、全部か指定分かを決めて実装する 承認済みタスクからのみ実装を開始し、実行モードを明示的に選びます。全範囲モードでは、承認済みの計画を自律的に実行し、有用な場合はタスク単位で作業を分担し、結果を統合して独立レビューを受け、最終検証を実行します。選択タスクモードでは、現在の文脈で指定されたタスクだけを実装し、無関係なタスクには手を加えません。 完了済みの作業を後から再検証する必要がある場合は、単独の実装レビューを使用します。一時停止するのは、不可欠な情報、必要な許可、安全上の問題、または範囲を変える判断が不足している場合に限ります。難しいという理由だけで、承認済みのワークフローを放棄してはいけません。 ## 開発用のスキルを使い回し、別の目でレビューを受ける 専門的な開発手順は、一つの明確な開始指示と、必要に応じたテンプレート、例、補助資料を備える再利用可能なスキルとして維持します。スキルは現在のタスクの文脈で動作し、プラットフォーム、権限、タスク範囲が許す場合に限って、範囲を限定した並列調査やレビューを委任できます。 実装上の問題点には反対視点からのレビューを、障害には根本原因を先に特定するデバッグを用い、完了を主張する前に最新の証拠で検証します。タスクに適用される可能性がわずかでもある関連スキルは確認して適用します。見かけ上単純であることは、その安全策が不要である根拠にはなりません。 ## 仕様の状態を更新し続け、新しい検証結果で完了を示す 内部の推論で別の言語を使用していても、仕様の成果物はその仕様に設定された対象言語で作成します。現在のフェーズ、承認済みの成果物、依存関係、完了した作業、残りのタスク、判断待ちの事項を含む状態を、ワークフロー全体を通じて確認できるようにします。 ソースの確認やタスクの完了だけを根拠に成功を主張してはいけません。適用可能な実装検証を実行し、生成された成果物を確認して、完了の記述を現在の証拠へ結び付けます。レビューや実装によって結果が変わった後は仕様と状態を更新し、次のセッションが実態どおりの状態を引き継げるようにします。