بنقرة واحدة
query-db-specs
プロジェクトの様々な仕様書を、キーワード・機能名・自然文で、高速・高品位に、優先度をつけて検索する。 設計・実装・コーディング・レビュー等、開発作業のあらゆる場面で仕様を参照したいときに使う。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
プロジェクトの様々な仕様書を、キーワード・機能名・自然文で、高速・高品位に、優先度をつけて検索する。 設計・実装・コーディング・レビュー等、開発作業のあらゆる場面で仕様を参照したいときに使う。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
| name | query-db-specs |
| description | プロジェクトの様々な仕様書を、キーワード・機能名・自然文で、高速・高品位に、優先度をつけて検索する。 設計・実装・コーディング・レビュー等、開発作業のあらゆる場面で仕様を参照したいときに使う。 |
| user-invocable | true |
| argument-hint | task description |
| allowed-tools | Skill, Read, Grep, Glob, Bash |
仕様文書(key specs)を検索する read-only ラッパー。doc-advisor:query-docs へ転送する。
doc-advisor が未インストールの場合は grep による簡易検索へフォールバックする。
❌ 自己再帰禁止:
Skillツールで自分自身や他の/forge:*-db-*抽象 SKILL を呼ばないこと(無限再帰)
doc-advisor:query-docs が available-skills に存在する場合、Skill ツールでこれを 1 回だけ 呼ぶ:
/doc-advisor:query-docs --key specs <$ARGUMENTS>
$ARGUMENTS(検索タスク記述)をそのまま末尾に渡す。バックエンドの応答はそのまま親に返す(構造変換しない)。
ToC(key specs)が未生成(TOC_NOT_FOUND)の場合は、/forge:update-db-specs で索引を生成するよう案内する。
doc-advisor:query-docs が available-skills に 存在しない 場合は、A を呼ばずに以下を実行する。
Step B-1: ユーザーへ通知 [MANDATORY]
応答の冒頭に必ず以下の警告を出す(grep フォールバックは優先度付けの品質が doc-advisor に劣るため):
⚠️ doc-advisor(外部 marketplace BlueEventHorizon/DocAdvisor)が未インストールのため、grep による簡易検索にフォールバックしました。
高品位な優先度付き検索を行うにはインストールを推奨します:
/plugin marketplace add BlueEventHorizon/DocAdvisor
/plugin install doc-advisor@DocAdvisor
Step B-2: 対象ディレクトリの解決
${CLAUDE_PLUGIN_ROOT}/skills/doc-structure/SKILL.md の「検索対象ディレクトリの解決」手順に従い、
category specs で filtered_dirs を取得し、Grep 対象ディレクトリとする。
対象ディレクトリが空の場合は「検索対象の仕様文書がありません」と報告して終了する。
Step B-3: 検索語の類義語展開 [MANDATORY]
grep は表記が一致しないとヒットしない(doc-advisor のような意味検索ができない)ため、$ARGUMENTS から
抽出した検索語ごとに 類義語・関連語を展開 してから検索する。展開の観点:
version、「レビュー」↔ review、「権限」↔ permission)req ↔ requirements、spec ↔ specification、CI ↔ continuous integration)index / indexing / 索引、config / configuration / 設定)元の語と展開語をまとめて検索対象とする。
Step B-4: grep 検索
展開した語を Grep ツール(-i 相当の大文字小文字無視、語を | で連結した正規表現も可)で
Step B-2 の対象ディレクトリに再帰的に適用する(path にディレクトリを指定、glob: "*.md" で
Markdown に絞る)。いずれかの語にマッチしたファイルを候補とし、マッチした語の種類数・出現数が
多い順に並べる。判断に迷う候補は実体を Read で確認し、false negative を避ける。
応答の先頭は Required documents: 形式(フォールバック時は Step B-1 の警告を先に出してから続ける):
Required documents:
- docs/specs/xxx/requirements/yyy.md
- docs/specs/xxx/design/zzz.md
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 ツール経由でのみ起動される(ユーザーからの直接起動は不可)。