progress

進捗

ユーザーが $progress を明示的に呼び出した場合、または確立済みの永続的な目標契約により、継続、再開、コンパクション、引き継ぎの際に $progress による復旧が必要な場合に、このスキルを実行します。通常の計画依頼から後者を推測してはいけません。計画システムは手動で選択されたプロジェクトの記憶として扱い、それを当てにする前に、直接の指示とリポジトリの証拠と照合してください。目標モードでは、独立した2つの真実を保ちます。プロジェクトキューはプロジェクトが次に行うべきことを示し、目標契約は現在の実行で許可されている操作を示します。

依頼によって、複数のフェーズが許可される場合があります。各フェーズを完了して検証した後、次に許可された操作をこのエントリーポイントから再度ディスパッチしてください。実行の前に、目標の権限を復旧してください。計画のみのフェーズによって、実装や納品の権限が与えられることはありません。

作業システムを解決する

1. 該当する AGENTS.md ファイルを読み、git の状態を確認します。
2. ファイルを選ぶ前に、計画の対象範囲を判断します。ユーザーが指定した対象範囲またはインデックスを使用します。並行ワークツリーで作業中の場合は、並行ワークツリーのワークフローから、現在のワークツリー専用の名前空間を選びます。それ以外の場合は、通常のスコープなし名前空間を使用します。
3. 作業を選ぶ前に、リクエストを分類します。
   • 明示的な goal mode、提示された Goal contract、または指定された目標状態のパスがある場合は、目標の実行を選びます。
   • 現在の作業を続行、再開、実装、引き継ぎ、開始、または完了することは、実行に影響する作業です。
   • 実装前に、ロードマップ、今後の実装、または提案された計画についてユーザーに説明または相談する場合は、計画レビューを選びます。
   • プロジェクトのキューだけを案内、監査、記録、並べ替え、スケジュール設定、またはその他の方法で編集する場合は、プロジェクトプレーンの作業です。
   • アクティブな目標には触れずに別のプロジェクト作業を行うよう明示されている場合は、通常のプロジェクトモードを選びます。「続行」という依頼だけから、この上書きを推測してはいけません。
4. 解決した対象範囲の慣例的な goals/ パスを調べ、スキーマに適合する目標状態を確認します。目標に関する任意のプロジェクト文書は対象外です。暗黙的な復旧には、Status: active、一致する Planning scope、および Outcome から Delivery までの必須フィールドをすべて含み、そのファイルを示す Goal state パスが記載された Original contract ブロックが必要です。明示的な目標モードまたはパス指定で不正な状態が見つかった場合は、安全側に倒して処理を停止します。それ以外の場合は、スキーマに適合しないファイルを振り分けの対象から除外します。明示的な目標実行の場合、または実行に影響するリクエストに対して復旧可能なアクティブな目標が1つある場合は、目標オーバーレイを有効にします。プロジェクトプレーンのみの作業と、明示的な別作業への上書きの場合は無効のままにします。これらの経路ではキューを正確な状態に保つことはできますが、目標作業を暗黙に開始することはできません。計画のみのリクエストが実装に発展した場合は、最初の実装作業の前に再度振り分けを行います。目標モードでは、候補作業を選ぶ前に目標の契約と目標の実行の両方を読みます。
5. その対象範囲内で、作業キューモデルに合致する既存のインデックスを使用します。通常の作業では ROADMAP.md を、並行作業では対象範囲に限定されたロードマップを優先します。PLAN.md を使用するのは、プロジェクト作業への経路が明確に示されている場合に限ります。単独のレガシー進捗文書しかない場合は、別のワークフローで利用する前に、organize ブランチの明示的な移行が必要であることを報告します。
6. 選択したインデックスを読みます。目標モードでは、プロジェクト項目の内容を開く前に目標ファイルを復旧し、終端条件を検証します。作業が残っている場合は、目標状態における対象範囲内の現在または次の成果を選び、契約とインデックスのメタデータに基づいて分類してから、ワークフローに必要な許可済みの作業項目ファイルだけを読みます。プロジェクトの Current は、含まれる成果の特定や照合には役立つことがありますが、それを選ぶ根拠にはなりません。対象範囲外であることを確認するだけなら、外部の項目リンクを開く必要はありません。
7. 状態に関する重要な主張を検証するために必要な範囲でのみ、最近の履歴、コード、テスト、または差分を確認します。矛盾は文書による制約として扱うのではなく、報告または修正が必要な古さとして扱います。

プロジェクトの現在および次の作業が特定され、該当する場合は目標の現在および次の作業も別途把握され、文書とリポジトリの状態との重大な矛盾が判明した時点で、解決は完了です。

認可とプロジェクトの順序を分離する

• ロードマップ、Current リンク、順序付きの計画、タスク、ブランチ、PR、レビューでの指摘、または新たに作成された計画によって、進行中の目標に作業が追加されることはありません。
• 目標モードでは、新しい計画、作業ブランチ、PR、レビューの取り組み、または個別にレビュー可能な成果物に着手する前に、その候補が永続的な目標の契約に沿っているか確認してください。
• 明示的に含まれている作業と、含まれている完了条件を満たすために必要な最小限の範囲の作業を許可してください。有効な契約に明示的に記録されている意思決定権限に従ってください。役立つ範囲外の作業は、後で取り組めるよう記録してください。その権限でカバーされていない曖昧な作業や、範囲を大幅に拡大する作業については、事前に確認してください。
• 含まれている最後の条件が満たされたら、両方の真実の記録面を更新し、目標を完了してから、次のプロジェクト項目を確認せずに終了してください。
• 目標の契約を正確に復元できない場合は、フェイルクローズしてください。プロジェクトのキューからスコープを推測したり、会話の断片から権限を再構築したりしないでください。

