Requesting

手順

1. Issueの種別と内容をユーザーと対話して決定する。
   • storyの場合（ユーザーに価値を提供する機能・改善）:
     • 誰が（ユーザーの種類・ロール）
     • 何をしたいか（実現したい機能・行動）
     • なぜ必要か（その機能による価値・目的）
     • 受け入れ条件（どうなれば完了か）
   • taskの場合（具体的な実現方法・技術的タスク）:
     • タスクの目的
     • 実施内容の詳細
     • 完了条件
2. document-specialist エージェントに依頼してIssueの本文を「Issue作成ルール」に従って生成する。
3. タイトルと本文をユーザーに提示し承認を得る。修正指示があれば反映して再提示する。
4. managing-github スキル（issue-create.sh）を使用してIssueを作成する。
   • storyの場合: --label story を指定
   • taskの場合: --label task を指定
5. 作成したIssueを managing-github スキル（.claude/skills/managing-github/scripts/issue-verify-and-fix.sh）で検証・修正する。
   • issue-create.sh のレスポンスJSONから Issue番号を抽出し、issue-verify-and-fix.sh に渡す
   • 検証結果の報告: 検証結果（ラベルチェック結果、本文フォーマットチェック結果）をユーザーに報告する
   • 修正内容の報告: 修正が発生した場合、具体的な修正内容をユーザーに報告する
   • エラーハンドリング: スクリプト実行が失敗した場合は、エラー内容をユーザーに報告し、手動での確認を促す（Issue作成自体は成功しているため、処理は続行する）
6. 作成したIssueのタイトルとURLをユーザーに報告する。
7. storyラベルの場合のみ、タスク細分化が必要かユーザーに確認し、必要であれば細分化の方法をユーザーと相談する。

Issue作成ルール

タイトル

• story: ユーザーのニーズを表現（例: 「パスワードを忘れた場合に再設定できるようにしたい」）
• task: 実施するタスクを表現（例: 「パスワードリセット機能のAPIエンドポイントを実装する」）

本文構成

storyの場合

• ユーザーストーリー: [ユーザーの種類]として、[実現したいこと]をしたい。なぜなら[その理由・価値]だからだ。
• 背景: なぜこの機能が必要か
• 現状: 現在の状態や問題点
• 期待する結果: 実装後のあるべき姿
• 受け入れ条件: チェックボックス形式で列挙
• 補足情報: 技術的制約、関連Issue/PR、参考リンクなど

taskの場合

• 目的: タスクを実施する目的
• 実施内容: 具体的な作業内容
• 完了条件: チェックボックス形式で列挙
• 補足情報: 技術的制約、関連Issue/PR、参考リンクなど

ラベル判断基準

• story ラベルは、ストーリー（親Issue）にのみ付与する
  • 親Issueで使い、ユーザーの要望やユーザーに提供する価値が記載されているIssue（WHYが中心）
• task ラベルは、タスクIssue（サブIssue）にのみ付与する
  • サブIssueで使い、作業者に依頼できるくらいに実装方法が具体化されているIssue（HOWが中心）

Converted and distributed by TomeVault — claim your Tome and manage your conversions.