team-update について
team-updateは、チーム向けに進捗やフィードバックを集め、更新文を作成して次の作業を計画するスキルです。編集可能なPlaybookにツール設定や好みを保存し、外部操作には事前承認を求めます。
主な機能
- 01編集可能なプロジェクトPlaybook
- 02ツール検出と未対応時の代替
- 03コミット、チャット、課題、タスクの収集
- 04更新文の作成とフィードバック分類
- 05次の作業の優先順位付け
活用シーン
- 01プロジェクト状況の更新準備
- 02チームのフィードバック確認と分類
- 03最近のリポジトリ作業の要約
- 04課題やタスクに基づく優先順位の計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/team-updateを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/discovery-patterns.mdfeedback-triage.mdmessage-composition.mdplaybook-format.md詳細
チームの最新情報
チームチャットにプロジェクトの最新情報を投稿し、フィードバックを読んで振り分け、次のステップを計画します。利用可能なコミュニケーションツールやプロジェクトツールに合わせて動作します。
プレイブックのパターン
このスキルでは、プロジェクトのルートにある .claude/team-update-playbook.md のプレイブックファイルを使用します。
- 初回実行：利用可能なツールを確認し、ユーザーに希望を尋ねてから実行し、プレイブックを保存します
- 2回目以降の実行：プレイブックを読み込み、確認を省略して直接実行します
- ユーザーがプレイブックを編集した場合：変更はすぐに反映されます（チャンネル、スタイル、振り分けルール）
プレイブックは、ユーザーが編集できる通常の Markdown ファイルです。ツールの設定、チャンネルの希望、メッセージのスタイル、振り分けルール、最終実行時のメタデータが記録されます。
フェーズ 0：プレイブックの確認
プロジェクトのルートに .claude/team-update-playbook.md があるか確認します。
存在する場合：読み込みます。ツールの設定、チャンネル情報、メッセージのスタイル、振り分けルールはすべてこのファイルに記載されています。既知の設定を使ってフェーズ 1 に進みます。
存在しない場合：先にフェーズ 0b（確認）を実行します。
フェーズ 0b：確認（初回実行時のみ）
接続されている MCP ツールと利用可能なローカルツールを確認し、利用可能な機能を検出します。
検出パターンについては、references/discovery-patterns.md を参照してください。
機能の検出
各機能カテゴリについて確認します。
| 機能 | 検出方法 | 見つからない場合の代替手段 |
|---|---|---|
| チャット | chat、slack、discord、teams に一致する MCP ツール | 手動投稿用に書式設定したテキストを出力する |
| Git | git rev-parse --is-inside-work-tree | コミットの要約を省略する |
| 課題 | github、linear、jira に一致する MCP ツール | 省略するか、テキストのリストを出力する |
| タスク | tasks、todos、asana に一致する MCP ツール | 省略するか、テキストのリストを出力する |
| ナレッジ | Basalt Cortex（~/Documents/basalt-cortex/） | 関連するナレッジノートを検索する |
ユーザーの希望（質問する）
確認後、ユーザーに以下を確認します。
- チャンネル：最新情報を投稿するチャットスペース／チャンネルはどれですか？（検出した選択肢を提示）
- 投稿者：本人として投稿しますか、それともボットのIDを使いますか？（例：Anthro Morphic）
- リポジトリの対象範囲：追跡するリポジトリはどれですか？（デフォルト：現在のリポジトリ）
- メッセージのスタイル：簡潔なスタンドアップ形式、詳細な変更履歴、会話形式の最新情報のどれにしますか？
- チームの状況：把握しておくべきチームメンバーはいますか？（名前、役割）
- 振り分けルール：フィードバックの処理に関する独自のルールはありますか？（またはデフォルトを使用）
プレイブックの保存
確認とユーザーの希望の収集後、プレイブックを .claude/team-update-playbook.md に保存します。
完全なテンプレートについては、references/playbook-format.md を参照してください。検出したツールとユーザーの希望を使って、すべてのセクションを埋めます。機能が見つからなかった場合は、プレイブックに「Not available」と記載します。
.claude/ が .gitignore に含まれていることを確認してください（プレイブックには、コミットすべきでないスペース ID やユーザーの希望が含まれます）。
フェーズ 1：コンテキストの収集
利用可能なすべての情報源から情報を集めます。呼び出すツールは、プレイブックの「Data Sources」セクションを確認してください。
1a. 対象期間の決定
プレイブックの「Last Run」セクションで、前回の更新日時を確認します。前回の実行がない場合は、どの期間を対象にするかユーザーに尋ねます（デフォルト：24 時間）。
1b. データの収集
利用可能な各情報源からデータを集めます。
| 情報源 | 収集する内容 | ツール |
|---|---|---|
| Git コミット | git log --oneline --since=<last-update> | Bash |
| チャットメッセージ | 前回の更新以降に設定済みチャンネルで送信されたメッセージ | プレイブックに記載されたチャット MCP ツール |
| 未解決の課題／PR | 最近更新された項目、または新たに作成された項目 | プレイブックに記載された課題追跡ツール |
| 進行中のタスク | 進行中、または最近完了したタスク | タスク追跡ツール |
1c. 下書き用の要約
個々のハッシュではなく、テーマごとにコミットをまとめます。クローズした課題、マージした PR、完了したタスクを記録します。返信が必要なチームメッセージには印を付けます。
フェーズ 2：最新情報の下書きと投稿
2a. メッセージを作成する
メッセージのパターンについては、references/message-composition.md を参照してください。
プレイブックの「メッセージスタイル」セクションに従ってください。基本原則は次のとおりです。
- プロセスではなく、リリースまたは変更した内容から書き始める
- 関連するコミットをテーマごとにまとめる
- 必要な場合に限り、具体的な人物に言及する
- ざっと読めるようにする（短い段落、箇条書き）
- AI ではなく、チームメイトのように書く — 絵文字を多用せず、曖昧な表現を避け、チームがすでに把握している背景を過剰に説明しない。references/message-composition.md の「コミュニケーションスタイル」セクションを参照してください。
2b. プレビューと承認
下書きをユーザーに提示してください。以下を含めます。
- 作成したメッセージ
- 投稿先のチャンネル
- 新しいメッセージか、スレッドへの返信か
承認が必要です：ユーザーの明示的な承認なしに、外部チャンネルへ投稿してはいけません。
2c. 投稿
承認されたメッセージを、プレイブックのチャットツールを使って投稿してください。チャットツールを利用できない場合は、ユーザーが手動で投稿できるよう、書式を整えたメッセージを出力してください。
2d. プレイブックを更新する
投稿後、プレイブックの「最終実行」セクションを次の内容で更新してください。
- 現在のタイムスタンプ
- スレッドキー（該当する場合）
- 投稿内容の簡単な概要
フェーズ 3：フィードバックを読み取り、トリアージする
3a. 返信を読む
更新を投稿してから届いた、設定済みチャンネルのメッセージを読んでください。次の内容を確認します。
- 更新への直接の返信
- プロジェクトに言及している、チャンネル内の新しいメッセージ
- リアクションや確認の返信
3b. フィードバックを分類する
分類パターンについては、references/feedback-triage.md を参照してください。
プレイブックの「トリアージルール」セクションに従ってください。デフォルトの分類は次のとおりです。
| 種類 | 対応 |
|---|---|
| バグ報告 | イシューを作成する（ラベル：bug） |
| 機能リクエスト | イシューを作成する（ラベル：enhancement） |
| 質問 | ユーザーの承認を得るため、返信の下書きを作成する |
| ブロッカー | ただちに報告し、解決策を提案する |
| 確認の返信 | 記録する。対応は不要 |
| 無関係な話題 | 無視する |
3c. 提示して対応する
フィードバックの概要と、提案する対応を提示してください。
## Feedback Summary
- Daniel: "Can we add dark mode?" -> Create issue (enhancement)
- Rabin: "Auth is broken on staging" -> Create issue (bug, priority)
- Karen: "Looks good!" -> No action
Proceed with these actions?
承認が必要です：ユーザーの明示的な承認なしに、イシューの作成、返信の投稿、または外部への対応を行ってはいけません。
フェーズ 4：次のステップを計画する
4a. 優先順位を付ける
集めたすべての情報（コミット、イシュー、タスク、フィードバック）から、次の項目を特定してください。
- ブロッカー：進行を妨げているもの
- 優先度の高い項目：バグ、緊急のリクエスト、期限
- 次に取り組む項目：予定されている作業、機能リクエスト
- バックログ：あると望ましいもの、優先度の低い項目
4b. 提示する（投稿しない）
優先順位を付けたリストをユーザーに提示してください。これはユーザーの計画用であり、チャンネルには投稿しないでください。
## Suggested Priorities
1. [BLOCKER] Fix auth on staging (from Rabin's feedback)
2. [HIGH] Complete API endpoint for user profiles (current sprint)
3. [NEXT] Dark mode support (from Daniel's request)
4. [BACKLOG] Refactor database queries
自律性に関するルール
| 対応 | レベル |
|---|---|
| プレイブックの読み取り／作成 | そのまま実行する |
| ツールの検出（初回実行時） | そのまま実行し、ユーザーに設定を確認する |
| コンテキストの収集（git、チャット、イシュー） | そのまま実行する |
| 更新メッセージの下書き作成 | そのまま実行し、プレビューを提示する |
| 外部チャンネルへの投稿 | 承認が必要 |
| イシュー／タスクの作成 | 承認が必要 |
| チームへの返信の投稿 | 承認が必要 |
| プレイブックの「最終実行」の更新 | そのまま実行する |
| 計画／優先順位の提示 | そのまま実行する |
利用可能なツールに応じた対応
このスキルは、利用可能なツールがどの程度であっても機能します。
| 利用可能なツール | できること |
|---|---|
| Git のみ | コミットを要約し、手動投稿用のテキストを出力する |
| Git + Chat | 投稿と読み取りを一通り実行し、イシューの作成は手動で行う |
| Git + Chat + Issues | イシューの自動作成を含む一連の対応 |
| Git + Chat + Issues + Tasks + Knowledge | 継続的な追跡を含む一連の対応 |
動作モード
このスキルは、さまざまなトリガーフレーズに応答します。
| トリガー | 動作 |
|---|---|
| "team update" / "post update" | 全サイクル：情報を収集し、下書きを作成して投稿し、フィードバックを確認します |
| "check team chat" / "what did the team say" | フェーズ 3 のみ：フィードバックを読み、振り分けます |
| "standup" / "sync with team" | フェーズ 1 + 2：情報を収集して投稿し、フィードバックの確認はスキップします |
| "project update" | フェーズ 1 + 2 + 4：情報を収集して投稿し、計画を立てます（フィードバックの振り分けはスキップします） |
| "feedback loop" | フェーズ 3 + 4：フィードバックを読み、計画を立てます |
参照ファイル
| タイミング | 読み込むファイル |
|---|---|
| 初回実行 — プレイブックの保存 | references/playbook-format.md |
| 初回実行 — ツールの検出 | references/discovery-patterns.md |
| 更新メッセージの作成 | references/message-composition.md |
| チームからのフィードバックの分類 | references/feedback-triage.md |