ロードマップと作業日誌
有用な最新計画と追跡可能な意思決定記録を、新しいレイアウトを強制せずに維持します。ユーザーの指示とプロジェクトの規則に従います。既存の名前、識別子、言語、リンク、未コミットの変更、無関係なコンテンツは保持します。新しい計画には、ユーザーが指定した、または合理的に示した言語を使用します。不明な場合は問い合わせます。言語を強制してはいけません。
使用するタイミング
ロードマップ、開発計画、キュー、作業日誌、アイテムステータス、または計画された作業の継続に関するリクエストに使用します。例：「what is next on the roadmap?」、「continue the agreed item」、「дорожная карта」、「план разработки」、「дневник разработки」、「что дальше по плану?」、「продолжай разработку по плану」。リクエストの対象範囲はコンテキストから判断します。ステータスに関する質問は読み取り専用です。
まずは発見
プロジェクトルートを特定し、その指示を読みます。既存のロードマップ、キュー、アイテムノート、引き継ぎドキュメントを見つけます。名前と場所はさまざまです。関連するアイテム、その受け入れ基準、現在のキュー、リンクされたノートを読みます。該当する実装、利用可能なバージョン管理状態、およびリクエストが現在の状態評価を必要とする場合の証拠を確認します。Gitや特定のディレクトリ構成、特定のステータス用語を前提としてはいけません。複数のリポジトリの場合は、既存のリンクに従います。アクセスできない正規の場所については、代わりとなるものを勝手に作らずに尋ねます。
リクエストから暗に示されているモードを選択します：
- 読み取り専用： 関連ドキュメントと証拠から回答します。記録された主張と独立して確認された事実を区別します。編集は行いません。
- 初期化： 計画が存在しない場合、所有者が望む作業方法について話し合い、適切な構造、場所、範囲、初期アイテム、順序付けを提案します。必要に応じてトラック、エージェントロール、初期カードを含めます。より深い調査には、利用可能で適切であれば
grill-meを使用します。存在しない場合はインストールを提案しますが、許可なしにインストールしたり、ワークフローを妨げたりしてはいけません。それ以外の場合は、未解決の選択肢に対する推奨事項を含めて、自分で簡潔で構造化された議論を促進します。ファイルを作成する前に、ユーザーの十分な情報に基づく同意を得ます。優先順位やコミットメントをでっち上げてはいけません。 - 採用： 計画資料がすでに存在する場合は、それをそのまま使用します。所有者が大規模なレビューを要求した場合、初期化時と同じオプションの構造化議論を、未解決の部分に合わせて使用します。新しいファイル、移行、または大規模な書き換えを提案する場合は、説明し、事前に十分な情報に基づく同意を得ます。無言で別の情報源を作成してはいけません。
- 再開： 最新の指示、アクティブなキュー、アイテムノート、関連する現在の状態を読みます。矛盾または古くなった指示は、現在の証拠とユーザーの最新の決定に照らして解決します。重要な矛盾が残っている場合は尋ねます。アイテムがまだ選択または委任されていない場合は、実装前に合意します。保存された計画や文書化の承認は、作業開始の許可ではありません。
- 更新： 要求された範囲の変更を既存の記録に加えます。アイテムのステータス、残作業、影響を受けるキューエントリに一貫性を保ちます。履歴と無関係な順序は保持します。新しいファイルや大規模な書き換えの場合は、提案された変更を説明し、事前に十分な情報に基づく同意を得ます。1つのアイテムに限定されたリクエストは、計画の残りを実装または書き換える権限を与えるものではありません。
記録と調整
プロジェクトの確立された構成を使用します。通常、ロードマップはアイテムとその現在の順序を要約し、日誌は決定事項、発見事項、証拠、履歴を保持します。長い詳細はリンクで繋ぎ、重複を避けます。識別子は安定させます。決定事項やキャンセルされた作業を無言で削除してはいけません。必要に応じて、理由を付けて「置き換え済み」または「キャンセル済み」とマークします。
決定、一時停止、または順序が変更された場合、許可された範囲内で影響を受ける現在の要約と次のステップの指示を更新します。以前の指示は履歴としてラベル付けします。一時停止または延期された計画は、アクティブな継続指示として見えてはいけません。単にメモが追加されたからといって、無関係な作業を再優先してはいけません。必要な修正が許可された範囲外にある場合は、編集範囲を拡大するのではなく、ユーザーにフラグを立てます。
所有者がより広い範囲を許可していない限り、一度に1つのアイテムに取り組み、自動的に次のアイテムを開始してはいけません。完了したサブステージは親アイテムを完了させません。残りを記録します。作業モードは権限や予算とは別にします。継続の許可は、プロダクションアクションや外部書き込みに対する包括的な許可ではありません。記録された完了、保留中のユーザー承認、完全に承認された作業は区別します。引き継ぎ時、決定時、検証結果、ブロッカー時に簡潔なチェックポイントを残し、残っているものと再開方法を含めます。不確かな進行中のアクションは繰り返す前に検証します。共有チェックアウトでの複数ファイル更新の前に、書き込み直前のバージョン管理状態とダーティパスを確認し、新しく読み込んだコンテンツに対して狭い編集を適用し、無関係な作業を保持し、許可がない限りコミットや公開をせずに範囲変更を検証します。
複数のアイテム、エージェント、セッションにまたがる作業、予算がある作業、または所有者がトラックや連続モードを許可した作業については、最初に「長時間実行作業」（references/long-running.md）を読んでください。
ステータスと証拠
プロジェクトのステータス用語を使用します。存在しない場合は、OPEN、IN PROGRESS、BLOCKED、PARTIAL、DONEを提案し、プロジェクトに合意された意味を定義します。ステータスは、意図や委任者の裏付けのない主張ではなく、受け入れ基準と実際の証拠に基づいて記録します。PARTIALの場合は、残っているものとブロッカーを明記します。影響を受けるステータス参照の一貫性を保ちます。
実際に実行したチェック、その結果と範囲、および必要に応じて誰が実行したかを記録します。証拠は過去のものであるか、別の実行者からのものである可能性があります。そのソースと適用可能性をラベル付けし、再実行されたことを暗示してはいけません。後の変更がチェックを無効にする場合は、適切な検証を特定するか実行します。コマンド、結果、テスト数、承認、ユーザー受け入れを決してでっち上げてはいけません。自動テスト、リリースされたコード、ライブ運用は異なる主張です。実装やテストからライブ受け入れを推測してはいけません。必要な受け入れが行われていない場合は、PARTIALまたはプロジェクトの同等の状態を保持し、不足している環境や承認を明記します。
許可された編集の後、影響を受けるステータス、キュー、リンク、証拠と範囲との一貫性を確認します。変更、実際に行ったチェック、未解決のアイテムを報告します。実行しなかった検証を主張してはいけません。
参照
- 汎用テンプレート — プロジェクトに適合させたオプションの開始点。
- シナリオ — モードと範囲の選択に関する簡潔な例。
- 長時間実行作業 — トラック、チェックポイント、一時停止と停止、受け入れ、予算、共有チェックアウト。
- マルチリポジトリ調整 — 作業を保持し、チェックアウト間で記録状態、Git状態、ライブ状態を区別します。