issue-intake

Issue Intake (As-Is / To-Be → Issue) スキル

このスキルは、Issue を起票するフェーズ だけを担当する。PdM/CS や、思いついた要望をまずチケット化したい人が入口で使う。実装フェーズには踏み込まない。

---

このスキルを使う場面

✅ 使う:

• 「As-Is: ○○ / To-Be: ○○」と整理された入力
• 「○○できるようにしたい」「○○がバグってる」「○○あると嬉しい」などのふわっとした要望
• 「これチケットにして」「Issue 作って」「課題を起票したい」
• 複数の要望をまとめて起票したい(1 件ずつ繰り返し適用)

❌ 使わない:

• 既に Issue 番号が決まっている → github-issue-pr-flow(実装フェーズ)へ
• アイデア段階で仕様自体を整理したい → pdm-design-doc へ
• 雑談・調査・読み取りのみ

---

上位/下位スキルとの関係

pdm-design-doc          (アイデア → Design Doc・仕様書)
       ↓
issue-intake            ← このスキル (As-Is/To-Be → Issue)
       ↓
github-issue-pr-flow    (Issue → ブランチ → 実装 → PR)

各スキルは 一方向に渡すだけ。実装まで戻らない。

---

標準フロー

Step 1. 入力を As-Is / To-Be に整理

入力パターンによって対応を分岐する。

パターン A: As-Is / To-Be が明示されている

そのまま使う。曖昧な部分があれば 1 文ずつ確認する。

パターン B: 不具合報告風 (「○○が壊れてる」「動かない」)

• As-Is = 現在の壊れた挙動
• To-Be = 正常に動く状態
• 種別ラベル = bug 候補

パターン C: 機能要望風 (「○○できたら嬉しい」「○○あるといいな」)

• As-Is = 「現状 ○○ できない / ○○ が無い」
• To-Be = 入力された要望
• 種別ラベル = enhancement 候補

パターン D: ふわっとしすぎ (「なんか UX 微妙」「使いづらい」)

• 推定せず、ユーザーに質問 して具体化する
  • 「どの画面のどの操作が、どう微妙ですか?」
  • 「どうなったら満足ですか?」
• 具体化できなければ起票しない(pdm-design-doc への誘導を案内)

整理後、必ずユーザーに確認 してから次へ進む:

以下の内容で起票しようとしています。よろしいですか?

As-Is: <要約>
To-Be: <要約>
推定ラベル: <種別ラベル>

ユーザー承認なしに Step 2 へ進まない。

---

Step 2. 既存 Issue の重複チェック

gh issue list --search "<キーワード>" --state all --limit 20 で検索する。

キーワードの作り方

• To-Be / As-Is の主要名詞・動詞を 2〜3 個抽出
• 同義語・関連語も試す(例: 「通知」+「アラート」+「メール」)
• 必要に応じて --label <ラベル> で絞り込み

検索結果の提示フォーマット

重複チェック結果:

🔴 強い候補(open):
- #12 〇〇画面の通知改善 (created: 2026-04-01, labels: enhancement, P2)

🟡 弱い候補(closed):
- #23 〇〇通知をメールで送る (created: 2026-03-10, closed: 2026-03-15)

選択肢:
a) #12 に乗せる(コメントで追記情報を投稿)
b) 新規 Issue を起票
c) #23 を再オープンして使う
d) やめる

ユーザーが選ぶまで起票しない。

何件もヒットして判定できない場合

• ラベルや期間で絞り込む提案をする
• それでも絞れなければユーザーに「直近 1 ヶ月のみ見ますか?」「特定ラベル無しで?」と確認

---

Step 3. Issue 起票(b を選んだ場合のみ)

3-a. ラベル確認

既存ラベル一覧を取得:

gh label list --limit 100

種別ラベルは必須。To-Be の内容から推定:

• バグ → bug
• 新機能・改善 → enhancement
• ドキュメント → documentation
• 内部リファクタ → refactor または tech-debt
• セキュリティ → security
• テスト追加 → test

該当ラベルが無い場合は ユーザーに確認:「X を付けようと思いますが、新規ラベル Y を作りますか?」承認なしに gh label create しない。

優先度・領域ラベル(P0/P1/ux/manual 等)はユーザーが明示したときだけ。

3-b. タイトル

• 70 文字以内
• 「○○を△△できるようにする」「○○のときに○○を表示する」のような To-Be 起点 の動詞文
• リポジトリの既存 Issue のスタイルに合わせる(gh issue list --limit 10 で確認)
• プレフィックス例: feat: fix: docs: refactor: chore: (リポジトリの慣習に合わせる)

3-c. 本文テンプレート

