메뉴
問題・背景・原因（Bug Report）または背景・ユーザーストーリー・受け入れ基準（Feature Request）を整理し、 GitHub Issue として記録する。Issue 種別をユーザーが選択し、種別別の必須セクションを対話で収集して起票する。 解決内容（対策・実装計画）は anvil:impl-issue（triage-issue 経由で起動）が担当する。 トリガー: "issue を作りたい", "問題を記録したい", "バグを issue にして", "課題を起票", "要望を issue にして"
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | create-issue |
| description | 問題・背景・原因（Bug Report）または背景・ユーザーストーリー・受け入れ基準（Feature Request）を整理し、 GitHub Issue として記録する。Issue 種別をユーザーが選択し、種別別の必須セクションを対話で収集して起票する。 解決内容（対策・実装計画）は anvil:impl-issue（triage-issue 経由で起動）が担当する。 トリガー: "issue を作りたい", "問題を記録したい", "バグを issue にして", "課題を起票", "要望を issue にして" |
| user-invocable | true |
| argument-hint | [issue-title] |
| allowed-tools | Bash, AskUserQuestion, Read |
問題・背景・原因または要望・ユーザーストーリー・受け入れ基準を整理し、
GitHub Issue として記録するスキル。
解決内容の分析・実装計画・ブランチ作成・PR 作成は anvil:impl-issue（/anvil:triage-issue 経由で起動）が担当する。
このスキルが書き込む内容: 課題の内容（Issue 種別ごとの必須セクション）のみ。 対策・実装計画・成果物リンク・進捗ステータスは
anvil:impl-issueが後から追記する。
/anvil:create-issue [issue-title]
| 引数 | 内容 |
|---|---|
| issue-title | Issue タイトルのヒント（省略時は対話で確定する） |
gh --version
Error: gh CLI が必要です。
インストール: https://cli.github.com/
gh auth status
Error: gh CLI が認証されていません。
実行してください: gh auth login
git rev-parse --is-inside-work-tree
git remote get-url origin
.git_information.yaml がプロジェクトルートに存在するか確認する。
github.owner / github.repo を取得し、以降の --repo 引数に使用するgh repo view --json nameWithOwner --jq '.nameWithOwner' で <owner>/<repo> を取得する取得した
<owner>/<repo>は Phase 4 のgh issue createで使用する。
AskUserQuestion を使用して Issue 種別を確認する。種別ごとに本文の必須セクションが異なる。
| 種別 | 説明 | ラベル |
|---|---|---|
| Bug Report | 既存挙動の不具合報告 | bug |
| Feature Request | 新機能・既存機能の改善要望 | enhancement |
注意: 種別の自動判定は禁止（REQ-005 I-04）。タイトル文字列やラベルから推定せず、必ずユーザーに確認する。
選択結果を <issue-kind> として記録し、Phase 2 / Phase 3 の分岐に使用する。
<issue-kind> に応じて以下の必須セクションを AskUserQuestion で順に収集する。
情報が得られない項目は、空欄ではなく閉じた集合の不在表現のいずれかで埋める。
以下の 4 表現のみ許容する。N/A / 未確認 / 要調査 等の別表記は使用しない（REQ-005 §5.1 不変条件）。
| 不在表現 | 用途 |
|---|---|
不明 | 情報が得られないため記載できない |
なし | 該当する事象・補足が存在しない |
調査中 | 現時点では未確認だが今後判明する見込み |
該当なし | 質問・項目自体が当該 Issue に該当しない |
Bug Report が選択された場合、以下 8 項目を順に AskUserQuestion で確認する:
| # | セクション | 内容 |
|---|---|---|
| 1 | 背景 / コンテキスト | 何をしようとしていたか、いつ気付いたか |
| 2 | 現象（実際の動作） | 実際に起きたこと。エラーメッセージがあれば原文を含める |
| 3 | 期待動作 | 本来どう動作すべきだったか |
| 4 | 再現手順 | 既知の初期状態（ログイン状態・データ準備等）を明記した上での、番号付きの操作列 |
| 5 | 環境情報 | 少なくとも OS / バージョン / 使用ツールやランタイムのバージョン |
| 6 | 重大度 | 業務継続不能 / 機能に支障あり / 軽微 から AskUserQuestion で選択させる |
| 7 | 証跡 | 関連するスクリーンショット / ログ / 動画への参照（添付または外部リンク）。存在しない場合は なし |
| 8 | 原因 | 判明している場合のみ記載。不明な場合は 調査中 と明記する |
Feature Request が選択された場合、以下 4 項目を順に AskUserQuestion で確認する:
| # | セクション | 内容 |
|---|---|---|
| 1 | 背景 / コンテキスト | なぜこの要望が生まれたか、現状の課題は何か |
| 2 | ユーザーストーリー | 「〜（役割）として、〜（やりたいこと）したい。なぜなら〜（得たい価値）」の形式で、役割・行為・価値の 3 要素を明示する |
| 3 | 受け入れ基準 | 本要望が満たされたと判断できる客観的な条件。各条件は単独で真偽判定できる粒度で記述する |
| 4 | 代替案 / 補足 | 検討した代替案または補足情報。存在しない場合は なし と明記する |
各種別の中核セクションは不在表現のみで埋めてはならない。
中核セクションがすべて不在表現の場合は、AskUserQuestion で再入力を促す（REQ-005 §5.1 不変条件）:
| 種別 | 中核セクション |
|---|---|
| Bug Report | 「現象（実際の動作）」「再現手順」 |
| Feature Request | 「ユーザーストーリー」「受け入れ基準」 |
中核セクションが両方とも不在表現の場合のフロー:
AskUserQuestion で「中核セクションが空のため Issue を起票できません」を提示再入力する / 中断する再入力する → 該当セクションのみ再収集中断する → 終了（Issue を作成しない）Feature Request かつ UI に関わる要望（画面・レイアウト・視覚表現の追加・変更）の場合、 Figma 参照情報を必須収集する（REQ-005 §5.1 不変条件）。
UI 関連かどうかの判定:
AskUserQuestion で「UI に関わる要望ですか？」を確認UI 関連が確定した場合、以下のいずれか 1 つ以上 を AskUserQuestion で必須収集する:
figma.com/design/... 形式）いずれも提供されない場合は中断する。
anvil:impl-issueの UI Issue 経路で必要なため、空欄では起票しない。
タイトル要件（REQ-005 §5.1）:
| 要件 | チェック方法 |
|---|---|
| 改行を含まない 1 文 | 改行・句点 (。/ . / ; ) を除外して確認 |
Issue 種別が読み取れる（[Bug] / [Feature] プレフィックス） | 自動付与する |
| 問題の対象と要点が読み取れる | AI が要約して提案 |
| GitHub Issue タイトルの上限（256 文字）以内 | 文字数を計測 |
引数 [issue-title] が指定されている場合はそれをベースに、未指定の場合は Phase 2 で収集した「現象」または「ユーザーストーリー」から AI が候補を生成する。
種別プレフィックスを必ず付与する:
[Bug] <要約>[Feature] <要約>AskUserQuestion でタイトル候補を提示し、採用 / 修正する から選択させる。
修正の場合は再入力を受けるが、上記 4 要件を満たすまでループする。
DES-025 §6.1 に準拠した HTML コメントマーカー構造で本文を組み立てる。
これにより anvil:impl-issue 後段の update-issue が機械追記セクションのみを冪等に書き戻せるようにする。
<!-- issue-driven-flow:user-content:start -->
## 背景 / コンテキスト
<Phase 2.1 #1 または Phase 2.2 #1 の入力>
## <種別ごとの 2 番目セクション>
<...>
（Phase 2 で収集した全必須セクションを順に記載）
<!-- issue-driven-flow:user-content:end -->
必須:
<!-- issue-driven-flow:user-content:start -->と<!-- issue-driven-flow:user-content:end -->のマーカー対は省略しない。anvil:impl-issue後段のupdate-issueがこのマーカー間を保護対象として識別する。
必須: 必須セクションの見出し名は REQ-005 §5.1 の正規名（「背景 / コンテキスト」「現象（実際の動作）」等）で固定する。
Background/背景単独などの別名・英訳・略称は使用しない。
AskUserQuestion を使用して以下を提示し承認を得る:
タイトル: <title>
ラベル: <bug または enhancement>
本文プレビュー（先頭 30 行）:
<本文の先頭部分>
| 選択肢 | 動作 |
|---|---|
作成する | Phase 4.3 へ |
修正する | どのセクションを修正するか AskUserQuestion で確認し戻る |
キャンセル | 終了（Issue を作成しない） |
特殊文字（バッククォート・ドル記号等）が含まれても安全に渡すため、本文を一時ファイルに書き出してから --body-file で渡す:
mkdir -p .claude/.temp
tee .claude/.temp/issue_body.md <<'BODY'
<本文>
BODY
gh issue create \
--repo <owner>/<repo> \
--title "<title>" \
--label "<bug または enhancement>" \
--body-file .claude/.temp/issue_body.md
作成された Issue 番号（#N）と Issue URL を記録する。
作成成功後、Issue URL を表示する:
Issue を作成しました:
<Issue URL>
AskUserQuestion で次の操作を確認する:
| 選択肢 | 動作 |
|---|---|
ブラウザで開く | gh issue view <#N> --repo <owner>/<repo> --web |
すぐ実装に進む | /anvil:triage-issue #<N> の起動を案内 |
終了 | このまま終了 |
すぐ実装に進む が選択された場合は、ユーザーに以下を提示して終了する（自動起動はしない）:
次のコマンドで進め方の判定から開始できます:
/anvil:triage-issue #<N>
/anvil:impl-issueはuser-invocable: falseのため直接起動できない。/anvil:triage-issueの判定を経由する（軽量実装と判定されれば triage が impl-issue を起動する）。
| エラー | 対応 |
|---|---|
| gh CLI 未インストール | https://cli.github.com/ のインストール手順を案内して終了 |
| gh CLI 未認証 | gh auth login を案内して終了 |
| git リポジトリでない | エラー終了。git init または該当ディレクトリへの cd を案内 |
| リモート未設定 | エラー終了。git remote add origin <url> を案内 |
| 中核セクションが不在表現のみ | AskUserQuestion で再入力 / 中断を確認 |
| UI 関連 Feature Request で Figma 参照情報が未提供 | AskUserQuestion で再入力 / 中断を確認 |
| タイトルが 256 文字を超える | AskUserQuestion で短縮版の再入力を依頼 |
gh issue create 失敗 | AskUserQuestion でエラー内容を提示し、再試行 / 中断を確認 |
ラベルがリポジトリに存在しない（bug / enhancement 未作成） | エラーを表示し、ラベルなしで再試行するか AskUserQuestion で確認 |
/anvil:triage-issue — 起票後の進め方判定（軽量実装なら内部で impl-issue を起動、SDD なら forge start-* を提案）/anvil:create-pr — PR 作成（同一プラグイン内の参照実装）/anvil:commit — コミットメッセージ生成・pushmsg-sys 通信基盤（常駐 Codex セッションとの Stop フック経由の非同期往復）の上で、 Codex とのレビュー依頼・所見受領・修正・完了判定を駆動する。3モード（依頼/受信/再開）を持つ。 依頼モードのトリガー句: "msg-reviewでレビュー依頼", "Codexとレビュー往復したい", "常駐Codexにレビューを依頼", "msg-reviewを実行して", "Codexセッションにコードレビューを頼みたい"。 受信モードの起動契機（トリガー句ではなくメッセージ本文の形式で成立）: Stop フックが差し戻した メッセージ本文の先頭が `[msg-review] <種別> review_id=<review_id> round=<n>` である。 再開モードのトリガー句: "msg-reviewを再開したい", "レビューの往復上限到達通知が来た、状況を確認して", "review_idの未解決所見を要約して", "msg-reviewの続きを確認したい"。
設計書から実装戦略を策定し、タスクを抽出して YAML 計画書を作成・更新する。レビュー+自動修正→commit まで一貫実行。 トリガー: "計画書作成", "計画開始", "start plan", "start planning"
計画書からタスクを選び、実装・レビュー・計画更新まで一貫して実行する。 トリガー: "実装開始", "タスク実行", "start implement"
コード・文書をレビューし、品質問題の発見から修正まで自動化できる。重大度 🔴🟡🟢 で分類。 --auto で修正まで一貫実行。code/requirement/design/plan/uxui/generic の6種別に対応。 トリガー: "レビュー", "review", "レビューして", "確認して"
GitHub Issue を軽量実装で進めるか forge の SDD フロー（start-requirements/start-design/start-plan）に委ねるかを判定するスキル。feature namespace の要否も判定する。トリガー：「このIssueをトリアージして」「Issueの進め方を判定して」「#N はどう進めるべきか判定して」
GitHub Issue の実装を準備から完了まで一貫して行う。triage の判定調査結果（仕様書・ルール・類似PR・既存コードの特定）を引き継ぎ、実装計画の策定・Issue への解決内容記載・実装・レビューまで進める。UI Issue の場合は Figma デザイン仕様書・実装設計書の作成、UI 実装、実装レビューまでカバーする。 `/anvil:triage-issue` が軽量実装と判定した Issue に対して Skill ツール経由でのみ起動される（ユーザーからの直接起動は不可）。