bw-cc-plugins

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 ツール経由でのみ起動される（ユーザーからの直接起動は不可）。

コミットメッセージを自動生成し、手間なく commit & push できる。 トリガー: "コミットして", "commit して", "push して", "commit & push"

ルール文書の追加・改訂後に検索インデックスを最新化する。 新しいルール文書を /forge:query-db-rules で検索可能にしたいときに実行する。 トリガー: "ルール検索インデックス更新", "ルールインデックス再構築"

要件定義書・設計書の追加・改訂後に検索インデックスを最新化する。 新しい仕様文書を /forge:query-db-specs で検索可能にしたいときに実行する。 トリガー: "仕様検索インデックス更新", "仕様検索インデックス再構築", "設計書インデックス更新"

ブランチ間で衝突しない、次の Spec ID（SCR / DES / TASK / ADR 等任意プレフィックス）を発行する。 要件定義書・設計書・計画書・ADR（アーキテクチャ決定記録）の作成時に ID の重複を防ぐために呼び出される。

コミット差分からタイトル・本文を生成し、PR を素早く作成できる。 トリガー: "PR を作成", "プルリクエスト作成", "create-pr", "PR 出して"

問題・背景・原因（Bug Report）または背景・ユーザーストーリー・受け入れ基準（Feature Request）を整理し、 GitHub Issue として記録する。Issue 種別をユーザーが選択し、種別別の必須セクションを対話で収集して起票する。 解決内容（対策・実装計画）は anvil:impl-issue（triage-issue 経由で起動）が担当する。 トリガー: "issue を作りたい", "問題を記録したい", "バグを issue にして", "課題を起票", "要望を issue にして"

ルール文書を分析し、forge 内蔵 docs との重複を検出・削除し、taxonomy に基づいて再構築する。 トリガー: "rules を整理", "重複ルールを削除", "clean rules", "ルールの掃除"

レビュー結果や調査結果を1件ずつ段階的に提示し、ユーザーの判断を仰ぐ。 /forge:review の対話モードまたは --inline で呼び出される。

要件定義書から設計書を作成する。コンテキスト収集→設計書執筆→レビュー+自動修正→commit を一貫実行。 トリガー: "設計書作成", "設計開始", "start design"

プロジェクトのバージョンを一括更新する。patch/minor/major/直接指定に対応。CHANGELOG 自動反映付き。 トリガー: "バージョン更新", "バージョンアップ", "version bump"

forge 内蔵ドキュメントの検索インデックスを更新する。 /forge:query-forge-rules の検索結果を最新化したいときに使う。 トリガー: "forge ToC 更新", "update forge toc", "forge インデックス更新", "forge 内蔵ドキュメントの ToC を再生成"

Feature 名から specs / rules ドキュメントの実パスを解決する。 他スキルが Feature に紐づくドキュメントの場所を特定したいときに呼び出す。

forge 内蔵の様々な知識ベースを、キーワード・機能名・自然文で、高速・高品位に、優先度をつけて検索する。

要件定義書を作成する。3モード対応: 対話形式でゼロから/既存コード解析で逆算/Figma デザインから抽出。 完了後にレビュー+自動修正→ToC更新→commit の完了フローを実行する。 トリガー: "要件定義", "要件定義書作成", "ソースから要件抽出", "Figma から要件"

要件定義書の ASCII アートからデザイントークンと UI コンポーネントの視覚仕様を創造する。 Apple HIG / Norman / Rams / Nielsen / Gestalt の知見に基づく UX 評価付き。iOS / macOS 対応。 トリガー: "UXUIデザイン", "デザイントークン作成", "start uxui design"

2 つの仕様ディレクトリ（基本 DIR と追加 DIR）を 1 つに統合する。 追加側を正とし、基本側を追加側の内容に合わせて修正したうえで、追加側に残る純粋新規部分のみを基本側へ移し、追加 DIR を削除する。 内容単位（節・項目）で処理し、ファイル単位の単純コピーではない。 トリガー: "仕様 DIR をマージ", "spec をマージ", "merge spec", "追加仕様を基本に統合", "spec ディレクトリ統合"

プロジェクトの様々なルールを、キーワード・機能名・自然文で、高速・高品位に、優先度をつけて検索する。 設計・実装・コーディング・レビュー等、開発作業のあらゆる場面でルールを参照したいときに使う。

プロジェクトの様々な仕様書を、キーワード・機能名・自然文で、高速・高品位に、優先度をつけて検索する。 設計・実装・コーディング・レビュー等、開発作業のあらゆる場面で仕様を参照したいときに使う。

SKILL.md の description / trigger を公式ベストプラクティスに基づき監査・改善提案する。 新規スキル作成時や既存スキルの品質チェックに使用する。 トリガー: "スキルの description をレビュー", "SKILL.md チェック", "review skill description"

Android Emulator / iOS Simulator 上で実装済みアプリ画面を起動・反映・操作・キャプチャする。現時点では Android/stub 対応、iOS は拡張予定。実装後レビュー、Figma との見た目突合、Emulator/Simulator のスクリーンショット取得が必要なときに使用する。

Figma デザインからデザイン仕様書を作成する subagent スキル。PAT で対象フレームを特定し、MCP で詳細取得、PAT で精度補完。画面設計書の nodeId を信頼せず Figma で検証する。YAML レイアウト定義から AI 理解プレビューを自動生成し、Figma SS と並べて検証する。impl-issue の Phase 6 から呼び出される。

画面設計書・Figma・実装キャプチャの三点突合で、実装済み画面を仕様とデザインに同期する。Figma 側の対象ノード特定、スクリーンショットによる採用判断、visible 判定、色・フォント・余白の実値抽出、capture-emulator-screen による実装側キャプチャ、デザイントークン対応、差分修正までを扱う。「Figma 通りに直して」「デザイン差分を抽出して修正して」「この画面を設計とデザインに合わせて」と言われた時に使用する。

Figma MCP サーバーの公式知識ベース。get_design_context や get_screenshot 等のツール仕様、デザインコンテキスト取得、セットアップ、Flutter プロジェクト固有ルール（デザイントークン、フォント、アセット管理）を参照したい時に使用する。

Figma nodeId の発見・検証スキル。画面名/ID から Figma 内の正しい nodeId と URL を特定・検証する。画面設計書の nodeId を信頼せず、PAT（REST API）で Figma 側を実際に確認する。MCP は使用しない。

Claude Code plan mode で書いた **Markdown plan** から、要件定義書と設計書を一気通貫で作成する。 本 skill が入力にするのは **Claude Code plan mode の Markdown plan** であり、 forge の実装計画書 `{feature}_plan.yaml`（YAML、`/forge:start-plan` が作成）とは別物。 Markdown plan を起点にゼロから feature の仕様化を始めたいときに使う。 トリガー: "markdown plan から feature 作成", "plan mode から要件作成", "create feature from markdown plan"

プロジェクトのディレクトリをスキャン・分類し .doc_structure.yaml を対話的に生成する。 forge が文書を参照するための必須初期設定。 トリガー: "forge の初期設定", "doc structure を作成", "ドキュメント構成", "setup"

プロジェクトをスキャンしバージョン管理対象を検出、.version-config.yaml を対話的に生成する。 update-version の前提条件。プロジェクト構造変更時にも再実行する。 トリガー: "version config を作成", "バージョン設定", "setup version config"

forge スキル一覧を表示し、選択したスキルの引数をガイド付きで構成してそのまま実行できる。 トリガー: "forge help", "forge の使い方", "ヘルプ", "どのスキルを使えばいい"