mcpField
S
session-flow

session-flow

github.com/yeachan-heoエージェントワークフロー40.4k61 回インストール1 日前に更新
リポジトリ

session-flow について

session-flowは、セッション切り替えやコンテキスト圧縮後の再把握を支援するスキルです。会話の根拠に基づいて目標、段階、判断、次の手順を整理し、全体表示・短縮表示・リセットのモードを備えています。

主な機能

  1. 01会話の根拠から段階を再構成
  2. 02完了・予定・中止した作業を区別
  3. 03全体・短縮・リセットの各モード
  4. 04識別用マーカー付きタスクを管理

活用シーン

  1. 01セッション切り替え後の状況把握
  2. 02コンテキスト圧縮後の作業再開
  3. 03ユーザーの判断待ち事項の確認

インストール

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

$npx skills add https://github.com/yeachan-heo/oh-my-claudecode --skill session-flow

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

詳細

セッションの流れ

この会話が実際にどのように進んだかを、証拠に基づく簡潔なマップとして作成します。これにより、セッションの切り替えや圧縮の後にユーザーが状況を把握し直せます。これは参考用の要約であり、プランナー、実行役、またはユーザーのタスクリストの代替ではありません。

モード

  • 引数なし:全体のマップを表示し、ネイティブの Task ツールが利用可能な場合は、セッションフローの Tasks を照合します。
  • short:目標、現在の段階、ユーザーに確認が必要なこと(あれば)のみを返します。読み取り専用です。Tasks は変更しません。
  • reset:このスキルが所有する Tasks のみを特定して削除し、削除したものを確認します。新しいマップは表示しません。

ワークフロー

  1. この会話のユーザーメッセージとツールの結果から、経緯を再構成します。リポジトリの状態だけを根拠に、ある段階が実施されたと判断してはいけません。当初の目標、明示的な目標変更、方向転換、完了した結果、中止した方針、ユーザーの判断待ちの項目を区別します。
  2. 履歴から判断できる場合は、意味のある段階を4~8個作成します。履歴が少ない場合は、内容を水増ししたり、作業を捏造したりせず、段階を減らします。各段階には、次の状態を1つ割り当てます。
    • ✅ 会話で裏付けられる結果を伴って完了
    • ▶ 現在進行中の未完了段階
    • ○ 明示的に計画されているが、未着手の段階
    • ✂ 明示された理由により中止
    • ↪ 以前の方向性と、証拠で裏付けられた新しい方向性を示す方向転換
  3. 各段階に、簡潔な根拠を1つ示します。会話に実際の URL や成果物のパスがある場合は、それを使用します。それ以外の場合は、特徴的な短いユーザーの引用またはツールの結果を引用します。リンクを捏造したり、推測を事実として述べたりしてはいけません。確実でない再構成や圧縮前の再構成には inferred と記します。
  4. 全体のマップは最大15行に収めます。段階ごとに1行と、簡潔な「目標」「あなたに確認」「次のアクション」の行を含めます。「あなたに確認」には未解決の判断事項を含め、なければ none とします。「次のアクション」には、会話で裏付けられる場合に限り、具体的な次の行動を記します。
  5. デフォルトモードと reset モードでは、変更を加える前に TaskList を呼び出し、各 [S<number>] の候補を TaskGet で確認します。Task がこのスキルに属するのは、subject が [S<number>] で始まり、description に完全一致するマーカー行 session-flow: managed stage が含まれている場合のみです。マークされていない Task は編集、完了、削除、再利用してはいけません。
  6. デフォルトモードでは、段階を表す所有済み Task を更新し、不足している段階は TaskCreate で作成します。subject は [S<number>] で始め、description の最初の行は所有権マーカーと段階の根拠にします。状態をマップに合わせます。完了(中止または方向転換を含む)は completed、現在の段階は in_progress、計画済みの段階は pending とします。再構成したマップから外れた段階の所有済み Task は、TaskUpdate で status を deleted にして削除します。存続する段階番号は維持し、所有されていない Task と番号が重ならないようにします。
  7. OMC の継続フックは、[S<number>] の subject プレフィックスと完全一致する所有権マーカーの両方を持つ Task を対象外とします。そのため、これらの記録は未完了作業として扱われません。作成時または更新時は、両方のマーカーを維持します。short では変更を伴う Task ツールを呼び出してはいけません。
  8. reset では、TaskList と TaskGet を使って所有済み Task を特定し、所有が確認できた Task に限り、TaskUpdate で status を deleted にします。
  9. ネイティブの Task ツールが利用できない場合は、マップを表示しますが、保存したと主張してはいけません。reset の場合は、所有済み Task を確認または削除できなかったことを報告します。どの Task がこのスキルに属するか推測してはいけません。

出力

簡潔で一貫した形式を使用します。

🎯 Goal: <goal and any evidenced change>
✅ S1 <stage> → <outcome> — evidence: <source pointer>
↪ S2 <old direction> → <new direction> — evidence: <source pointer>
▶ S3 <current stage> — evidence: <source pointer>
✂ S4 <dropped path> — <reason> — evidence: <source pointer>
⏸ Needs you: <decision or none>
➡ Next: <supported next action or none>

該当しない例の行は省略します。会話に修正の根拠となる証拠がない限り、呼び出しをまたいでも段階の順序を維持します。修正がある場合は、所有済み Task を更新して一致させます。

コメント