mcpField
F
forge-create-issue

forge-create-issue

github.com/mgratzer開発8352 回インストール3 日前に更新
リポジトリ

forge-create-issue について

対話を通じて、構成の整った Issue の計画と作成を支援するスキルです。関連コードを調査し、目的や成功条件を確認して実装案と範囲を検討し、ユーザーの承認後にプロジェクトの Issue トラッカーへ登録します。

主な機能

  1. 01関連コードと再利用箇所の調査
  2. 02背景と成功条件の確認
  3. 03実装アプローチの比較
  4. 04単一または複数 Issue の検討
  5. 05草案承認後の Issue 作成

活用シーン

  1. 01機能案を Issue にまとめる
  2. 02不具合報告の完了条件を定める
  3. 03実装案を比較して範囲を決める
  4. 04大きな作業を関連 Issue に分割する

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mgratzer/forge --skill forge-create-issue

インストール後、Claude Code で/forge-create-issueを入力して読み込まれたか確認します。

同梱ファイルreferences/afk-vs-hitl.md

詳細

Issue の作成

対話を通じて共同で計画し、適切に構成された Issue を作成します。Issue はプロジェクトの Issue トラッカーに作成されます。プロバイダーの検出については、issue-operations を参照してください。

入力

Issue のアイデアまたは問題の説明：$ARGUMENTS

任意：実行時の指針として -- <additional context> を指定できます。

引数が指定されていない場合は、どのような内容で Issue を作成したいかユーザーに尋ねてください。

プロセス

ステップ 1：コードベースを調査する

ユーザーの入力を解析し、質問する前に関連するコードを調査します。

  • 関連する既存の実装やパターンを見つけます
  • 統合ポイントと再利用できる可能性のある箇所を特定します

関連する場合は、外部依存関係にアクセスできることを確認します。問題があれば、先に進む前にその旨を伝えてください。

ステップ 2：詳細を確認する

AskUserQuestion を使って、コードからは判断できない情報を集めます。

  • 問題の背景 — 何がきっかけか、誰が影響を受けるか、現在の動作と望ましい動作
  • 成功基準 — 何をもって完了とするか
  • 制約 — 技術的な制限、依存関係
ステップ 3：代替アプローチを提示する

入力に、根拠とともに選択済みのアプローチが含まれている場合は、このステップを省略します。意図的な分析を通じてすでに決定されているため、ステップ 4 に直接進みます。

それ以外の場合は、単一の推奨案ではなく、見つかった構造的に異なるアプローチ（通常は 2～4 個）を提示します。選択するのはユーザーです。

各アプローチについて、以下を示します。

  • 1 行でまとめた概要
  • 仕組み（簡潔に）
  • メリットとデメリット
  • 相対的な複雑さ（低／中／高）
  • 影響を受ける主なファイル

AskUserQuestion を通じて、アプローチの選択または組み合わせをユーザーに委ねます。

ステップ 4：スコープを評価する

Issue を 1 つにするか、複数に分けるかを評価します。

分割する場合： 成果物が異なる、コードベース内の異なる領域に関わる、並行して作業できる、または作業量が 1～2 日を超える場合。

まとめる場合： 変更が密接に関連している場合、または分割によって調整の負担が増える場合。

分割する場合は、垂直方向に切り分けます。各 Issue は、エンドツーエンドの薄い一連の作業にします（vertical-slicing を参照）。それぞれを AFK または HITL に分類します（afk-vs-hitl.md を参照）。依存関係の順に並べます。

分割が適切な場合は、単一の Issue、相互にリンクした複数の Issue、またはサブ Issue を含むエピックを提示します。

ステップ 5：Issue の下書きを作成する

タイトル： Conventional Commit 形式を使用します — <type>(<scope>): <description>

ラベル： ラベルを付ける前に、既存のラベルを確認します。issue-operations を参照してください。少なくとも 1 つのタイプラベルと、関連する領域ラベルを付けます。

本文の構成：

## Summary
[1-2 sentences]

**Execution mode:** [AFK | HITL] 

## Problem / Motivation
[Why this needs to exist]

## Proposed Solution
[Chosen approach with implementation details]

### Alternatives Considered
[Other approaches and why they weren't chosen]

### Implementation Constraints
[When applicable: preferred libraries, config locations, patterns to follow, external dependencies]

## Acceptance Criteria
- [ ] [Specific, testable criteria]
- [ ] Tests added/updated
- [ ] Documentation updated (if applicable)
ステップ 6：確認して作成する

下書きをユーザーに提示し、納得するまで調整します（承認または修正の判断には AskUserQuestion を使います）。その後、プロジェクトの Issue トラッカーを使って Issue を作成します。エピックとサブ Issue を含むプロバイダー固有の手順については、issue-operations を参照してください。

Issue の参照情報を共有します。実装を始めるには forge-implement を使うよう提案します。

ガイドライン

  • 好奇心を持つ — 前提を問い直し、「なぜ」「もし～なら」と尋ねます
  • 詳細を指定しすぎない — 実装者が判断できる余地を残します
  • Issue に所要時間の見積もりを書かない — ステップ 4 の作業量の目安は分割を判断するためのものであり、Issue 本文に記載するものではありません

関連スキル

次のステップ： forge-implement を使って Issue を実装します。

使用例

/forge-create-issue add dark mode support
/forge-create-issue add dark mode support -- keep it to a single Issue
/forge-create-issue

コメント

Markdown 対応