## As-Is
<現状を 1〜3 文で>

## To-Be
<あるべき姿を 1〜3 文で>

## 受け入れ条件
- [ ] <これを満たせば完了とみなせる条件>
- [ ] <なるべく検証可能な粒度で>
- [ ] (UI 変更を伴う場合) マニュアル / リリースノート / スクショも同じ PR で更新
- [ ] (該当する場合) E2E テストの追加・更新

## 補足
<関連 Issue / 関連 URL / スクショ / 参考実装 等。空ならセクション削除>

受け入れ条件は強く推奨。「実装フェーズで何を作れば完了か」を入口で固めることで、後工程の認識ズレを防ぐ。書けない場合は「ユーザー側で後ほど補足してください」と明記して起票して良い。

マニュアル / リリースノート / E2E の項目は、プロジェクトに該当機能が無ければ自然と省略される(チェックボックスごと外して起票)。プロジェクトの CLAUDE.md にマニュアル/リリースノートの運用が書かれている場合は、それを参照する旨を補足に入れると親切。

3-d. gh issue create 実行

gh issue create \
  --title "<タイトル>" \
  --label "<種別ラベル>" \
  --label "<追加ラベル(任意)>" \
  --body "$(cat <<'EOF'
<本文テンプレート>
EOF
)"

3-e. ラベル付与の確認

gh issue view <番号> --json labels

ラベル空配列ならエラー。gh issue edit で追加してから次へ進む。

---

Step 4. 既存 Issue にコメント追加(a を選んだ場合のみ)

gh issue comment <番号> --body "$(cat <<'EOF'
追加情報:

## As-Is
...

## To-Be
...

(関連: 今回 issue-intake skill 経由で追記)
EOF
)"

ラベルや優先度が変わるべきなら、ユーザーに確認してから gh issue edit で更新する。

---

Step 5. 再オープン(c を選んだ場合のみ)

gh issue reopen <番号>

その上で Step 4 と同じくコメント追記。再オープンの理由が「クローズ判断が早すぎた」のか「再発した」のかを 1 文でコメントに含める。

---

Step 6. 完了報告

ユーザーに以下を報告して 作業を止める:

• Issue URL
• 付けたラベル
• ステータス(新規起票 / コメント追記 / 再オープン)
• 「実装は github-issue-pr-flow に #<番号> を渡してください」と引き継ぎ案内

禁止事項:

🚫 そのままブランチを切らない 🚫 そのまま実装に進まない 🚫 「ついでに直しました」をしない 🚫 ユーザー承認なしに新規ラベルを作らない

実装まで進めたい場合はユーザーが明示的に「これ実装して」と次の入力をする。その時点で github-issue-pr-flow の役割。

---

エッジケース

入力が複数の課題を含んでいる

• 1 課題ずつ分解してから Step 1 に戻る
• 「3 件に分かれそうですが、それぞれ起票しますか? まとめますか?」とユーザー確認

既に類似 Issue があり、優先度を上げてほしい依頼

• 起票ではなく gh issue edit <番号> --add-label P0 等で対応
• 「優先度を P2 → P0 に変更しました」と報告

スクショ・添付ファイルがある

• GitHub の gh issue create は添付に対応しないので、起票後に Issue 編集 UI で手動添付 をユーザーに依頼する
• 本文には添付予定のファイル名と用途を 1 行入れておく(例: スクショ: error-toast.png (再現時の画面))

Issue 運用していないリポジトリ

• 「このリポジトリは Issue 運用していますか?」と確認
• 否の場合はこのスキルは適用外。github-issue-pr-flow のエッジケース節へ案内

CLAUDE.md / プロジェクト固有のルールがある

• リポジトリ直下に CLAUDE.md があれば、Issue 起票前に必ず一読(プロジェクト固有のラベル運用・テンプレート指定がある可能性)

---

やってはいけないこと

🚫 As-Is / To-Be が不明確なまま起票する(必ずユーザー確認) 🚫 重複チェックなしで起票する 🚫 起票しただけで実装まで進める 🚫 ユーザー承認なしに新規ラベルを作る 🚫 自分でブランチを切る・PR を作る(実装フェーズは github-issue-pr-flow の責任) 🚫 重複候補があっても「念のため新規起票」を独断で選ぶ

---

チェックリスト(作業終了時)

• As-Is / To-Be がユーザーに確認済み
• 既存 Issue の重複チェックを実施した
• ユーザーの選択(a/b/c/d)に従った
• ラベルを 1 つ以上付けた(gh issue view --json labels で確認済み)
• Issue URL をユーザーに返した
• 「実装は github-issue-pr-flow に引き継ぎ」と案内した
• ブランチを切っていない・PR を作っていない