Communitygithub.com

JetBrains/thinkrail

軽量リアルIDEでπとともに行うVibeコーディング - 必要なVibe

thinkrail とは?

このスキル「Chat TODO plan」は、AIアシスタントとユーザーが協調してタスクを管理するための、セッション単位のTODOリスト仕組みです。主な目的は、チャット内の会話スコープに限定したタスク計画をリアルタイムで共有・維持することにあります。グループ(ユーザーの依頼1つ=1タスク)とその中のステップ(項目)で構成され、各ステップにはタイトル、ステータス(pending→in_progress→done)、オプションのノートを含みます。グループのステータスは自動的にステップから導出されます。ユーザーがUIから追加した「ルーズアイテム(ユーザーレーン)」は常にプランの末尾に表示され、AIは現在の作業を優先し、完了後にそれらを処理します。本スキルは、ユーザーがAIの作業中に自由に編集できる共有・ライブリストを提供し、AIはtodo_listツールで常に最新の状態を読み取り、todo_write/todo_add/todo_update/todo_removeツールを適切に使い分けて更新します。対応プラットフォームは特に限定されず、AIエージェントとテキストインターフェースでの協働を想定しています。

対応~Claude Code~Codex CLI~Cursor
npx skills add JetBrains/thinkrail

お気に入りのAIに質問する

このエージェントスキルを事前に読み込んだ状態で新しいチャットを開きます。

ドキュメント

Chat TODO 計画

これは何か

  • このチャットにスコープされた計画 — 会話のタスク一覧。ユーザーにはTodoパネルに表示され、セッションと共に存在します(リポジトリにはコミットされません)。
  • グループ=タスク、アイテム=ステップ。 ユーザーの1リクエスト=1グループ。そのタイトルはプロセスではなく成果(「ログインリダイレクトを修正」)です。内部のステップがアイテムです — 各アイテムはタイトル、ステータス(pending → in_progress → done)、およびオプションのノート(完了条件をそこに記載、例:「ログインE2Eがグリーン」)を持ちます。タスク自体のステータスは保存されず、ステップから導出されます。
  • ルーズアイテム(Loose items)はユーザーレーンであり、プランの末尾に配置されます。 これらはユーザーがUIから追加したもので、あなたはそれらを実行しますが、グループ化、書き換え、削除は行いません。todo_listはそれらをすべてのグループの最後に意図的にレンダリングします。つまり、タスク途中でユーザーが追加したリクエストは、現在の作業の後にキューイングされます。よって、現在のタスクを完了(または再開)してからルーズアイテムに取り掛かってください — 新しく追加されたユーザーアイテムに飛びついて、進行中のステップを放棄しないでください。ルーズアイテムはあなたが作成するものではありません(ツールにはgroupまたはafterアンカーが必要)。小さな依頼は小さなグループ(1〜2ステップでOK)、またはリストなしで構いません。
  • 共有かつライブ:あなたが管理し、ユーザーは作業中に編集します — タスクの追加、不要になったものの削除。保存されたリストが信頼できる情報源です。あなたが記憶しているのはスナップショットに過ぎません。同期を保つには**todo_listで再読み込み**してください。
  • ユーザーのステータスウィンドウ — チャットを読まなくても一目で何が進行中か把握するためのもの。短く具体的なステップタイトル、常に最新のステータス。

粒度

リクエストのサイズプラン上の形
些細なもの(回答、1つの編集)リストなし
1〜7ステップ1グループ(小さな依頼=1〜2ステップのグループでOK)
約10ステップ以上それらはステップではなくタスク — 複数のグループに分割

ステップは検証可能で、コミットサイズ程度:「進めながらチェックしやすい」もの。「フェーズ1」ではありません。

操作方法

  1. まず計画を提案 — それがリストの目的です。 複数ステップが必要なリクエストを理解した瞬間、最初のアクションは**todo_write**で提案プランを作成すること — 1タスク1グループ、内部にステップ — 明確化の質問をする前、作業を開始する前に実施してください。その後、詳細が判明したらその場で調整します。(一発回答にはリストは不要です。)
  2. タスクは厳密に順番通り、一度に1ステップずつ作業:
    • ステップを開始するときはin_progressに、完了したらdoneに設定。新しいステップを開始すると、他のin_progressステップは自動的にpendingに戻ります — なので、次に進む前には完了(doneとマーク)してください。そうしないと前のステップが未完了に戻って見えます。
    • 現在のグループに未完了のステップがある間は、次のグループを開始しないでください。唯一の例外は、本当にブロックされたタスク — その理由をステップのnoteに記録し、ユーザーに伝えてから次のグループに進んでください。
    • 次の各ステップの前に、再度todo_listを実行。 ユーザーが作業中に編集した可能性があります:新しいもの(ユーザーレーンの末尾に追記されています — 現在のステップの後に取り上げ、進行中の作業を横取りしないでください)を確認し、計画にあったが消えているアイテムがあれば、ユーザーが削除したものです — スキップし、再追加しないでください。
    • ツールの結果が役立ちます:done後にはタスクの次のステップを提示し、何もin_progressでないときは現在のステップをフリップするよう促します。これらのナッジに従って行動してください。
  3. セッション中に新しい依頼が来たら = 新しいグループを追加(todo_addでgroup:を使い、1ステップずつ追加、または複数のtodo_add呼び出しで新しいタスクのステップを並べる)。新しい依頼のステップを現在のグループに混ぜないでください。タスク途中で発見したステップは、todo_add after: <現在のステップID>でスロットイン(自分のステップの1つにアンカー — ユーザーのアイテムにアンカーすることは拒否されます。なぜならあなたのアイテムは決してユーザーレーンに入らないからです)— そのためにtodo_writeで計画を再構築しないでください。
  4. 終了前に調整。 ターンの終わりに、もう一度todo_listを実行してください。未完了のステップ(ユーザーが追加したばかりのアイテムを含む)が残っている場合、それらを実行するか、何が残っていてなぜかを明確に伝えてください — 新しいアイテムに手を付けずに静かにアイドル状態にならないでください。

不変条件

  • 完了は残る。 ステップ完了 = todo_update → done。完了したアイテムは絶対に削除しないでください — それはユーザーの履歴です。todo_removeはユーザーが明示的に削除を依頼した場合のみ使用します。
  • 手術的に編集する。 最初の計画以降は、todo_update / todo_addを使用(1アイテムに触れる)。既存のリストを微調整するためにtodo_writeを使ってはいけません — すべてを置き換えてしまいます。todo_writeは新鮮な計画をレイアウトするためだけに使用します。
  • ユーザーの編集を尊重する。 リストは共有です。彼らの追加は新しいリクエストとして、削除はキャンセルとして扱います。ルーズアイテムはユーザーのものです — 実行しますが、再計画時に書き換えたり削除したりしません。(todo_writeはユーザーアイテムと完了アイテムを保持してくれますが、それに頼らないでください — 編集にはtodo_add/todo_updateを使用し、todo_writeは本当に新しい計画のために取っておいてください。)

ツール

  • todo_list — 現在の計画を読み取る(信頼できる情報源;ユーザーの編集をキャッチするために再読み取り)。
  • todo_add — 1つのステップを追加(group内、または既存のステップafter;残りはそのまま)。
  • todo_update — 1つのステップを進める(開始時はin_progress、完了時はdone;完了は残る)。
  • todo_remove — 1つのアイテムを削除(ユーザーが要求した場合のみ)。
  • todo_write — 新しい計画をレイアウト(グループのみ — タスクごとに1グループ;開いているアイテムを置き換える;最初の一度だけ使用)。

関連スキル