القائمة
コミットメッセージを自動生成し、手間なく commit & push できる。 トリガー: "コミットして", "commit して", "push して", "commit & push"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
msg-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 ツール経由でのみ起動される（ユーザーからの直接起動は不可）。
استنادا إلى تصنيف SOC المهني
| name | commit |
| description | コミットメッセージを自動生成し、手間なく commit & push できる。 トリガー: "コミットして", "commit して", "push して", "commit & push" |
| user-invocable | true |
| argument-hint | [message] |
変更内容を要約したコミットメッセージを生成し、GitHub へ commit & push する。
/anvil:commit [message]
| 引数 | 内容 |
|---|---|
| message | コミットメッセージ（省略時は変更内容から自動生成） |
commit 前に format 乱れを必ず解消する。format ずれたまま commit すると、後で誰かが fmt を走らせたときに無関係なファイルが diff に混入し、PR レビューや git blame が混乱する。
共有スクリプトで実行する（存在チェック + 実行、条件判定ロジックのインライン重複を避けるため）:
bash "${CLAUDE_SKILL_DIR}/scripts/run_dprint_fmt.sh"
dprint fmt が新たにファイルを書き換えた場合、それも本 commit に含める (関連: ユーザー方針「dprint fmt がスコープ外ファイルを整形しても revert 不要」)。
dprint 以外の formatter (prettier / black / rustfmt 等) が project で使われている場合は、CLAUDE.md か README.md の指示に従って手動適用したうえで本 commit に含める。
git status --porcelain
変更なし → エラー終了:
Error: コミットする変更がありません。
変更をファイルに保存してから再試行してください。
指定されたメッセージをそのまま使用する。
git diff HEAD の変更内容を解析して要約を自動生成する。変更の性質に応じて以下のプレフィックスを使用:
| 変更の性質 | プレフィックス |
|---|---|
| 新機能追加 | feat: |
| バグ修正 | fix: |
| リファクタリング | refactor: |
| 文書変更 | docs: |
| その他 | chore: |
git status
原則: ステージ済みファイルのみをコミット対象とする。自動で git add しない。
ステージ済みファイルがある場合 → そのまま Phase 4 へ進む。
ステージ済みファイルがなく、未ステージの変更がある場合 → AskUserQuestion を使用して確認する:
git add -u を実行未追跡ファイルがある場合は AskUserQuestion を使用して個別にステージするか確認する。
保護ブランチへの直接 commit を未然に防ぐ。
git branch --show-current
保護ブランチの解決優先順位（create-pr skill と同一の優先順位に揃える）:
.git_information.yaml の default_base_branchdevelop → main → master の順で、リポジトリに存在するものを採用AskUserQuestion で警告し、対応を確認する:
現在のブランチ (<current-branch>) は保護ブランチです。直接 commit せず feature ブランチを作成することを推奨します。
提案する feature ブランチ名: feature/<Phase 2 で生成したコミットメッセージから推定したスラッグ>
AskUserQuestion で承認・修正させた上で git checkout -b <branch> を実行し、Phase 4 へ進むブランチ名の推定は AI が Phase 2 で生成したコミットメッセージ（fix(anvil): ... 等）の要約部分を英語スラッグ化して feature/ を前置する（例: fix(anvil): triage-issue Phase 7 条件3の測定単位を客観的な閾値に修正 → feature/anvil-clarify-blast-radius-threshold）。
そのまま Phase 4 へ進む（確認不要）。
以下の内容を表示した上で、AskUserQuestion を使用してコミットの承認を得る:
ブランチ: <current-branch>
メッセージ: <生成したコミットメッセージ>
対象ファイル: <ステージング済みファイル一覧>
git commit -m "<生成されたメッセージ>" を実行コミット失敗（pre-commit hook によるエラー等）の場合は、AskUserQuestion を使用してエラー内容を提示し対応を確認する。
コミット成功後、AskUserQuestion を使用してプッシュの承認を得る:
git pushgit push -u origin <current-branch>push 失敗の場合は AskUserQuestion を使用してエラー内容を提示し対応を確認する。
| エラー | 対応 |
|---|---|
| 変更なし | エラー終了・変更を促す |
| detached HEAD | git symbolic-ref 失敗 → ブランチ名なしで続行 |
| コミット失敗 | AskUserQuestion でエラー内容を提示し対応を確認 |
| push 失敗 | AskUserQuestion でエラー内容を提示し対応を確認 |