بنقرة واحدة
doc-structure
Feature 名から specs / rules ドキュメントの実パスを解決する。 他スキルが Feature に紐づくドキュメントの場所を特定したいときに呼び出す。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
القائمة
Feature 名から specs / rules ドキュメントの実パスを解決する。 他スキルが Feature に紐づくドキュメントの場所を特定したいときに呼び出す。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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 ツール経由でのみ起動される(ユーザーからの直接起動は不可)。
| name | doc-structure |
| user-invocable | false |
| description | Feature 名から specs / rules ドキュメントの実パスを解決する。 他スキルが Feature に紐づくドキュメントの場所を特定したいときに呼び出す。 |
| argument-hint |
.doc_structure.yaml(config.yaml 互換フォーマット)を読み込み、
ドキュメントのパス解決・Feature 検出・doc_type 判定を行う。
forge 内の他スキルからの呼び出し専用(user-invocable: false)。
.doc_structure.yaml のパス解決を担う自己完結設計(外部依存なし)。
.doc_structure.yaml が無い場合の共通ハンドオフ [MANDATORY]以下の各能力の手順中で .doc_structure.yaml が見つからない場合は、この手順に従う。
呼び出し元スキルは個別に存在確認を行わない(本スキルに一本化する。設定ファイルの
生成自体は責務が大きく異なるため setup-doc-structure スキルのまま分離するが、not-found 時の
ハンドオフはここで一元化する)。
.doc_structure.yaml が見つかりません。
/forge:setup-doc-structure を実行してプロジェクト構造を定義する必要があります。
今すぐ /forge:setup-doc-structure を実行しますか?
/forge:setup-doc-structure を呼び出す。完了後、呼び出し元が
要求した能力の手順を最初からやり直す(.doc_structure.yaml が生成されているはず)。.doc_structure.yaml が無いため解決できません」と報告して終了する。新規ドキュメントの出力先ディレクトリを求めたい他スキル(start-design 等)は、.doc_structure.yaml
の内部スキーマ(doc_types_map 等)を自スキルの SKILL.md に書かず、本節を Read して以下の手順に従う。
doc_type(抽象カテゴリ名。例: design / plan / requirement / rule)feature(任意。既知の Feature 名。未指定なら Step 3 の存在確認モードになる)category(省略時 specs。ルール文書を扱う場合のみ rules).doc_structure.yaml を Read する。存在しない場合は上記「共通ハンドオフ」に従う。{category}.doc_types_map から、値が入力 doc_type と一致するエントリ(キー)を1つ探す。
見つからない場合は「{doc_type} に対応するエントリがありません」と報告して終了する。feature が指定されている場合: エントリのキー(例: docs/specs/**/design/)の */**
セグメントを feature に置換し、解決済みディレクトリとする(例: docs/specs/{feature}/design/)。feature が指定されていない場合: エントリのキーをそのまま Glob パターンとして使い
(例: docs/specs/**/design/*.md)、一致する既存ファイルの有無を確認する。feature 指定時: 解決済みディレクトリのパスfeature 未指定時: 既存ファイルの有無(と一致したファイル一覧)文書検索(Grep 等)や外部インデックス転送のために対象ディレクトリ一覧を求めたい他スキル
(query-db-rules / update-db-rules 等)は、.doc_structure.yaml の root_dirs/patterns.exclude
を自スキルの SKILL.md に書かず、本節を Read して以下の手順に従う。
category(rules または specs).doc_structure.yaml を Read する。存在しない場合は上記「共通ハンドオフ」に従う。{category}.root_dirs と {category}.patterns.exclude を取得する。dirs: root_dirs の配列(そのまま)exclude: patterns.exclude の配列filtered_dirs(参考値): dirs のうち、末尾ディレクトリ名が exclude のいずれかに一致するエントリを
除いた配列(自前でツールに渡す前に除外したい consumer 向け。ネストした除外ディレクトリの混入は
許容する)dirs/exclude をそのまま下流ツール(doc-advisor の --dirs-json/--exclude-json 等)へ転送する
consumer は filtered_dirs を使わず dirs/exclude を使う。自前で Grep 等に渡す consumer は
filtered_dirs を使う。
短縮名(例: main)・相対パス・絶対パスのいずれかを実ディレクトリへ解決したい他スキル
(merge-specs 等)は、.doc_structure.yaml の root_dirs を自スキルの SKILL.md に書かず、
本節を Read して以下の手順に従う。外部ライブラリ(PyYAML 等)は使わない(プロジェクト規約:
Python は標準ライブラリのみで動作する)。
alias(短縮名 / 相対パス / 絶対パスのいずれか)alias がそのまま存在するディレクトリなら、それを解決結果として終了する。.doc_structure.yaml を Read する(存在しない場合は上記「共通ハンドオフ」に従う)。
specs.root_dirs の各エントリについて、最初の *(または **)より前の部分を
「spec ルート候補」として抽出し、重複を除いて列挙する(例: specs/*/design/ → spec ルート候補
specs/)。<spec_root>/<alias>/ が存在するか(Glob または Bash
[ -d ... ] で)確認する。存在すればそれを解決結果とする。${CLAUDE_PLUGIN_ROOT}/scripts/doc_structure/resolve_doc_structure.py
SCRIPT="${CLAUDE_PLUGIN_ROOT}/scripts/doc_structure/resolve_doc_structure.py"
# カテゴリ別のファイル一覧
python3 "$SCRIPT" --type rules
python3 "$SCRIPT" --type specs
python3 "$SCRIPT" --type all
# Feature 一覧(specs の glob パターンから抽出)
python3 "$SCRIPT" --features
# 特定 doc_type のファイル一覧
python3 "$SCRIPT" --doc-type design
python3 "$SCRIPT" --doc-type design --category specs
python3 "$SCRIPT" --doc-type rule --category rules
# バージョン情報
python3 "$SCRIPT" --version
# プロジェクトルート・ファイルパスの指定
python3 "$SCRIPT" --type all --project-root /path/to/project
python3 "$SCRIPT" --type all --doc-structure /path/to/.doc_structure.yaml
--type の出力{
"status": "ok",
"project_root": "/path/to/project",
"rules": ["docs/rules/coding_standards.md", "docs/rules/git_workflow.md"],
"specs": ["docs/specs/forge/design/some_design.md", "..."]
}
--features の出力{
"status": "ok",
"features": ["forge", "auth", "payment"]
}
--doc-type の出力{
"status": "ok",
"category": "specs",
"doc_type": "design",
"files": ["docs/specs/forge/design/some_design.md", "..."]
}
--version の出力{
"status": "ok",
"version": "4.4",
"major_version": 4
}
{
"status": "error",
"message": ".doc_structure.yaml が見つかりません: /path/to/.doc_structure.yaml"
}
SCRIPT="${CLAUDE_PLUGIN_ROOT}/scripts/doc_structure/resolve_doc_structure.py"
RESULT=$(python3 "$SCRIPT" --type all)
JSON 出力を受け取り、必要なフィールドを利用する。
forge プラグイン内の Python スクリプトからは直接 import 可能:
import sys
import os
# resolve_doc_structure.py のパスを追加
sys.path.insert(0, os.path.join(
os.path.dirname(__file__), '..', 'scripts', 'doc_structure'
))
from resolve_doc_structure import (
load_doc_structure,
resolve_files,
resolve_files_by_doc_type,
detect_features,
invert_doc_types_map,
match_path_to_doc_type,
)
config.yaml 完全互換。forge は root_dirs, doc_types_map, patterns.exclude のみ使用する。
他フィールド(toc_file, checksums_file, work_dir, output, common 等)は無視する。
# doc_structure_version: 3.0
rules:
root_dirs:
- docs/rules/
doc_types_map:
docs/rules/: rule
# ... doc-advisor 固有フィールド(forge では無視)
specs:
root_dirs:
- "docs/specs/**/design/"
- "docs/specs/**/plan/"
- "docs/specs/**/requirement/"
doc_types_map:
"docs/specs/**/design/": design
"docs/specs/**/plan/": plan
"docs/specs/**/requirement/": requirement
# ... doc-advisor 固有フィールド(forge では無視)
* は1階層のみ、** は任意の深さにマッチする。サブ Feature(forge/review-PR/design/ 等)がある場合は ** を使用する。
| フィールド | 用途 |
|---|---|
{category}.root_dirs | ドキュメントディレクトリの一覧(glob パターン *, ** 対応) |
{category}.doc_types_map | パス → doc_type のマッピング |
{category}.patterns.exclude | 除外パターン |
コメント行 # doc_structure_version: X.Y でバージョンを管理する。
メジャーバージョン変更はフォーマットの破壊的変更を意味する。