| name | summarize-issue |
| description | issueファイルを分析し「まとめ」セクションを作成する。issueのまとめ、要約を依頼された時に使用。 |
| argument-hint | [issue-file-path] |
| allowed-tools | Read, Edit, mcp__acp__Read, mcp__acp__Edit |
| disable-model-invocation | false |
Issue要約スキル
現在開いているissueファイルを分析し、「まとめ」セクションを作成します。
手順
-
issueファイルの読み込み
- 引数で指定されたissueファイル、または現在エディタで開いているissueを特定して全内容を読み込む
- ファイル名から判断できない場合は、ユーザーにissueファイルのパスを確認する
-
内容の分析
- issueの全体を理解する
- 以下の観点を抽出する:
- 何をしたか: 作業内容、実施した変更、追加した機能など
- なぜそうしたか: 背景、きっかけ、動機、目的
- 問題と対応: 発生した問題、エラー、そしてその解決方法
- 関連リンク: 関連するPR、issue、ドキュメントへのリンク
-
まとめの作成
- 3-5段落、各段落2-3文程度で簡潔に記述
- 技術的な詳細は適度に含めつつ、全体像が分かるように構造化する
- GitHubリンクは必ず箇条書き形式で記載(
- https://github.com/... の形式)
- 問題が発生していない場合は、問題セクションは省略してもよい
- 文体: 常体(だ・である調)で統一する。丁寧体(です・ます調)は使用しない
- 例: 「していました」→「していた」、「判明しました」→「判明した」
-
出力方法の判定と実行
Octo buffer (octo://で始まるパス) の場合:
- ファイルへの直接書き込みは不可(仮想バッファのため)
- まとめをマークダウンのコードブロック(
markdown)で囲んでチャットに出力する
- ユーザーが手動でコピー&ペーストして
:wで保存する
通常のファイルの場合:
## まとめというセクションタイトルで作成
- 既存の「まとめ」セクションがある場合は上書きする
- 配置位置: issueファイルの末尾(最後のセクション後)
出力フォーマット例
## まとめ
[作業内容についての段落。何を実施したか、どのような変更を加えたかを説明]
[背景についての段落。なぜこの作業が必要だったのか、どういうきっかけで始めたかを説明]
[問題と対応の段落(該当する場合)。遭遇した問題とその解決方法を説明]
注意事項
- まとめは簡潔かつ情報量のバランスを取る
- 技術用語は適切に使用し、専門性を保つ
- 時系列が分かりやすいように記述する
- 作成後、ユーザーに追加した内容を確認してもらう