eliteforge-task-progress-tracker

タスク進捗トラッカー

目標

具体的な要件ごとに、選択したタスクディレクトリ内に Markdown のタスクファイルを 1 つ作成し、作業の進捗に応じて更新します。既定のディレクトリは docs/tasks/ です。 タスクファイルは、中断後に作業を再開するための基準点でもあります。意味のある変更を行うたびに Git コミットを作成し、関連するステップのメモにコミット ID を記録してください。

このスキルを使う場面

• ユーザーが、コーディングの前にエージェントに計画を立ててほしい場合。
• ユーザーが、TODO、現在のステータス、進捗をリポジトリに保存してほしい場合。
• エージェントの作業中にタスクの状態を更新し続けるようユーザーが求める場合。
• ユーザーが、中断後に作業を再開できるようにしたい場合。

ファイルのルール

• 既定のディレクトリ：docs/tasks/
• ユーザーまたは別の有効なスキルが明示的なタスクディレクトリを指定した場合は、そのディレクトリを指定どおりに使用し、docs/tasks/ に重複ファイルを作成しないでください。
• 既知の上書き設定：$eliteforge-google-stitch-onboarding が有効な場合は、トラッカーファイルを docs/tasks/google-stitch-onboarding/ に配置します。
• ファイル名：<task-description>.md
• task-description は、要件を短くまとめたケバブケースにしてください。
• task-description には ASCII 文字を優先してください。リクエストが中国語の場合は、短い英語のスラッグに変換してください。
• ユーザーが明示的に求めない限り、-status-process、-task、-todo などの固定サフィックスを追加しないでください。
• 一致するタスクファイルがすでにある場合は、重複して作成せず、そのファイルを更新してください。
• 無関係なタスクファイルを上書きしないでください。
• タスクファイルの内容は、実際の Git チェックポイントの状態と一致していなければなりません。

使用可能なステータス値

• notrun
• running
• waiting_human_decision（人間の判断待ち：現時点での検討は完了しており、人間から判断が示されるまで作業を停止する状態）
• finished
• cancel

Git チェックポイントのルール

• 意味のある変更はそれぞれチェックポイントとして扱います。次の変更に進む前に、git commit を作成してください。
• コミットが作成されたら、各ステップのメモに最新の関連コミット ID を commit: abc1234 のような短い形式で記録してください。
• 1 つのステップで複数のコミットを作成した場合は、commits: abc1234, def5678 のように作成順に追記してください。
• タスクファイルを更新する前に、互いに無関係な編集を複数、未コミットのまま残さないでください。
• すでに作成したコミット ID を記録するだけのタスクファイル更新は、それ自体で新たなステップのチェックポイントにはなりません。次の作業コミットに含めるか、タスク終了時に最後の記録用コミットとして作成してください。
• ワークスペースが Git リポジトリでない場合、またはコミットを作成できない場合は、現在のステップのメモと更新ログに問題を記録し、それ以上、復元できない変更を続ける前にユーザーへ伝えてください。
• 中断した作業を再開する場合は、最新の該当するタスクファイルを読み、関連するステップのメモに記録された最新のコミット ID を特定して、そのコミットを作業再開の基準点として使用してください。

ワークフロー

1. 実質的な作業を始める前に、次の内容を含むタスクファイルを作成または更新します。
   • 要件の概要
   • 完了条件
   • ステップ一覧
   • 初期状態の status: notrun
   • 初期状態の process: 0%
   • コミット ID を記録できるように準備したステップの注記
2. 実際の実行を開始したら、ただちに次の内容を更新します。
   • status: running
   • process: 5%
   • 最初に着手するステップを current_step に設定
   • チェックポイントから復旧できるよう、ワークスペースで Git コミットを作成できることを確認
3. 意味のあるマイルストーンを達成するたびに、同じファイルを更新します。
   • 受け入れ基準のチェックボックスと既存のタスクチェックボックス
   • ステップのステータス
   • current_step
   • process
   • 簡潔な進捗ログのエントリー
   • コミット作成後、その関連コミット ID を記録します。記録内容は次の作業コミット、または最後の記録用コミットで反映します。
