Codex 互換性に関する注記：

• Codex では $skill-name でリポジトリスキルを呼び出します。このミラーコピーはレガシーの Claude /skill-name 参照を書き換えます。
• この Codex ミラーでの計画ガイダンスは plan-hard スキルを推奨します。
• タスクトラッカー義務：ワークフローまたはスキルステップを実行する前に、すべてのステップのタスク追跡を作成/更新し、進行状況が変わるにつれて同期を保ってください。
• ユーザー質問プロンプトは Codex でユーザーに直接質問することを意味します。
• Claude 固有のモード切り替え命令が現れた場合は無視してください。
• 厳密な実行契約：ユーザーがスキルを明示的に呼び出した場合、そのスキルプロトコルを記述どおりに実行します。
• サブエージェント認可：スキルがユーザー呼び出しまたは AI 検出され、そのプロトコルがサブエージェントを必要とする場合、そのスキル起動はそのタスクに必要な spawn_agent サブエージェントの使用を認可します。
• ユーザーが明示的に偏差を最初に承認しない限り、プロトコルステップをスキップ、並べ替え、またはマージしないでください。
• ワークフロースキルについては、リストされた各子スキルステップを明示的に実行し、段階的な証拠を報告します。
• 必要なステップ/ツールがこの環境で実行できない場合は、適応する前に停止してユーザーに確認してください。

<!-- CODEX:PROJECT-REFERENCE-LOADING:START -->

Codex プロジェクト参照ロード（フック無し）

Codex は Claude フックベースのドキュメント注入を受け取りません。 コーディング、計画、デバッグ、テスト、またはレビューの際は、このルーティングを使用してプロジェクトドキュメントを明示的に開いてください。

常に読むべき文書：

