القائمة
要件定義書・設計書の追加・改訂後に検索インデックスを最新化する。 新しい仕様文書を /forge:query-db-specs で検索可能にしたいときに実行する。 トリガー: "仕様検索インデックス更新", "仕様検索インデックス再構築", "設計書インデックス更新"
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | update-db-specs |
| description | 要件定義書・設計書の追加・改訂後に検索インデックスを最新化する。 新しい仕様文書を /forge:query-db-specs で検索可能にしたいときに実行する。 トリガー: "仕様検索インデックス更新", "仕様検索インデックス再構築", "設計書インデックス更新" |
| user-invocable | true |
| argument-hint | |
| allowed-tools | Read, Bash, Skill |
仕様文書（key specs）の検索インデックス（ToC）を再構築するラッパー。.doc_structure.yaml から
specs の対象パスを解決して doc-advisor:index-docs へ転送する。
❌ 自己再帰禁止:
Skillツールで自分自身や他の/forge:*-db-*抽象 SKILL を呼ばないこと（無限再帰）
${CLAUDE_PLUGIN_ROOT}/skills/doc-structure/SKILL.md の「検索対象ディレクトリの解決」手順に従い、
category specs で dirs/exclude を取得する。
exclude の裸名（/ なし、例 plan）は doc-advisor の --exclude-json でも同じ意味（パスの任意の階層にある
同名ディレクトリに完全一致）で扱われるため、変換なしでそのまま渡せる（doc-advisor 0.4.4 expand_dirs.py
should_exclude で確認済み）。
ToC の checksum は生成時点のファイル内容で計算される。後続で Skill ツール経由で起動される /anvil:commit の Phase 0 が実行する dprint fmt によって対象ファイルの本文が書き換わると、ToC 生成時点の checksum と実際に commit される内容が不一致になる（Issue #202）。ToC 生成前に dprint fmt を適用し、最終的な内容で checksum を計算させる。
anvil:commit Phase 0 と同一条件・同一コマンドを共有スクリプトで実行する（条件判定・実行ロジックのインライン重複を避けるため）:
bash "${CLAUDE_PLUGIN_ROOT}/scripts/doc_structure/run_dprint_fmt.sh"
これによりファイル内容が変わった場合、変更は作業ツリーに残る（ToC 生成後に呼ばれる /anvil:commit がそのまま commit 対象に含める）。
Skill ツールで doc-advisor:index-docs を 1 回だけ 呼ぶ（常に dirs モード）:
/doc-advisor:index-docs --key specs --dirs-json '<root_dirs の JSON 配列>' --exclude-json '<exclude の JSON 配列>'
exclude が空の場合は --exclude-json '[]' を渡す（省略も可）。
doc-advisor プラグイン（外部 marketplace BlueEventHorizon/DocAdvisor）が未インストールで
doc-advisor:index-docs が available-skills に存在しない場合は、その旨を報告して終了する。
doc-advisor:index-docs の完了レポート（added / updated / deleted / toc_path 等）をそのまま親に返す。
--dirs-json/--exclude-json は key specs の完全な desired state。展開後に
含まれないパスは ToC から削除される（.doc_structure.yaml が正）。.claude/doc-advisor/toc/specs-<hash>/toc.yaml（doc-advisor が管理）。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 ツール経由でのみ起動される（ユーザーからの直接起動は不可）。