4. 最終回答の前に、ファイルを最後に一度更新します。
   • 正常に完了した場合：status: finished、process: 100%、意味のある変更をすべてコミットし、完了した受け入れ基準をすべてチェック済みにする
   • 人による判断が必要な場合：status: waiting_human_decision、process は現在の意味のある進捗率のままにし、必要な判断内容をアクティブなステップの注記と更新ログに正確に記録する
   • ユーザーがタスクを停止または中断した場合：status: cancel
5. タスクが中断された場合は、次の手順で再開します。
   • 選択したタスクディレクトリ内にある、最新の該当タスクファイルを読む
   • current_step、最新のステップ注記、最新の更新ログエントリーを確認する
   • 状態を推測せず、最後に記録されたコミット ID から続行する

進捗ルール

• process は 5%、35%、100% のようなパーセント形式にします。
• 進捗は単調に増加させ、ユーザーが明示的にスコープを変更しない限り、減少させないでください。
• 実際のマイルストーンを反映する増分を優先し、根拠のない細かな進捗率を設定しないでください。
• 実装と検証が実際に完了するまで、100% にしないでください。

必須テンプレート

リポジトリに既存のより優れた規約がない場合は、次の構成を使用してください。

# Task: <title>

## Requirement
<short requirement summary>

## Acceptance Criteria
- [ ] <condition 1>
- [ ] <condition 2>

## Overall Status
- status: notrun
- process: 0%
- current_step: not started

## Steps
| step | description | status | note |
| --- | --- | --- | --- |
| 1 | <step 1> | notrun | commit: pending |
| 2 | <step 2> | notrun | commit: pending |

## Update Log
| time | status | process | update |
| --- | --- | --- | --- |
| <timestamp> | notrun | 0% | task initialized |

更新ルール

• ステップ一覧を TODO リストとして扱います。別の場所に独立した TODO セクションを設けないでください。
• Markdown のチェックボックスは静的なテキストではなく、現在の状態を示すものとして扱います。基準や TODO を実際に完了したら、同じ更新サイクル内で [ ] を [x] に変更してください。
• 作業が一部のみ完了している場合、またはまだ検証されていない場合は、チェックボックスを未チェックのままにし、残っている作業をステップ注記または更新ログに記載してください。
• スコープ変更やリグレッションによって、完了済みの項目が無効になった場合は、該当項目を [ ] に戻し、その理由を更新ログに記録してください。
• 成功を報告する前に、チェックボックスの状態が実際の実装および検証状況と一致していることを確認してください。完了済みの項目を未チェックのままにしないでください。
• current_step は常に ## Steps のいずれかの行、または completed と一致させてください。
• ステップが finished になったら、ユーザーがチェックポイント前に明示的に停止した場合を除き、その注記に少なくとも 1 つのコミット ID を記録してください。
• 既存のステップにコミットを追加した場合は、ステップ注記と更新ログを更新し、コミット情報が古いままにならないようにしてください。
• 既存のコミット ID を記録するだけの事務的なタスクファイル編集では、新たなステップを追加する必要はありません。次に可能なコミットで確実に反映してください。
• スコープが変わった場合は、作業を続ける前に ## Requirement、## Acceptance Criteria、## Steps を更新してください。
• 技術的な問題で作業が妨げられた場合は、status: running のままにし、問題の内容をステップ注記と更新ログに記録してください。
• 分析が完了し、次のアクションに人の選択が必要な場合は、status: waiting_human_decision に設定し、必要な判断内容を正確に記録して、ユーザーが判断するまでそれ以上の作業を停止してください。
• 中断からの復旧に備え、最新のステップ注記と更新ログエントリーには、次のエージェントが続行すべき作業と、続行元となるコミットを記録してください。
• エントリーは簡潔かつ事実に即した内容にしてください。

応答の動作

• 役立つ場合は、作業中の更新または最終応答でタスクファイルのパスに言及します。
• 既存のタスクの続行を依頼された場合は、まず選択されたタスクディレクトリを検索し、該当する最新のファイルと、そこに記録された最新のコミット ID から作業を再開します。
• Git リポジトリ外で作業した場合、またはコミットを作成できなかった場合は、その制約を応答で明示します。