計画は作成時に一貫性を保つ

progress ワークフローで計画を作成する場合、または意図する成果、動作、アーキテクチャ、互換性、移行、ロールアウト、受け入れ条件を実質的に変更する場合は、 End-state planning を読み、作成前に適用してください。確定済みの目標を再構成し、過去の残存要素を取り除き、実際に必要な義務とその完了条件を維持したうえで、同じ操作内で一貫性のある計画を1つ作成してください。編集後に別途レビューコマンドを実行したり、ユーザーにもう一度依頼してもらったりする必要が生じないようにしてください。

計画済みの最終状態を変えない通常の証拠更新、次のアクションの更新、キューの並べ替え、ライフサイクルの移行、誤字修正には、このゲートは適用されません。適用される場合は、ユーザーの指示とリポジトリの証拠から判断できない、根幹に関わるプロダクト上または外部契約上の決定についてのみ確認してください。選択されたワークフローの既存の変更権限と目標に関する権限を守ってください。一貫性のレビューによって、編集や実装が許可される範囲が広がることはありません。

スコープごとに作業キューを1つだけ保つ

• 各インデックスは簡潔に保ち、Current スロット、順序付きの Plans キュー、順序なしの Tasks プールを設けてください。
• 通常の作業では、インデックスを ROADMAP.md、予定された作業を plans/<stable-slug>.md、未予定の作業を tasks/<stable-slug>.md に保存してください。既存の todo/ または todos/ ディレクトリがある場合は、重複する形式を作らず、それをタスクプールとして維持してください。
• 並行するワークツリー作業では、同時に編集する各ワークツリーにそれぞれ異なるロードマップと、別々の計画・タスク用サブディレクトリを割り当ててください。並行ワークツリーのワークフローに定められた命名規則と所有権のルールを適用してください。
• 計画の順序は、選択したインデックスにのみ記録してください。ファイル名と項目ファイルには連番を付けないでください。
• スコープ内の有効な項目はすべて、現在、キュー内、またはプール内のいずれかに一度だけ記載してください。Current にある項目は、現在の項目でなくなるまで、以前のリストには記載しないでください。
• 各項目ファイルを、その Outcome、Current state、Next action の情報源としてください。スコープ、チェックリスト、決定事項、検証内容は、継続するうえで役立つ場合にのみ追加してください。
• 完了時には、結果を項目に記録し、項目を有効なインデックスから削除し、リストから外したファイルを簡潔な履歴として残してください。

ワークフローを選択する

ゴールの実行は条件付きの承認レイヤーであり、プロジェクトの作業管理に取って代わるものではありません。ゴールモードが有効で、リクエストがプロジェクト作業のレビュー、変更、または実装を行う場合は、ゴールのリソースに加えて、以下から主要なワークフローを正確に 1 つ読みます。リクエストがゴールの状態の初期化、復旧、修正、または完了のみを行う場合は、ゴールのワークフローだけで十分です。

• 作業を整理する — システムを初期化し、項目の記録、開始、並べ替え、スケジュール設定、スケジュール解除、または完了を行います。
• 作業の状況を把握する — リポジトリを変更せずに、現在の作業、次の作業、ブロック中の作業、または古くなった作業を報告します。
• 計画済みの作業を説明する — 次に行う作業と計画の記述方法を説明し、ユーザーが意図に沿っているか判断できるようにします。重要なレビュー事項を提示し、明示的に承認された計画の変更のみを適用します。
• 作業を続行する — 項目を現在の状態に保ちながら、まとまりのある実質的な作業範囲を 1 つ選択して実装します。
• 作業を引き継ぐ — 実装を行わず、現在のセッションを永続的な項目と次のアクションにまとめます。

ユーザーが実際に複数の git worktree を調整している場合は、並列 worktree も読みます。この例外は通常の実行では適用しません。

一貫性を保って完了する

変更を伴うワークフローを終了する前に、変更した各インデックス内のすべてのパスが存在すること、各アクティブ項目がそのスコープ内に正確に 1 回だけ現れること、計画の番号に連続性があること、変更した各項目に証拠に基づく現在の状態と具体的な次のアクションが記載されていることを検証します。新規作成または大幅に改訂した計画については、フォローアップのレビュー実行を必要とせず、記述された目標が計画の最終状態ゲートを通過していることも検証します。並行作業中は、現在の worktree が自身の計画名前空間のみを変更したことも検証します。トランスクリプトや日常的なセッションログはファイルに含めません。ゴールモードでは、明示的に記録された修正を除き、元の契約が変更されていないこと、ステータスがスコープ内の次の作業のみを示していること、完了によってプロジェクトのキューの次の項目が開始されていないことも検証します。変更した計画ファイル、実施した検証、スコープ内の次のアクション、完了、またはブロッカーを報告します。