---

name: gh-ss description: GitHub Issue を起点に実装前の計画コメントを作成して投稿し、設計方針が確定するまで Issue コメント上で質疑・改訂を繰り返すためのスキル。Issue 番号を受け取り、Issue 本文/既存コメントを読んで実装方針・変更対象見込み・影響範囲・テスト/確認方針・ユーザー確認事項を整理し、Issue に「## Implementation Plan (Codex)」見出しでコメント投稿する。実装・コード変更・PR 作成は行わない。

GH SS

Overview

GitHub Issue から実装前の計画コメントを作成し、Issue に投稿する。設計方針が確定するまで、Issue コメントでユーザーからの返信を受けて計画を改訂・再投稿する。実装（コード変更/PR 作成）は一切行わない。

Workflow

1. リポジトリの AGENTS.md を読み、言語/運用ルールに従う。
2. 本リポジトリは GAS が中心のため、計画内に npx clasp push の要否を明示する（実行条件は AGENTS.md に従う）。
3. Issue を読み取る。必ず次のコマンドで本文を取得する。 gh issue view <N> --json number,title,body,labels,assignees -q ".number,.title,.body"
4. 既存コメントも読み取る（計画やフィードバックの履歴確認）。 例: gh issue view <N> --json comments -q ".comments[].body"
5. Issue 本文と既存コメントの内容から計画を整理する。情報が不足/曖昧な場合は推測せず、 ユーザー確認事項 に具体的な質問として列挙する。
6. ## Implementation Plan (Codex) 見出しでコメント本文を作成する。 形式は references/plan-template.md を使用する。
7. コメントは必ず --body-file - で投稿する（--body に改行は禁止）。 例: cat <<'EOF' | gh issue comment <N> --body-file -
8. 投稿後は 待機状態 に入り、ユーザーの返信（追加要件/修正指示/質問への回答）を受け取る。
   • ユーザーから「イシューにコメント追記しました」「返信しました」等の連絡があった場合は、実装に進まず、必ず Issue コメントを再取得して反映する。
9. ユーザー返信を反映し、計画が変わる場合は ## Implementation Plan (Codex) を更新して再投稿する。
   • 変更点が小さくても、差分（何が変わったか）を冒頭に箇条書きで明示する。
10. すべての ユーザー確認事項 が解消し、ユーザーが「この計画で進めてOK」「確定」等で承認したら、 次に実行すべきこと（例: 実装スキル/PR スキルの起動）を 案内だけ して終了する。

Notes

• 返答は必ず日本語にする。
• ユーザーへの返答で「実装に入ります」「PR を作成します」等の宣言は禁止。
• 終了条件: ユーザーが計画を明示的に承認するまで、このスキルは「計画の作成/改訂/質問の整理」のみを行う。
• ユーザーの返信を受けたら、必ず Step 3 と Step 4 のコマンドで Issue 本文とコメントを再取得してから反映する。
• このスキルは「実装開始」「着手」「作業を進めて」等の言葉が出ても、実装をしない（別スキルが必要）。
• ユーザーの返信待ちの間に、勝手に追加作業（実装・調査・リファクタ）を開始しない。
• Issue 番号が未指定なら、作業前にユーザーへ確認する。
• clasp を使う場合は npx clasp を優先する（@google/clasp は devDependencies）。