mcpField
W
workmap

workmap

github.com/wkentaroエージェントワークフロー038 回インストール4 日前に更新
リポジトリ

workmap について

進行中の会話を、アイデア、プロジェクト、タスク、未解決の質問からなるワークマップに整理するスキルです。既存の ToDo、ファイル、トラッカーを変更せずに作業を把握できます。

主な機能

  1. 01会話に基づく作業ツリー
  2. 02プロジェクトとタスクの依存関係
  3. 03タスクのステータス表示
  4. 04作業の分割と再描画
  5. 05維持されるノード ID

活用シーン

  1. 01現在のセッション作業の整理
  2. 02目標をプロジェクトタスクに分割
  3. 03未解決の判断事項と障害の確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/wkentaro/agent-skills --skill workmap

インストール後、Claude Code で/workmapを入力して読み込まれたか確認します。

同梱ファイルagents/openai.yaml

詳細

Workmap

アクティブな会話の作業をワークマップとして描画します。アイデア、そのプロジェクト、およびそれらのタスクと質問を、ひとつのツリーにまとめます。ワークマップは会話だけをもとに作成するビューです。描画しても、作業内容、ネイティブの ToDo、ファイル、トラッカーは変更されません。

ノード

  • アイデア:セッションの中心となる問題または目標を一行で表します。
  • プロジェクト:一行で完了条件を示すひとつの目標です。同じ階層の他のプロジェクトとは相互に独立しています。
  • タスク:レビュー可能なひとつの変更です。コードリポジトリでは、ひとつの PR にあたります。
  • 質問:まだ決定または解決されていない判断事項や不明点です。

これらは、リポジトリのドメインでプロジェクトやタスクと呼ばれているものにかかわらず、マッピング対象の作業単位を指します。

ツリーには作業の順序も示されます。

  • プロジェクト内のタスクは、記載順に積み重なるスタックを形成します。各タスクはリスト内のひとつ上のタスクを土台とし、それぞれがひとつの PR となり、各 PR は前の PR をベースにします(GitHub の gh stack)。スタックに属さないタスクには ∥ を付けます。
  • プロジェクトはそれぞれ独自のワークツリーで並行して進みます。別のプロジェクトを待つプロジェクトには after P1 のように記載します。
  • touches: はプロジェクトが変更する領域を示します。領域が不明な間は省略します。同じ領域に影響するプロジェクトは相互に独立していません。統合するか、after で順序を指定してください。

どのプロジェクトにも属さないノードは Loose の下に置きます。プロジェクトがないセッションでは、すべてのノードが Loose の下に置かれます。

分割

「プロジェクトに分割」または「タスクに分割」と指示されたら、その階層だけを分割して描き直します。新しいノードは、ユーザーが承認するまで [proposed] とします。最新の明示的なユーザーの決定を優先します。ユーザーは会話を通じてワークマップを編集します。変更のたびに描き直してください。

範囲

アクティブなスレッドのみを使用します。継承したコンテキスト、親の会話、または別の会話のコンテキストは、ユーザーが明示的に取り込まない限り、解釈のためのコンテキストとして扱い、ノードにはしません。

以下を含めます。

  • 明示的な依頼と、承認されたアクション。
  • 開始または完了した作業。
  • 約束したことと、結果に影響する未回答の質問。
  • 検討中の重要な選択、ブロッカー、先送りされたフォローアップ。
  • 具体的なアシスタントの推奨事項を、実行可能なノードにまとめたもの。
  • 結果に影響する、却下または置き換えられた選択肢。

以下は除外します。機械的なツール操作、細かなブレインストーミング、説明用の例、アクションや決定を伴わない事実、親ノードですでに表されている完了済みの下位ステップ、および重複項目。

ステータス

各タスクと質問には、固定の絵文字とテキストを付けて表示します。

  • ✅ [done]:目に見える証拠、またはユーザーによる明示的な確認をもって完了しています。
  • 🔄 [in-progress]:開始済みですが、未完了です。作業が中断されている場合は Interrupted at: を追加し、このステータスを維持します。
  • ⏳ [pending]:合意済みで実行可能ですが、未着手です。
  • 💬 [discussing]:判断または方針が未解決です。
  • ⛔ [blocked]:入力、アクセス権、または外部の出来事を待っています。
  • ⏸️ [deferred]:条件が整うまで意図的に保留されています。条件がわかっている場合は Resume when: を追加します。
  • 💡 [proposed]:具体的に提案されていますが、承認されていません。
  • 🚫 [cancelled]:却下、置き換え、または不要になっています。必要に応じて Reason: を追加します。

タスクのステータスだけではプロジェクトの状態が示されない場合(分割前の [proposed] プロジェクトなど)に限り、プロジェクトにもステータスを表示します。

ID

プロジェクトは P1、P2、タスクは T1、T2、質問は Q1、Q2 とします。各系列の番号はワークマップ全体で共通です。タスクが別のプロジェクトに移動しても、ID は変わりません。後続の描画では、インライン表示でも全体表示でも ID を再利用し、新しいノードには次の未使用番号を割り当て、廃止した番号は再利用しません。以前のワークマップが要約によって表示されなくなった場合は、ID の継続性を保証できないことを明記します。

描画

各ノードは一行で記載します。依存関係、ブロッカー、担当者、中断箇所、再開条件、または重要な根拠を省略すると見えなくなる場合に限り、インデントした補足を一行追加します。担当者の責任が曖昧な場合、またはエージェント以外が担当する場合に限り、担当者を表示します。各プロジェクトのタスクはスタック順に、その他のノードは検討順に並べます。

インライン

議論では、返信が扱うノードだけを描き、その周囲に議論を記述します。タイトル、Outcome so far、Next move は省略し、本文ではノードを ID で参照します。あるノードについての説明は、そのノードの直下に配置します。

P2 Sidebar clears the home indicator        after P1
├─ 💡 [proposed] T4 safe-area foot
│    could fold into T2: same file, ten lines
└─ 💬 [discussing] Q1 pad the foot or the whole sidebar?
全体

ユーザーがスキル名を指定して呼び出したとき、またはセッションの状況を尋ねたときは、次の形式で workmap を描きます。セクション間には空行を 1 行入れ、隣接するノード間には空行を入れません。

Workmap — <idea>

Outcome so far
<one-sentence outcome summary>

P1 <goal>                                   touches: <area>
├─ ✅ [done] T1 <change> (#<PR>)
├─ 🔄 [in-progress] T2 <change> (#<PR>)
└─ ⏳ [pending] T3 <change>
P2 <goal>                                   touches: <area>   after P1
├─ ⏳ [pending] T4 <change>
├─ ⏳ [pending] T5 <change>  ∥
└─ 💬 [discussing] Q1 <open decision>
💡 [proposed] P3 <goal>
Loose
└─ ⏸️ [deferred] T6 <change>
     Resume when: <condition>

Next move
<one-sentence recommendation, by ID>

リクエスト

スキル名の後に続く言葉は、ユーザーが何を見たいかを示しています。その要望に応える全体の workmap を描きます。何も指定されていない場合は、現時点の workmap 全体を描きます。

  • 積み上げられた PR など、完了までの計画の場合は、まず残作業をタスクに分けてから、各プロジェクトのスタック全体を描きます。[done] のタスクも含めます。
  • 残作業や決定事項のみなど、より限定的な依頼の場合は、該当するノードだけを各プロジェクト行の下に描きます。

コメント