Menu
要件定義書・設計書の追加・改訂後に検索インデックスを最新化する。 新しい仕様文書を /forge:query-db-specs で検索可能にしたいときに実行する。 トリガー: "仕様検索インデックス更新", "仕様検索インデックス再構築", "設計書インデックス更新"
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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 ツール経由でのみ起動される（ユーザーからの直接起動は不可）。