daily-task-manager

毎日のタスク管理

契約

このスキルでは、以下を保証します。

• タスクは脳ページ（ops/tasks.md）に構造化された形式で保存され、各タスクに変わらない id が割り当てられます
• タスクのライフサイクル：追加 → 進行中 → 完了 | 延期 | 削除
• 優先度レベル：P0（緊急）、P1（今日）、P2（今週）、P3（バックログ）
• 完了したタスクは完了日とともにアーカイブされ、延期したタスクには目標日と理由が記録されます
• 変更時に、無関係なタスクや不明なセクションが失われることはありません
• すべてのアクションで、以下の構造化された結果を返します（Returns）

戻り値

各アクションの後、呼び出し元（サブエージェントを含む）が確実に連携できるよう、構造化された結果を返します。

{action, task_id, status: ok|not_found|ambiguous|needs_confirmation, priority, date, page: "ops/tasks.md", saved: true|false}

review では、単一の task_id ではなく、グループ化したアクティブなタスクの一覧を返します。「task list json」というトリガーで呼び出された場合は、Markdown ではなく、タスクオブジェクト {id, description, priority, due, status} の JSON 配列を返します。

ツールインターフェース

宣言されたツールのみを使用してください。読み取りには get_page("ops/tasks.md")、書き込みには put_page("ops/tasks.md", …)、監査証跡には add_timeline_entry、相互参照には search を使用します。このスキルから gbrain CLI の動詞をシェルで実行しないでください。ツールがインターフェースです。（ユーザーがエージェントを使わずに手動で実行する場合の CLI 相当コマンドは gbrain get ops/tasks / gbrain put ops/tasks です。あくまで相当コマンドであり、スキルのインターフェースではありません。）

アクションの振り分け

状態を変更する前に、ユーザーの意図を次のとおり確定的に割り当てます。

• 「add / remind me to / put X on my list」→ add
• 「done with X / finished X / completed X / ✅ X」→ complete
• 「push X / defer X / move X to next week」→ defer
• 「delete X / remove X / kill task X」→ remove（明示的な削除を示す語がある場合のみ。削除を推測しないでください）
• 「what are my tasks / task list / what's on my plate (today)」→ review（「today」は P0 と P1 に絞り込みます）

フェーズ

1. 読み込み。 get_page("ops/tasks.md") を実行します。初回実行時： ページが存在しない場合は、出力形式のテンプレートを使って作成してから続行します。
2. 検証。 アクションの振り分けに従ってアクションを決定します。必須フィールドが不足している場合（アクションごとのルールを参照）、状態を変更する前に、簡潔な確認質問を1つだけ行います。優先度、期日、延期理由を捏造してはいけません。
3. 対象タスクの特定（complete/defer/remove）：指定があれば id で照合します。指定がなければ、アクティブなタスクのみを対象に、説明文をあいまい一致で照合します。一致するものがない場合は not_found を返し、変更しません。複数一致する場合は ID と候補を一覧表示し、ambiguous を返して変更しません。
4. 実行：
   • 追加： 説明が必須です。優先度は、ユーザーが明示した、または明確に示唆したレベルを使います。指定がなければ、デフォルトで P3 とし、その旨を返信とタイムラインエントリに記載します。期日は、指定された場合、またはユーザーの発言で明示されている場合のみ設定します。新しいタスク ID（t-YYYYMMDD-NN。NN はその日の次の空き番号）を発行します。タイムラインエントリを追加します。
   • 完了： [x] を付け、(completed: YYYY-MM-DD) を記録して Completed に移動します。
   • 延期： 目標の日付または期間と理由が必須です。不足している場合は確認します。元のテキスト、ID、優先度を保持したまま Deferred に移動します。ただし、ユーザーが変更した場合はその変更を反映します。
   • 削除： 破壊的な操作です。ユーザーのメッセージにすでに明示的な確認が含まれている場合を除き、明示的な確認を求めます。完了または延期を提案することを優先します。
   • 確認： 読み取り専用です。状態は変更しません。アクティブなタスクを優先度ごとにグループ化し、ID を表示します。
5. 保存。 変更を行った後は put_page("ops/tasks.md") を実行します。差分を意識し、影響を受ける行だけを変更してください。このスキルが認識しないセクションも含め、他のすべての内容を保持します。

エッジケース

