project-context

プロジェクトコンテキスト

目的

後続のセッションで状態を再構築せずに作業を再開できるよう、永続的なリポジトリのコンテキストを通常のファイルに保持します。

再開、引き継ぎ、長期にわたる作業、サブエージェントへのフォローアップ、再利用可能な参照コンテキスト、またはタスクログには、このスキルを使用します。読み取り専用の質問や一度限りの確認には、初期設定しないでください。リポジトリに既存のコンテキスト文書があるものの、プロジェクトコンテキストのレイアウトがない場合は、並行するツリーを作成する前に、明示的に採用するか、project-context-migration を使用してください。

契約

docs/
  reference/**/*.md
  tasks/yyyy/mm-dd/<task-slug>/
    BRIEF.md
    logs/{DECISIONS,WORKLOG}.md
    [optional] <purpose-named-backlog>.md
    [optional] working/
    [optional] archive/
  [optional] BACKLOG.md

• docs/reference/** には、再利用可能な最新のルールと信頼できる事実を保存します。調査履歴、進捗、時系列、コード一覧、出所に関する説明は含めないでください。内容を言い換えるのではなく、権威あるコード、API、設定、テスト、またはプロジェクト文書を参照してください。訂正や削除の依頼があった場合は、古くなった主張を書き換えるか削除してください。
• BRIEF.md は、書き換え専用の再開カードです。安定した目標、スコープの境界、現在の結論と状態、そして最も近い再開可能なステップを記載します。報告書、履歴、証拠ログ、ファイル一覧、バックログではありません。フェーズの境界では、新しい再開状態に書き換え、以前の証拠や時系列はログ、working/、または archive/ に移します。
• logs/WORKLOG.md には、意味のある一連の作業が完了するたびに、簡潔な結果を1件記録します。コマンドや細かな反復は記録しません。logs/DECISIONS.md には、今後の解釈、スコープ、アーキテクチャ、ロールバック、またはルールの適用方法を変える決定のみを記録します。記録する決定が生じるまでは、DECISIONS.md を空のままにしてください。正確なブロック形式は、同梱のログヘルパーに任せてください。
• タスクルートには、現在の正本となる文書とルーターを置きます。永続的な人間可読の草案、調査メモ、未決定の計画、方法、簡潔な証拠の要約は working/ に置きます。完了、却下、置き換え済み、または古くなったコンテキストは archive/ に置きます。
• 破棄可能な実験やブラウザーテストのコード、状態、未加工の出力は、リポジトリ外の隔離されたワークスペースに置き、確認後に破棄します。保持するコードと証拠は、それぞれ通常の管理場所に置きます。
• 最も近いステップが1つだけでは不十分な場合に限り、目的別のタスクバックログを使用します。リポジトリレベルの作業のうち、現在は行っていないものは docs/BACKLOG.md に記載します。

タスクの識別と共有オーナーシップ

• 未解決の作業と期待される成果が引き続き一致する場合にのみ、既存のタスクを再利用します。話題が似ていることや古い境界メモがあることは、同じタスクである根拠にはなりません。判断に迷う場合は、新しい日付付きタスクを作成します。
• 複数のタスク、オーナー、またはフェーズが、実装や受け入れ基準を変える解釈に依存する場合は、現在の正本となるオーナーを1つ割り当てます。既存のコード、API、設定、テスト、またはプロジェクト文書のオーナーを優先してください。それ以外の場合、タスク固有の意味には目的別のタスクルート契約を、再利用可能な意味には docs/reference/** を使用します。
• 利用者はそのオーナーを参照し、タスク固有の状態、相違点、次のアクションのみを保持します。同じ未完了の作業をブリーフ、バックログ、作業メモ、ログに重複して記録しないでください。

運用と検証

作業を始める前に、ブリーフの目標、現在の状態、再開地点を照合します。現在の状態から目標が達成済みだと確認できた場合は、選択したタスクを完了として閉じ、隣接する次のステップは、ユーザーまたは承認済みの正式な計画で選択されるまで候補のままにしておきます。

まずブリーフを読み、作業に必要な参照情報またはログのコンテキストだけを確認します。一致する未完了のタスクを再利用するか、主要ファイルを含めた日付付きのタスクを作成します。判断をほとんど要さず、すぐに完了する小規模な変更に限り、新しいタスクの作成を省略します。追加の項目は、担当者または読み手が異なる場合にのみ加えます。

ブリーフと正規ログの書き手を1人に定めます。他のエージェントがこれらを記述できるのは、明示的に範囲を限定して割り当てられた場合のみです。リポジトリ相対パスまたは安定したプレースホルダーを使用し、シークレットを保存しません。作業を委任する際は、現在の目標、制約、不明点、証拠を得るコマンド、成果物のパス、必要な正規ポインターだけを渡します。

コンテキストが不足している場合は、明示した仮定のもとで、元に戻せる形で作業を進めます。権限を変更したり、後戻りしにくい決定をしたりする前には確認を求めます。

同梱のログヘルパーと実行時の構成チェッカーを使用します。正確な処理手順は各スクリプトに従います。通常の完了または引き継ぎでは、スキルの相対パスを使って scripts/check_runtime_shape.py --task-root docs/tasks/yyyy/mm-dd/<task-slug> を実行します。タスクのパスは、検出されたリポジトリまたは明示的な --repo-root からの相対パスです。リポジトリ全体の監査または移行チェックでは --task-root を省略します。チェッカーは、必須の構成、最新のログブロック、移植可能なパス、シークレットらしき記述を確認します。担当範囲、意味上の品質、履歴全体、移行の正確性は確認しません。タスクを継続管理する場合は、ブリーフから作業を再開でき、現在のコンテキストの担当者が1人に明確に定まっていることを確認してから完了とします。