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が中心）