Menu
GitHub Issue・PRのトリアージ。番号を渡すと、要望の要約・実現難易度・既存機能との重複チェック・対応判断を調査してレポートする。Issue/PRの番号が出てきたとき、トリアージ、優先度判断、対応判断と言われたときに使用する。
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Baseado na classificação ocupacional SOC
アプリのリリース（バージョンbump + CHANGELOG + タグ → GH Actions で自動ビルド・配布）。iOS / Android / macOS / Linux / Windows の任意の組み合わせでリリースできる。「リリース」「バージョン上げて」「リリースして」と言われたときに使う。
ccpocket の X 向けリリース告知カード画像を作成・更新する。最新の iOS/Android/macOS リリースタグ、App Store release_notes、既存の scripts/release-card/generate.mjs を使って英語・日本語の告知PNGを生成し、画像を目視確認して不備があれば生成スクリプトを修正する。「リリースカード」「X告知画像」「リリース報告用画像」「release-card」と言われたときに使用する。
ストア情報の更新自動化 — スクリーンショット撮影（シミュレーター × モック画面 × Marionette MCP）とメタデータテキスト更新。ストア更新、スクショ更新、App Store / Google Play のメタデータ更新、リリースノート作成の際に使用すること。
Codex の使い方、CLI/app/IDE、rules・hooks・AGENTS.md・skills・subagents・config などを案内する。Codex や OpenAI 製品の仕様を答える前に必ず公式ドキュメントを確認し、rules/approval は `codex execpolicy check` で実検証すること。
MCP (dart-mcp + Marionette) を使ったFlutterアプリのE2E自動化・UI検証ガイド。シミュレーターでのUI動作確認、モックプレビュー検証、Bridge経由のE2Eテスト、スクリーンショット撮影など、アプリの動作検証が必要なときに使う。「動作確認して」「UIを検証して」「E2Eテスト」「シミュレーターで確認」「モックで確認」と言われたときや、UI変更後の検証フェーズで使用すること。
Shorebird OTA パッチの作成・staging 配布（stable 昇格はユーザー実施）
| name | triage |
| description | GitHub Issue・PRのトリアージ。番号を渡すと、要望の要約・実現難易度・既存機能との重複チェック・対応判断を調査してレポートする。Issue/PRの番号が出てきたとき、トリアージ、優先度判断、対応判断と言われたときに使用する。 |
GitHub Issue または PR の番号を受け取り、コードベースを調査して対応判断に必要な情報をレポートする。
/triage 42
/triage #8
番号からIssueかPRかを自動判定する。
# まずIssueとして取得を試みる
gh issue view <番号> --json number,title,body,labels,state,comments,author,createdAt
# 404なら PRとして取得
gh pr view <番号> --json number,title,body,labels,state,files,comments,author,reviews,createdAt
# Issueのコメント
gh issue view <番号> --json comments --jq '.comments[].body'
# PRのレビューコメント
gh pr view <番号> --json reviews --jq '.reviews[].body'
IssueテンプレートやラベルからIssueの種別を判定する:
| 種別 | 判定基準 |
|---|---|
| Bug Report | bug ラベル、テンプレートのフィールド |
| Feature Request | enhancement ラベル、Proposal セクション |
| Prompt Request | テンプレートに「プロンプト」「AI tool」セクション |
| Dependabot | author が dependabot[bot] |
| 外部PR | authorがリポジトリオーナー以外 |
Issue / PR が以下に該当するかを確認する:
現時点では、少なくとも以下は experimental / best-effort または未サポート寄りとして扱う:
この種のIssueでは、通常のバグ判定に加えて以下も見る:
要望の内容に基づいて、関連するコードを調査する。 Explore サブエージェントを活用して並列に調査を進める。
# 変更ファイル一覧
gh pr view <番号> --json files --jq '.files[].path'
# diff の取得
gh pr diff <番号>
調査結果をもとに、実装の難易度を判定する。
| 難易度 | 基準 | 工数目安 |
|---|---|---|
| Low | 単一ファイルの修正、UIの微調整、既存パターンの踏襲 | ~1時間 |
| Medium | 複数ファイルの変更、新しいWidgetの追加、既存APIの拡張 | 数時間 |
| High | プロトコル変更（Bridge + Flutter両方）、新機能のフルスタック実装 | 1日以上 |
| Very High | アーキテクチャ変更、外部依存の追加、セキュリティモデルの変更 | 数日以上 |
判定の根拠を具体的なファイルパスや変更箇所とともに示す。
以下のフォーマットで会話内にレポートを出力する。
## Triage Report: #<番号> <タイトル>
### 概要
[1-2文で要望の要約]
### 種別
[Bug / Feature / Prompt Request / Dependabot / 外部PR]
### プラットフォーム状況
[正式サポート / experimental / 未サポート]
### 推奨ラベル
- [例: `platform:windows`]
- [例: `status:experimental`]
- [例: `help wanted`]
### 既存機能チェック
- [既に実現済みの機能があれば記載]
- [部分的に実現されている場合はその旨と差分]
- [完全に新規の場合は「該当なし」]
### 実現難易度: [Low / Medium / High / Very High]
**根拠:**
- [変更が必要なファイル・モジュール]
- [プロトコル変更の有無]
- [影響範囲]
### 対応判断
| 観点 | 評価 |
|------|------|
| ユーザー価値 | [高/中/低] — [理由] |
| 実装コスト | [高/中/低] — [理由] |
| リスク | [高/中/低] — [理由] |
| 推奨 | [対応する / 保留 / 見送り] |
### 推奨アクション
- [具体的な次のステップ]
- [必要なら「PRなら受け入れ可能な条件」]
Windows や macOS版モバイルのように、メンテナが継続的に検証していない環境に関するIssueでは、次の基準を追加で適用する:
対応する だけでなく、外部PR待ち や best-effort と明記してよい推奨ラベル例:
platform:windowsplatform:macosstatus:experimentalstatus:unsupportedneeds-reproneeds-testhelp wanted推奨アクション例:
以下を満たすPRは best-effort でレビュー・取り込み候補にしてよい:
逆に、以下に当てはまるPRは慎重に扱う:
外部PRはそのままマージするのではなく、内容を精査してメンテナが取り込む方針を取っている。 これは、PRの意図は良くても実装の一部を修正・調整したいケースが多いため。
Co-authored-by を付与して貢献者をクレジットする
Co-authored-by: username <email>
gh api users/<username> --jq '.name, .email'<id>+<username>@users.noreply.github.com を使用外部PRのトリアージレポートでは、推奨アクションに取り込み方針を含める:
### 推奨アクション
- **取り込み方針**: [そのままマージ / 一部修正して取り込み / 参考にして再実装]
- **修正が必要な点**: [具体的な修正箇所]
- **Co-authored-by**: `Co-authored-by: Name <email>`
Issue/PRにコメントを投稿する際は、投稿者の言語に合わせて対応する:
Issue/PRのタイトル・本文・コメントから投稿者の言語を判定する。
バイリンガル返信の場合は、元言語を先に書き、--- で区切って英語を後に続ける。
例: 日本語のIssueへの返信
ご提案ありがとうございます！この機能は v1.5.0 で実装済みです。
セッション一覧画面で未読インジケーターが表示されます。
---
Thank you for the suggestion! This feature has been implemented in v1.5.0.
You'll see unread indicators on the session list screen.
gh issue comment / gh pr comment で複数段落の本文を投稿する場合は、シェルクォートで本文を直接 --body に埋め込まない--body-file で渡すgh issue view / gh pr view で最新コメントを取得し、改行や Markdown が崩れていないか確認する例:
cat <<'EOF' >/tmp/comment.md
First paragraph.
- bullet 1
- bullet 2
EOF
gh pr comment <number> --body-file /tmp/comment.md