• 初回実行： ページがない場合は、処理を行う前にテンプレートから作成します。status: ok とし、メモに "initialized" と記載します。
• 不正な形式のページ： ops/tasks.md が存在するもののスキーマに一致しない場合、ページ全体を書き換えてはいけません。内容を最小限に追加・編集し、不明な内容はそのまま保持して、返信で形式の不備を伝えます。
• 再試行／重複追加： 有効なタスクに同一の説明がすでにある場合、重複して追加せず、既存のタスク ID を報告します。
• 日付： すべて ISO 8601（YYYY-MM-DD）を使います。「今日」や「来週」の日付は、推測せずコードや時計で計算します。
• ページ識別子： ツール呼び出しでは常に（拡張子を含む）ops/tasks.md を使います。これが唯一の正規の保存場所です。
• 単一書き込み元を前提とする制約（並行処理の制限）。 タスクの処理サイクルは、読み取り・変更・書き込みです。get_page("ops/tasks.md") → 編集 → put_page("ops/tasks.md") の順に行います。put_page はページ全体を置き換え、比較と交換（compare-and-swap）に対応していないため、2 つの変更が交錯すると後から書き込んだ方が優先されます。2 回目の put_page が 1 回目の変更を上書きし、完了済みのタスクが再表示されたり、追加したタスクが消えたりします。また、t-YYYYMMDD-NN の採番で、並行する 2 つの追加処理に同じ番号が割り当てられ、ID が重複することがあります。タスクの編集は直列化してください。ops/tasks.md に対する複数のタスク変更を並行して実行してはいけません（複数のサブエージェントや、並行するチャットターンなど）。変更が競合する可能性がある場合は、put_page の直前に再度 get_page を実行し、読み取った最新のページから次に使える番号を算出してください。

出力形式

保存済みページの形式

後続の操作で安全に対象を指定できるよう、各タスクには固定 ID を付与します。

# Tasks

## P0 — Urgent
- [ ]  {task description} (due: {date})

## P1 — Today
- [ ]  {task description} (due: {date optional})

## P2 — This Week
- [ ]  {task description} (due: {date optional})

## P3 — Backlog
- [ ]  {task description}

## Deferred
- [ ]  {task description} (deferred until: {date}; reason: {reason})

## Completed
- [x]  {task description} (completed: {date})

ユーザー向けの返信

変更後は、操作、タスク ID、優先度／ステータス、関連する日付、保存できたかどうかを簡潔な 1 行で伝えます。レビューの場合は、有効なタスクを優先度別にまとめます。返信は簡潔にし、横幅の狭いチャット画面では表を避けます。

失敗した場合

gbrain のエラー code、終了コード、[AGENT] ブロック、または通知ブロックがある場合は、エージェント運用者プロトコルに従ってください。このスキル固有の対応は次のとおりです。

• タスクページの更新で revision_conflict が返された場合：ops/tasks.md を再度読み取り、1 件のタスク変更を適用し直して保存します。古い読み取り結果を使ってリスト全体を上書きしてはいけません。
• write_pending（終了コード 10）の場合：保留中のレシートを添えて saved: false と報告し、gbrain write-request <request_id> をポーリングします。タスクが記録されたとユーザーに伝えてはいけません。
• タスク ID が曖昧、または見つからない場合：ambiguous／not_found を返し、どのタスクか尋ねます。最も近い候補を変更してはいけません。

アンチパターン

それぞれに修正方法を示します。

• 優先度を指定せずにタスクを追加する → デフォルトで P3 にし、そのデフォルトを適用したと明言します（黙って適用してはいけません）。
• 曖昧な参照先を変更する → いったん停止し、ID 付きで候補を列挙して確認します。
• 完了日を記載せずに完了扱いにする → 必ず (completed: YYYY-MM-DD) を付けます。
• 目標日と理由を指定せずに延期する → まず両方を尋ねます。
• 明示的な確認なしに削除する → 先に確認します。代わりに完了または延期する方法を提案します。
• ページ全体を上書きする／不明なセクションを削除する → 変更は最小限にとどめます。
• 宣言されていないツールや CLI 動詞を使う → get_page／put_page／search／add_timeline_entry のみを使います。
• 期日、優先度、理由を捏造する → 必須項目を決して作り上げず、確認します。
• リストを際限なく増やす → Backlog が約 20 件を超えたら、週次レビューを促します。
• 脳のページ以外にタスクを保存する → すべてを検索可能な ops/tasks.md に保存します。
• ops/tasks.md に対するタスク変更を並行して実行する → ページ全体を置き換える put_page は後勝ちとなり、更新がひそかに失われたり ID が重複したりします。編集を直列化し、書き込みの直前に再度読み取ります。

設計上の根拠（このバージョンで解消する障害モード）

• インターフェースの不整合： 以前のバージョンでは、get_page／put_pageをツールとして宣言しながら、本文ではCLIの動詞を使うよう指示していたため、モデルはどちらかをランダムに選んでいました。宣言したツールをインターフェースとし、CLIは人間向けの同等機能に関する注記にとどめるよう変更しました。
• 照合できないタスク： タスクIDがない状態で、類似したタスクが2件あるときに「デプロイタスクを完了して」と指示すると、誤ったタスクが気づかれないまま変更されていました。安定した t-YYYYMMDD-NN形式のIDと、曖昧な場合に処理を停止する仕組みによって、この問題を解消します。
• 初回実行時のクラッシュ： ops/tasks.mdが存在する前提により、ページがない場合の動作が未定義になっていました。初回実行時にテンプレートから作成することで、この問題を解消します。
• ページ全体の上書きリスク： 「タスクリストを更新して書き込む」という指示は、同時編集を失わせるページ全体の書き換えを招いていました。最小限の差分を必須とし、不明な内容を保持するルールを設けることで、この問題を解消します。