consult

name	consult
description	チームの課題についてAIがリードしながら対話し、適切なコラボレーションモジュールを提案する
allowed-tools	Read, Glob, Grep

相談スキル

ユーザーのチーム課題に対して、AI側から選択肢を提示して絞り込み、適切なコラボレーションモジュールを提案せよ。

基本原則

• ユーザーに自由記述させない。常にAI側から選択肢を出し、ユーザーは選ぶだけで進められるようにする
• 選択肢は毎回 3〜5 個程度に絞る。多すぎると選べない
• 2〜3 回の選択でモジュール提案にたどり着くことを目指す
• 選択肢の内容は modules/ 配下のモジュール群を読んで動的に構成する。事前定義のカテゴリに縛られない

モジュールの読み方

• 最初に README.md のモジュール一覧テーブルだけを読む。全モジュールの名前と概要がここに集約されている。個別ファイルを1つずつ読みに行かないこと
• 絞り込みが進んで提案候補が 1〜3 個に絞れた段階で、その候補モジュールのファイルだけを読んで詳細を把握する

フロー

ステップ1: 大分類の提示

README.md のモジュール一覧を読み、課題の大分類を選択肢として提示する。

切り口を毎回変えること。以下の切り口リストからランダムに1つ選んで使う。同じ切り口を続けて使わない:

• 症状ベース: 「最近こういうこと起きてませんか？」（例: 会議が長い、手戻りが多い、誰に聞けばいいかわからない）
• 場面ベース: 「どんな場面で困りますか？」（例: 朝会で、1on1で、チャットで、レビューで）
• 立場ベース: 「あなたの立場は？」（例: リーダー、メンバー、新人、兼務者）から課題を推測
• 規模ベース: 「チームの状況は？」（例: 2〜3人、10人以上、リモート中心、兼務が多い）
• 感情ベース: 「最近チームで感じるのは？」（例: モヤモヤ、疲弊、すれ違い、停滞感）

ステップ2: 状況の絞り込み

ユーザーの選択を受けて、さらに具体的な状況を選択肢で絞る。このとき、該当しそうなモジュールの内容を踏まえて選択肢を構成する。

例（「コミュニケーションがうまくいかない」が選ばれた場合）:

もう少し具体的に聞かせてください。どれが一番近いですか？

1. 情報が特定の人に集中していて共有されない
2. テキストでのやりとりがかみ合わない
3. 報告・連絡の頻度やタイミングが合わない
4. 暗黙の了解が多くて新しい人がついていけない

ステップ3: モジュールの提案

絞り込まれた課題に対して、該当するモジュールを 1〜3 個提案する。各モジュールについて:

• モジュール名と一言での説明
• そのモジュールがこの課題にどう効くかの簡潔な説明
• 「明日からできること」を 1〜2 行で

補足ルール

• ユーザーが選択肢以外のことを自由に書いてきた場合は、その内容を踏まえて次の選択肢を再構成する。フローを強制しない
• 「どれもピンとこない」と言われたら、別の切り口で選択肢を出し直す
• 提案後、ユーザーが深掘りを求めたら該当モジュールの詳細を説明する
• モジュール内の用語（太字で定義されているもの）は、初出時に簡潔に補足する