positron-intake-rotation について
Positron IDE の週次担当者向けに、Issue、ディスカッション、サポートチケットの受付手順を案内するスキルです。確認や返信の下書きを支援し、GitHub の変更操作はユーザーが手動で行います。
主な機能
- 01Issue とディスカッションの取得スクリプト
- 02関連する Issue と投稿の検索
- 03ラベルとトリアージ手順の提案
- 04確認用返信の下書き
- 05手動実行する GitHub コマンドの準備
活用シーン
- 01当番中の新規 Issue 確認
- 02重複 Issue や関連投稿の検索
- 03サポートチケット返信の下書き
- 04Issue 分類案の準備
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ posit-dev/ positron --skill positron-intake-rotationインストール後、Claude Code で/positron-intake-rotationを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/intake_workflow.mdresponse_examples.mdscripts/fetch_discussions.shfetch_intake_issues.shfetch_labels.shsearch_related.sh詳細
Positron Intake Rotation
概要
このスキルでは、Positron IDE リポジトリのイシュー受付ローテーションに対応するための包括的なガイダンスを提供します。受付ローテーションとは、チームメンバーが週単位(月曜日から金曜日)で担当し、新しいイシュー、ディスカッションの投稿、サポートチケットを確認して返信することで、迅速な対応と実行可能なイシュー管理を確保する取り組みです。
目標は、新しい投稿におよそ1営業日以内に返信し、すべてのイシューに対応可能な状態にするための情報がそろっていることを確認することです。
🚨 重要:手動操作のプロトコル
このスキルは受付ローテーションを支援しますが、GitHub の操作を直接実行することは決してありません。
GitHub とのすべてのやり取りは、ユーザーが手動で行う必要があります。
- ✅ 投稿前に確認できる返信案を作成する
- ✅ ラベルや分類方法を提案する
- ✅ ユーザーが実行するコマンドを準備する
- ✅ イシューやディスカッションを検索して分析する
- ❌ コメントや返信を直接投稿しない
- ❌ イシューの編集、ラベルの追加、ステータスの変更を行わない
- ❌ イシューをクローズしたり、新しいイシューを作成したりしない
- ❌ GitHub の状態を変更する
ghコマンドを実行しない
ワークフロー: 分析 → 提案 → 返信案の作成 → ユーザーが手動で実行
このスキルを使う場面
次のような場合にこのスキルを使用してください。
- 現在、受付ローテーションを担当している
- 他のチームメンバーの受付作業を支援している
- 受付ローテーションの手順を学んでいる
- ステータスが設定されていないバックログ項目を確認している
- GitHub のディスカッションに返信している
- カスタマーサポートのチケットに対応している
- 重複または関連するイシューを検索している
クイックスタート
主要なスクリプト
受付作業を効率化するために、4つのシェルスクリプトが用意されています。
scripts/fetch_intake_issues.sh- ステータスのないオープンなイシュー(受付キュー)を一覧表示しますscripts/fetch_discussions.sh- 対応が必要な最近のオープンなディスカッションを一覧表示しますscripts/fetch_labels.sh- 分類に使用できるリポジトリのラベルをすべて表示しますscripts/search_related.sh <query>- 関連するイシューやディスカッションを検索します
すべてのスクリプトは、プログラムからの利用に対応する --json フラグをサポートしています。スキルのディレクトリからスクリプトを実行してください。
主要な参考資料
詳細なワークフローを説明する、包括的な参考ドキュメントが2つ用意されています。
references/intake_workflow.md- イシュー、ディスカッション、サポートチケットへの対応に関する一連のワークフローreferences/response_examples.md- 経験豊富なチームメンバーによる返信パターンと例
返信案を作成するときや、複雑なケースに対応するときは、これらの参考資料を読み込んでください。
基本的なワークフロー
毎日の受付プロセス
ローテーション期間中は、毎日次のプロセスに従ってください。
-
新しい項目を確認する
scripts/fetch_intake_issues.shを実行して、ステータスが設定されていない Issue を確認しますscripts/fetch_discussions.shを実行して、最近のディスカッションを確認します- Jira のサポートチケットを確認します
-
各項目を体系的に確認する
- 説明とコンテキストをすべて読みます
- 情報が十分かを評価します(システムの詳細、再現手順などが記載されているか)
- 項目の種類(バグ、機能リクエスト、質問、重複)を判断します
-
関連するコンテンツを検索する
scripts/search_related.sh "<keywords>"を使用して、類似する Issue を検索します- https://positron.posit.co/welcome.html のドキュメントを確認します
- 該当トピックに関する既存のディスカッションを探します
-
分類と整理を提案する
scripts/fetch_labels.shを実行して、利用可能なラベルを確認します- ユーザーが適用できる適切なラベル(領域、種類、優先度)を提案します
- 整理が済んだら、ステータスを「Triage」に設定することを推奨します
- 該当する場合は、「Positron Backlog」プロジェクトへの追加を提案します
- ユーザーが手動で実行する
ghコマンドを準備します
-
ユーザー確認用の返信案を作成する
- パターンについては
references/response_examples.mdを参照します - 投稿者に感謝する歓迎のメッセージを作成します
- 情報が不足している場合は、確認事項を含めます
- 利用可能であれば、回避策や関連コンテンツへのリンクを提案します
- 次のステップについて現実的な見通しを伝えます
- 投稿する前に、ユーザーに返信案を提示して確認してもらいます
- パターンについては
-
後続の対応を提案する
- 専門知識が必要な場合は、関連するチームメンバーへのタグ付けを提案します
- 正式な Issue への参照を含めた重複クローズ用メッセージを作成します
- 適切な場合は、ディスカッションを Issue に変換することを推奨します
- ローテーション終了後も引き続きフォローアップするか、明確に引き継ぐよう助言します
GitHub CLI の使用
一貫性を保つため、他の方法より GitHub CLI(gh)を優先してください。以下のコマンドはすべて、ユーザーが手動で実行するものです。
読み取り専用コマンド(情報収集のために実行できます):
# View issue with all comments
gh issue view <number> --repo posit-dev/positron --comments
# Search issues
gh issue list --repo posit-dev/positron --search "<query>" --state all
# View discussion
gh api graphql -f query='...' # (see scripts for examples)
変更コマンド(ユーザー用に準備し、直接実行は絶対にしないでください):
# Add labels - DRAFT THIS COMMAND for user to run
gh issue edit <number> --repo posit-dev/positron --add-label "area: console,Bug"
# Close as duplicate - DRAFT THIS COMMAND for user to run
gh issue close <number> --repo posit-dev/positron --comment "Closing as duplicate of #<canonical-number>"
重要: 変更コマンドは、ユーザーが確認して手動で実行するよう明確に案内し、コードブロックで提示してください。
さまざまなシナリオへの対応
バグ報告
バグ報告については、情報が十分かどうかを評価します。
情報が十分なバグ報告:
- システムの詳細(Positron のバージョン、OS、コミットハッシュ)
- 明確な再現手順
- 期待される動作と実際の動作
- エラーメッセージまたはスクリーンショット
情報が十分な場合:
scripts/search_related.shを使用して重複を検索します- ユーザーが適用できるラベル(領域、「Bug」タイプ)を提案します
- ステータスを「Triage」に設定することを推奨します
- 報告者に感謝し、問題を認識していることを伝える返信案を作成します
情報が不十分な場合:
- 報告者に感謝するメッセージを作成します
- 不足している情報について、具体的な質問を含めます
- 役立つ場合は、バグ報告テンプレートを参照するよう提案します
- 情報が提供されるまで Issue をオープンのままにするよう助言します
バグ対応の詳細なワークフローについては、references/intake_workflow.md を参照してください。
機能リクエスト
機能リクエストについて:
- 提案してくれたユーザーに感謝するメッセージを作成します
- 関連する既存の機能リクエストを検索します
- 重複している場合は、既存の Issue へのリンクを含むメッセージを作成します(ユーザーが手動でクローズします)
- 新規の場合は、ラベルを提案し、バックログへの追加を推奨します
- 優先順位付けについて現実的な見通しを伝えるメッセージを作成します
ディスカッション
ディスカッションの場合:
- ディスカッションの種類を判断します (質問、アイデア、バグ報告、告知)
- 適切な回答を下書きします:
- 質問: 回答を提供するか、ドキュメントへのリンクを記載します
- アイデア: 内容を承認し、関連する issue へのリンクを記載します
- バグ報告: 正式な issue を作成するようユーザーに依頼します
- オフトピック: 丁寧に別の場所へ誘導します
明確で実行可能なバグ報告や機能リクエストが含まれている場合は、ディスカッションを issue に変換することを推奨します (変換はユーザーが手動で行います)。
サポートチケット
サポートチケットは特別な対応が必要です:
⚠️ 重要: 公開 issue やディスカッションで顧客名を決して言及しないでください
- Jira でチケットのコンテキストを確認します
- 関連する公開 issue を検索します
- ユーザーが投稿できるよう、Jira 内で (公開せずに) 回答を下書きします
- 必要に応じて、機密情報を除去した公開 issue の作成を推奨します
- チケットと issue をリンクすることを提案します
セキュリティ issue
issue にセキュリティ脆弱性が記載されている場合:
- 詳細を公開の場で議論しないでください
- 報告者に [email protected] へメールするよう依頼するメッセージを下書きします
- 非公開での報告に関する注記を添えて公開 issue をクローズすることを推奨します (クローズはユーザーが手動で行います)
- チームに非公開で警告することを助言します
回答ガイドライン
トーンとスタイル
歓迎の姿勢を示す: 貢献者の時間と労力に感謝します
明確にする: 平易な言葉を使い、技術用語を説明し、例を提示します
役立つ情報を提供する: 回避策を提示し、リソースへのリンクを記載し、次のステップを示します
現実的にする: スケジュールや解決策について過度に約束しないでください
プロフェッショナルに徹する: frustrated な報告者に対しても、冷静かつ建設的に振る舞います
事例から学ぶ
経験豊富なチームメンバーの事例を確認するには:
# Find issues commented on by key team members
gh search issues --repo posit-dev/positron --commenter juliasilge --limit 20
gh search issues --repo posit-dev/positron --commenter jmcphers --limit 20
# View specific issue with comments
gh issue view <number> --repo posit-dev/positron --comments
トーンとアプローチの指針については、juliasilge と jmcphers による回答に特に注目してください。
詳細な回答パターンとアンチパターンについては、references/response_examples.md を読み込んでください。
重要なリマインダー
チームコラボレーション
すべてを一人で解決しようとしないでください。 次の場合はチームメンバーに相談してください:
- issue に専門的なドメイン知識が必要な場合
- 分類や優先順位付けの方法がわからない場合
- issue に複雑な技術的問題が記載されている場合
- ユーザーの懸念を理解するための助けが必要な場合
引き継ぎプロトコル
対応が自分のローテーション週を超える場合:
- 通常: トリアージに至るまで、自身でフォローアップを続けます
- それが不可能な場合: ローテーションの次の担当者へ引き継ぎを明確に伝えます
- 明確な引き継ぎなしに項目を放置しないでください
ドキュメント
繰り返し発生する issue やよくある質問が出てきた場合:
- FAQ エントリの作成を検討します
- ドキュメントの改善を提案します
- チームでの議論のためにパターンを記録します
クイックリファレンスリンク
- Issue Intake Board - ステータスのない issue
- Discussions - コミュニティディスカッション
- Support Tickets - カスタマーサポート (Jira)
- Rotation Schedule - Google スプレッドシート
- Documentation - Positron 公式ドキュメント
- Positron Assistant - GitHub issue アシスタント
ワークフロー概要
Daily Intake (Assistant Mode - Draft & Recommend):
1. Fetch new items (scripts/fetch_intake_issues.sh, scripts/fetch_discussions.sh)
2. Review and assess each item
3. Search for related content (scripts/search_related.sh)
4. SUGGEST labels and categorization (scripts/fetch_labels.sh)
5. DRAFT response (references/response_examples.md) for user review
6. PREPARE gh commands for user to execute
7. RECOMMEND setting status to "Triage" (user executes)
8. ADVISE on follow-through or handoff
Remember: The goal is to ASSIST the user with timely response and actionable
organization. NEVER execute GitHub modification commands directly - always
present drafts and recommendations for the user to review and execute manually.