• docs/project-config.json（プロジェクト固有のパス、コマンド、モジュール、ワークフロー/テスト設定）
• docs/project-reference/docs-index-reference.md（完全な docs/project-reference/* カタログへのルート）
• docs/project-reference/lessons.md（常時有効な保障とアンチパターン）

状況別ドキュメント：

• バックエンド/CQRS/API/ドメイン/エンティティの変更：backend-patterns-reference.md、domain-entities-reference.md、project-structure-reference.md
• フロントエンド/UI/スタイリング/デザインシステム：frontend-patterns-reference.md、scss-styling-guide.md、design-system/README.md
• 仕様/テストケース計画または TC マッピング：feature-docs-reference.md
• 統合テスト実装/レビュー：integration-test-reference.md
• E2E テスト実装/レビュー：e2e-test-reference.md
• コードレビュー/監査作業：code-review-rules.md プラス変更されたファイルに基づく上記のドメインドキュメント

すべてのドキュメントを盲目的に読まないでください。docs-index-reference.md から始めて、タスクに関連するファイルのみを開いてください。

<!-- CODEX:PROJECT-REFERENCE-LOADING:END -->

クイックサマリー

目標： Microsoft Word（.docx）ファイルを GFM サポート（テーブル、画像、フォーマット）付き Markdown に変換します。

ワークフロー：

1. インストール -- pandoc が利用可能であることを確認します（必須の依存関係）
2. 変換 -- GFM 出力形式と画像抽出で pandoc を実行します
3. クリーンアップ -- 一貫性のための Markdown の後処理

キールール：

• システムに pandoc がインストールされている必要があります
• 画像を Markdown と並んで media/ ディレクトリに抽出します
• テーブル、フォーマット、ドキュメント構造を保持します

懐疑的になってください。批判的思考と段階的思考を適用してください。すべての主張には追跡可能な証拠が必要です。信頼度は80％以上である必要があります。

docx-to-markdown

Microsoft Word（.docx）ファイルを GitHub 風 Markdown サポート付き Markdown 形式に変換します。

インストール必須

このスキルは npm 依存関係が必要です。 以下のいずれかを実行してください：

# オプション 1：ClaudeKit CLI 経由のインストール（推奨）
ck init  # install.sh を実行し、すべてのスキルを処理します

# オプション 2：手動インストール
cd .claude/skills/docx-to-markdown
npm install

依存関係： mammoth、turndown、turndown-plugin-gfm

クイックスタート

# 基本的な変換
node .claude/skills/docx-to-markdown/scripts/convert.cjs --input ./document.docx

# 出力パスを指定
node .claude/skills/docx-to-markdown/scripts/convert.cjs -i ./doc.docx -o ./output.md

# 画像をフォルダに保存
node .claude/skills/docx-to-markdown/scripts/convert.cjs -i ./doc.docx --images ./images/

CLI オプション

オプション	短形式	説明	デフォルト
--input	-i	入力 DOCX ファイルパス	（必須）
--output	-o	出力 Markdown ファイルパス	{input}.md
--images		抽出された画像のディレクトリ	インライン base64
--help	-h	ヘルプメッセージを表示

機能

• GFM テーブル： Word テーブルを markdown テーブルに適切に変換します
• 画像： 埋め込み画像を抽出します（base64 インラインまたはフォルダへ）
• リスト： 順序付きリストと順序なしリストを保持します
• コードブロック： 等幅テキストをコードブロックに変換します
• リンク： ハイパーリンクを保持します
• 見出し： 見出しレベルを維持します
• クロスプラットフォーム： Windows、macOS、Linux で動作します

変換パイプライン

DOCX → mammoth → HTML → turndown → Markdown

DOCX→HTML→MD の 2 段階変換は、最良の結果のための mammoth の公式推奨に従っています。

出力

成功時に JSON を返します：

{
    "success": true,
    "input": "/path/to/input.docx",
    "output": "/path/to/output.md",
    "stats": {
        "images": 3,
        "tables": 2,
        "headings": 5
    }
}

制限事項

• 複雑なレイアウト（列、テキストボックス）は構造を保持できない可能性があります
• 結合されたテーブルセルは基本的な markdown テーブルを生成します
• コメントと変更追跡は削除されます
• 一部のフォーマット（フォント、色）は変換で失われます

---

[重要] タスク追跡を使用して、開始前にすべての作業を小さなタスクに分割してください（ファイル読み込みの各タスクを含む）。これにより、長いファイルからのコンテキスト損失を防止します。単純なタスクの場合、AI はスキップするかどうかをユーザーに確認する必要があります。

<!-- SYNC:ai-mistake-prevention -->

AI ミステイク防止 — すべてのタスクで回避すべき障害モード：

削除前にダウンストリーム参照をチェックしてください。 コンポーネント削除により、ドキュメントとコード陳腐化のカスケードが発生します。削除前にすべての参照ファイルをマップしてください。 AI 生成コンテンツを実際のコードと照合してください。 AI は API、クラス名、メソッド署名を幻覚します。ドキュメント化または参照する前に、必ず grep で存在を確認してください。 編集後の完全な依存チェーンをトレースしてください。 定義を変更すると、それから派生するダウンストリーム変数とコンシューマーが見落とされます。常に完全なチェーンをトレースしてください。 正確性を検証する際にすべてのコードパスをトレースしてください。 コードが存在することを確認することは、それが実行することを確認することではありません。常に早期終了、エラーブランチ、条件付きスキップをトレースしてください。ハッピーパスだけではなく。 デバッグするとき、修正する前に「誰の責任か」と尋ねてください。 呼び出し側（データが間違っている）か呼び出し側（処理が間違っている）かをトレースしてください。責任層で修正してください。症状部位にパッチを当てないでください。 既存の値は意図的であると仮定してください。変更する前に理由を確認してください。 定数、制限、フラグ、またはパターンを変更する前に：コメント、git blame を読み、周囲のコードを確認してください。 最初だけでなく、すべての影響を受ける出力を検証してください。 複数のスタックに接触する変更は、すべての出力の検証が必要です。1 つのチェックマークがすべてのチェックマークではありません。 総合的デバッグ - 最も近い注意の罠に抵抗してください。 障害を調査するときは、すべての前提条件（設定、環境変数、DB 名、エンドポイント、DI 登録、データ前提条件）をリストします。次に、コード層の仮説を形成する前に、証拠に対して各々を検証してください。 手術用変更 - diff テストを適用してください。 バグ修正：変更されたすべての行は直接バグをトレースする必要があります。隣接するコードを改善またはリスタイルしないでください。拡張タスク：改善を実装し、明示的に発表してください。 あいまいさを表面に出してからコーディングしてください。コーディング前に選択を黙認しないでください。 リクエストに複数の解釈がある場合は、各々に労力推定を提示して確認してください。すべてのレコード、ファイルベース、またはより複雑なパスを仮定しないでください。

<!-- /SYNC:ai-mistake-prevention --> <!-- SYNC:critical-thinking-mindset -->

批判的思考マインドセット — 批判的思考と段階的思考を適用してください。すべての主張には追跡可能な証拠が必要です。信頼度 >80％ で行動してください。 幻覚防止： 推測を事実として提示しないでください。すべての主張のソースを引用し、不確実性を自由に認め、自分の出力の誤りをセルフチェックし、独立して相互参照し、自分の確実性に懐疑的であってください。根拠のない確実性は幻覚のすべての根本です。

<!-- /SYNC:critical-thinking-mindset --> <!-- SYNC:critical-thinking-mindset:reminder -->

注意が必要 です。批判的思考を適用してください。すべての主張には追跡可能な証拠が必要です。信頼度 >80％ で行動してください。幻覚防止：推測を事実として提示しないでください。

<!-- /SYNC:critical-thinking-mindset:reminder --> <!-- SYNC:ai-mistake-prevention:reminder -->

注意が必要 です。AI ミステイク防止を適用してください。総合的デバッグ、責任層での修正、コーディング前のあいまいさの表面化、圧縮後のファイル再読み込み。

<!-- /SYNC:ai-mistake-prevention:reminder -->

終了リマインダー

• 必須 重要 注意が必要 タスク追跡を使用して、開始前に小さな todo タスクに作業を分割してください
• 必須 重要 注意が必要 新しいコードを作成する前に、コードベースで同様のパターンを 3 つ以上検索してください
• 必須 重要 注意が必要 すべての主張に file:line 証拠を引用してください（信頼度 >80％ で行動してください）
• 必須 重要 注意が必要 作業品質を検証するための最終レビュー todo タスクを追加してください

[タスク計画] 行動する前に、タスク範囲を分析し、タスク追跡を使用して小さな todo タスクとサブタスクに体系的に分割してください。

<!-- CODEX:SYNC-PROMPT-PROTOCOLS:START -->

フックレスプロンプトプロトコルミラー（自動同期）

ソース：.claude/hooks/lib/prompt-injections.cjs + .claude/.ck.json

[ワークフロー実行プロトコル] [ブロッキング] ワークフロー実行プロトコル — 必須 重要 必須 重要。どんな理由でもスキップしないでください。

1. 検出： プロンプトをワークフローカタログと照合します
2. 分析： ベストマッチワークフローを見つけ、カスタムステップの組み合わせがより適切であるかどうかを評価します
3. 確認（必須形式）： この構造で直接ユーザー質問を使用します：
   • 質問：「どのワークフローを起動しますか？」
   • オプション 1：「[ベストマッチワークフロー] を起動（推奨）」
   • オプション 2：「カスタムワークフロー起動：[step1 → step2 → ...]」（1 行の根拠を含める）
4. 起動（確認されたら）： 標準の場合は $workflow-start <workflowId> を呼び出します。カスタムステップは手動で順序付けます
5. タスク作成： すべてのワークフローステップのタスク追跡
6. 実行： 各ステップを順序に従います [批判的思考マインドセット] 批判的思考と段階的思考を適用してください。すべての主張には追跡可能な証拠が必要です。信頼度 >80％ で行動してください。 幻覚防止原則： 推測を事実として提示しないでください。すべての主張のソースを引用し、不確実性を自由に認め、自分の出力の誤りをセルフチェックし、独立して相互参照し、自分の確実性に懐疑的であってください。根拠のない確実性は幻覚のすべての根本です。 AI 注意原則（初期性・近期性）： 長いプロンプト/プロトコルの最上部と最下部に 3 つの最も重要なルールを配置し、長いコンテキストウィンドウが命令遵守を生き残るようにします。

学んだ教訓

教訓

[重要] 厳しく学んだプロジェクトデバッグ/アーキテクチャルール。仮説を形成またはコードを書く前に注意が必要です。適用してください。

クイックサマリー

目標： 既知の障害パターンの再発を防止します。デバッグ、アーキテクチャ、命名、AI オーケストレーション、環境。

トップルール（常に適用）：

• 注意が必要です。すべての前提条件（設定、環境、DB 名、DI 登録）をコード層仮説の前に検証してください
• 注意が必要です。責任層を修正してください。呼び出し側固有の防御コードで症状部位にパッチを当てないでください
• 注意が必要です。並列非同期 + リポジトリ/UoW に ExecuteInjectScopedAsync を使用してください。ExecuteUowTask を使用しないでください
• 注意が必要です。コンテンツではなく目的で名前を付けてください。メンバーを追加すると強制的に名前変更 = 破れた抽象化
• 注意が必要です。サブエージェント結果を各ファイル後に段階的に保持してください。最後にバッチで実行しないでください
• 注意が必要です。Windows bash：Python エイリアスを検証してください（where python/where py）。python/python3 が解決することを仮定しないでください

---

デバッグとルート原因推論

• [2026-04-11] 総合的：コードの前に環境を検証してください。 障害 → すべての前提条件（設定、環境変数、DB 名、エンドポイント、DI 登録、認証情報、権限、データ前提条件）をリストします。→ コード層の仮説の前に、証拠を通じて各々を検証します（grep/cat/query）。最悪のウサギの穴：最も近い層に飛び込んでいる間、バグが他の場所にあります。例えば、「同期タイムアウト」のデバッグに数時間。実際の原因：テスト appsettings が間違った DB をポイントしています。常に最も安い確認が最初です。
• [2026-04-01] 修正する前に「誰の責任か」と尋ねてください。 トレース：呼び出し側（データが間違っている）か呼び出し側（処理が間違っている）？責任層で修正してください。症状部位のパッチを当てないでください。実際の問題をマスキングしています。
• [2026-04-01] エラー部位ではなくデータライフサイクルをトレースしてください。 データをフォローしてください：作成 → 変換 → 消費。バグは通常、消費されている場所ではなく、データが間違って作成されている場所にあります。
• [2026-04-01] 呼び出し側がわからないコードを作成してください。 関数/ハンドラー/コンシューマーは誰が呼び出すかを知りません。コメント/ガード/メッセージはビジネス意図を説明します。特定の呼び出し側（テスト、シーダー、スクリプト）を参照しないでください。

アーキテクチャインバリアント

• [2026-05-09] ユーザー名の具体化は User.UpdateName(firstName, middleName, lastName) を通じて実行する必要があります。 ドメインメソッド（src/Services/bravoTALENTS/Employee.Domain/AggregatesModel/User.cs:202-209）は FullName をシングルソース・オブ・トゥルースとして再計算します。3 つのサイトはまだ手動で user.FullName = user.GetFullName() に名前フィールドを割り当てた後にパッチします。src/Services/bravoTALENTS/Employee.Application/Factories/UserFactory.cs:50、src/Services/bravoSURVEYS/LearningPlatform.Application/ApplyPlatform/MessageBus/Consumers/AccountUserDeletedEventBusConsumer.cs:102、src/Services/bravoINSIGHTS/Analyze/Analyze.Application/MessageBus/Consumers/AccountUserDeletedEventBusConsumer.cs:66。次に何かに触れるときは、手動パッチを user.UpdateName(...) に置き換えてインバリアントを保持してください。
• [2026-03-31] 並列非同期 + リポジトリ/UoW は ExecuteInjectScopedAsync を使用する必要があります。ExecuteUowTask を使用しないでください。 ExecuteUowTask は新しい UoW を作成しますが、外部 DI スコープを再利用します（同じ DbContext）。並列反復は非スレッドセーフ DbContext を共有しており、データをサイレントに破損します。ExecuteInjectScopedAsync は新しい UoW + 新しい DI スコープを作成します（反復ごとにフレッシュリポジトリ）。
• [2026-03-31] バスメッセージ命名はサービス名プレフィックスを含める必要があります。コアサービスはフィーチャーイベントを使用しないでください。 プレフィックスはスキーマ所有権を宣言します（AccountUserEntityEventBusMessage = アカウントが所有）。コアサービス（アカウント、コミュニケーション）がリーダーです。フィーチャーサービス（成長、タレント）がコアに送信する場合は、{CoreServiceName}...RequestBusMessage を使用する必要があります。コアが使用する独自のイベントを定義しないでください。

命名と抽象化

• [2026-04-12] 目的でなくコンテンツで名前を付けます。「OrXxx」アンチパターン。 HrManagerOrHrOrPayrollHrOperationsPolicy は名前セットメンバー、ガードするもの。ロール追加 → 名前変更 = 破れた抽象化。ルール： 名前は DOES/GUARDS を表現し、CONTAINS ではありません。テスト： メンバーを追加/削除すると強制的に名前変更？ YES = コンテンツ駆動 = 悪い → 目的に名前を変更（例：HrOperationsAccessPolicy）。ニュアンス： 「Or」は問題ない行動慣用句（FirstOrDefault、SuccessOrThrow）。HAPPENS を表現し、メンバーシップではありません。

環境とツーリング

• [2026-04-20] Windows bash：python/python3 が解決することを仮定しないでください。最初にエイリアスを検証してください。 Python は bash PATH でそれらの名前の下にない可能性があります。確認：where python / where py。常に py（Windows Python Launcher）ワンライナーまたは JS の代替がある場合は node を優先してください。

テスト固有の教訓 → docs/project-reference/integration-test-reference.md 教訓セクション。本番コードのアンチパターン → docs/project-reference/backend-patterns-reference.md アンチパターンセクション。汎用デバッグ/リファクタリングリマインダー → システム教訓 .claude/hooks/lib/prompt-injections.cjs。

---

終了リマインダー

• 重要 注意が必要 総合的：コード層仮説の前にすべての前提条件（設定、環境、DB 名、エンドポイント、DI 登録）を検証してください。最も安い確認が最初です
• 重要 注意が必要 責任層を修正してください。症状部位にパッチを当てないでください。呼び出し側（データが間違っている）対呼び出し側（処理が間違っている）をトレースし、ルート所有者を修正します
• 重要 注意が必要 並列非同期 + リポジトリ/UoW → 常に ExecuteInjectScopedAsync、ExecuteUowTask は不可（共有 DbContext = サイレントデータ破損）
• 重要 注意が必要 バスメッセージプレフィックス = スキーマ所有権。フィーチャーサービスはコアサービスのイベントを定義しない。{CoreServiceName}...RequestBusMessage を使用してください
• 重要 注意が必要 目的で名前を付けます。メンバーを追加/削除すると強制的に名前変更 = 破れた抽象化
• 重要 注意が必要 サブエージェントは各ファイル/セクション後に結果を書く必要があります。すべての結果を 1 つの最終書き込みにバッチで実行しないでください
• 重要 注意が必要 Windows bash：python/python3 が解決することを仮定しないでください。最初に where python/where py を実行し、py ランチャーまたは node を使用してください
• 重要 注意が必要 すべての主張に file:line 証拠が必要です。信頼度 >80％ で行動してください。推測しないでください

[教訓リマインダー] [ブロッキング] タスク計画と継続的改善 — 必須。スキップしないでください。

開始前に小さなタスク（タスク追跡）に作業を分割してください。最終タスク追加：「AI ミステイクと学んだ教訓を分析」。

教訓を抽出 — ルート原因のみ、症状修正ではない：

1. 障害モード に名前を付けてください（推論/仮定障害）、症状ではなく。「ソースを読まずに API が存在すると仮定した」ではなく「間違った列挙値を使用した」。
2. 汎用性テスト： この障害モード≥3 コンテキスト/コードベースに適用されますか？否の場合、1 レベル上に抽象化してください。
3. 普遍的なルールとして書く プロジェクト固有の名前/パス/クラスを削除してください。任意のコードベースで有用です。
4. 統合： 複数のミステイクが 1 つの障害モードを共有 → 1 つの教訓。
5. 再発ゲート： 「このリマインダーなしで将来のセッションでこれが再発しますか？」— いいえ → $learn をスキップしてください。
6. 自動修正ゲート： 「$code-review/$code-simplifier/$security/$lint これを検出できますか？」— はい → 代わりにレビュースキルを改善してください。
7. 両方のゲートを通過 → ユーザーに $learn を実行するよう依頼してください。 [タスク計画] [必須] ワークフローまたはスキルステップを実行する前に、計画されたすべてのステップのタスク追跡を作成/更新し、各ステップが開始/完了するにつれて同期を保ってください。

<!-- CODEX:SYNC-PROMPT-PROTOCOLS:END -->