القائمة
会話文脈から GitHub issue を作成する。「issueを作って」「issue立てて」等のリクエストで使用。本文は「背景 / やりたいこと / 配慮してほしいこと」の3セクション構成。「背景・やりたいこと」は背景と What(何をやりたいか)に集中し How(実装方法)は書かない。「配慮してほしいこと」は任意(省略可)で制約・要望を書く。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
tmuxセッション内で実際のNeovimを起動し、send-keys / capture-pane で操作・観察してデバッグする。 Neovimの起動確認、プラグインエラーの調査、checkhealthの確認、設定変更の動作確認、 「nvimをデバッグして」「起動確認して」「checkhealth見て」などのリクエストで使用する。 Agentがnvimを直接実行する必要が生じた場合も、必ずこのスキルの手順を使うこと。
AIとの会話を、ユーザーの思考メモ(Self)も含めてGitHub IssueまたはPull Requestにコメントとして追加する実験版。手動で呼び出して使用。
タスクについて詳細に調査し、構造化されたまとめを出力する。ultrathinkモードで深く考察し、背景、期限、過去の対応方法、確認事項を調査。すべての情報に出典リンクを明記し、推測は必ず明示する。
AIとの会話をまとめてGitHub IssueまたはPull Requestにコメントとして追加する。手動で呼び出して使用。
AI Agentの説明で理解できない部分を、前提知識なしで噛み砕いて説明する。会話中にその場で呼び出して使う。用語の定義と、なぜそれが重要かを中心に解説する。
Agentの作業を止めずに済む場面でtmuxを活用する。判断軸は「このコマンドの完了を同期的に待つとAgentの作業が止まるか」。止まらない（数秒で終わる確認コマンド）ならBash直接。止まるが管理不要（所要時間が不確実、一度きりの非同期実行）ならtmux直接利用（tmux new-session -d）。止まる上に管理も必要（長時間ビルド・テスト・dev server・watcher・並列検証・対話的CLI・ログ永続化）ならこのスキルを呼び出してジョブ管理する。
| name | create-issue |
| description | 会話文脈から GitHub issue を作成する。「issueを作って」「issue立てて」等のリクエストで使用。本文は「背景 / やりたいこと / 配慮してほしいこと」の3セクション構成。「背景・やりたいこと」は背景と What(何をやりたいか)に集中し How(実装方法)は書かない。「配慮してほしいこと」は任意(省略可)で制約・要望を書く。 |
| argument-hint | [title] [--repo owner/repo] |
| allowed-tools | Bash, Write, Read |
| disable-model-invocation | true |
会話文脈から GitHub issue を作成する。本文は「背景 / やりたいこと / 配慮してほしいこと」の3セクションで組み立てる。「背景」「やりたいこと」は背景と What(何をやりたいか)に集中し、How(実装方法)は書かない。実装方法は担当者の判断に委ねる。実装上の要望や制約がある場合は「配慮してほしいこと」に書いてよく、そこでは How を含めてもよい。
happy663/dotfiles以下の3セクションで作成する。「背景」「やりたいこと」は背景と What を書き、How(実装方法)は書かない。「配慮してほしいこと」は任意で、書くべきことがなければ省略してよい(ないならないで問題ない)。
[必須] / [できれば] プレフィックスを付ける。ここに書く内容は着手時点の想定であり、調査の過程で変わりうる(例: 実は配慮不要だった、別の配慮が必要だった、[必須] が [できれば] に緩和された等)ことを前提とする完了条件は独立セクションとして持たない。「やりたいこと」を具体的に書けば実質的に兼ねる。ゴールがぼやける場合は「やりたいこと」の末尾に達成状態を明記する。
「背景」「やりたいこと」に書くのは背景と What だけ。How は意図的に書かない。迷ったときの判断基準:
How になりそうな記述は「やりたいこと」に書かず、担当者に委ねる。ただし、実装方法に関する要望や動かせない制約は「配慮してほしいこと」に書いてよく、そこでは How を含めてよい。
入力の収集
不足情報の聞き出し
背景・What の情報が不足していて、本文を書かないと認識齟齬を生む場合は、ユーザーに聞き出す。聞き出すのは背景と What だけ。How は聞かず、推測もしない。
聞き方は一度にまとめて行う:
How は聞かない。実装要望は、ユーザーが自発的に出した場合のみ「配慮してほしいこと」に書く。
投稿先リポジトリの決定
--repo owner/repo が指定されていればそれを使うhappy663/dotfiles をデフォルトとする本文をファイルに書き出す
/tmp/issue-body.md投稿前の確認
投稿
gh issue create --repo <owner/repo> --title "<title>" --body-file /tmp/issue-body.md
投稿後の検証
gh issue view <番号> --repo <owner/repo> --json body --jq .body で本文を取得## 背景
- [なぜ必要か、どういう文脈か]
- [判断材料になる周辺情報]
## やりたいこと
- [達成したいゴール(What)]
- [具体的なアウトプット像]
## 配慮してほしいこと
- [必須] [制約・前提、または実装方法(How)の要望]
- [できれば] [守れるとうれしい希望]
--body-file)で渡す。--body の直接指定や HEREDOC は使わない[必須] / [できれば] を付けて強弱を明示する。担当者が Must と Nice-to-have を区別できるようにするため