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 -->

クイックサマリー

目標: Markdown ファイルを GFM サポートと適切なフォーマット付きで Microsoft Word (.docx) 形式に変換します。

ワークフロー:

1. インストール -- pandoc が利用可能であることを確認します (必須依存関係)
2. 変換 -- docx 出力で pandoc を実行し、テンプレートが提供されている場合は参照テンプレートを適用します
3. 検証 -- 出力ファイルがフォーマット忠実度をチェックします

主要ルール:

• システムにインストールされた pandoc が必要です
• GFM テーブル、コードブロック、画像をサポートします
• カスタムスタイリングのためのオプションの reference.docx テンプレート

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

markdown-to-docx

テーブル、コードブロック、画像、LaTeX 数式方程式のサポート付きで、Markdown ファイルを編集可能な Microsoft Word ドキュメントに変換します。

インストール必須

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

# オプション 1: ClaudeKit CLI (推奨)
ck init

# オプション 2: 手動
cd .claude/skills/markdown-to-docx
npm install

依存関係: markdown-docx, gray-matter

クイックスタート

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

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

# カスタムテーマ付き
node .claude/skills/markdown-to-docx/scripts/convert.cjs -i ./doc.md --theme ./theme.json

CLI オプション

オプション	短縮	説明	デフォルト
--input	-i	入力 markdown ファイル	(必須)
--output	-o	出力 DOCX パス	{input}.docx
--theme	-t	カスタムテーマ JSON	ビルトイン
--title		ドキュメントタイトル	ファイル名
--help	-h	ヘルプを表示

機能

• GFM サポート: テーブル、打ち消し線、タスクリスト
• コードブロック: モノスペースフォント付きで構文を保持
• 画像: ローカル画像と URL 画像を埋め込み
• 数式: デフォルトでレンダリングされた LaTeX 方程式 ($...$, $$...$$)
• フロントマター: YAML メタデータをタイトルとして抽出
• システム依存関係なし: 純粋な JavaScript、Chrome が不要

出力

成功時に JSON を返します:

{
    "success": true,
    "input": "/path/to/input.md",
    "output": "/path/to/output.docx"
}

互換性

生成された DOCX ファイルは以下で動作します:

• Microsoft Word (2007 以降)
• Google Docs (Drive にアップロード)
• LibreOffice Writer
• Apple Pages

---

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

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

AI 誤り防止 — すべてのタスクで避けるべき失敗パターン: 削除前に下流参照をチェック。 コンポーネント削除はドキュメントとコード陳腐化のカスケードを引き起こします。削除前に、すべての参照ファイルをマップしてください。 実際のコードに対して AI 生成コンテンツを検証。 AI は API、クラス名、メソッドシグネチャを幻視します。ドキュメント化または参照する前に、grep で存在を常に確認してください。 編集後の全依存関係チェーンをトレース。 定義を変更すると、それから派生した下流変数とコンシューマーが見落とされます。常に完全なチェーンをトレースしてください。 正確性を検証する際にすべてのコードパスをトレース。 コード存在の確認は実行確認ではありません。常に早期終了、エラーブランチ、条件スキップをトレースしてください — ハッピーパスだけでなく。 デバッグ時に「誰の責任か?」と尋ねてください。 呼び出し元 (データ誤り) か被呼び出元 (処理誤り) かをトレースしてください。責任のあるレイヤーで修正してください — 症状の箇所にパッチを当てないでください。 既存の値は意図的であると想定してください — 変更前に理由を尋ねてください。 定数、制限、フラグ、またはパターンを変更する前に: コメントを読み、git blame を確認し、周囲のコードを調査してください。 最初の結果だけでなく、すべての影響を受ける出力を検証。 複数のスタックに触れる変更には、ALL 出力の検証が必要です。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 登録) を検証
• 注意が必要です 責任のあるレイヤーで修正 — 呼び出し元固有の防御的なコードで症状の箇所にパッチを当てない
• 注意が必要です 並列 async + リポジトリ/UoW については ExecuteInjectScopedAsync を使用 — ExecuteUowTask を使用しない
• 注意が必要です 内容ではなく目的で命名 — メンバーを追加すると強制的に名前変更 = 抽象化破損
• 注意が必要です サブエージェントの検索結果を各ファイル後に増分で永続化 — 最後にバッチで永続化しない
• 注意が必要です Windows bash: Python エイリアスを検証 (where python/where py) — python/python3 が解決すると想定しない

---

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

• [2026-04-11] 全体像優先: コードの前に環境を検証。 失敗 → すべての前提条件 (設定、環境変数、DB 名、エンドポイント、DI 登録、資格情報、権限、データ前提条件) をリスト → 各々を証拠 (grep/cat/クエリ) で検証してからコード層仮説を形成. 最悪のウサギ穴: 最も近いレイヤーをデバッグしながら、バグが他のどこかにある場合 — 例: 数時間「同期タイムアウト」をデバッグしているのに、本当の原因はテスト 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] 並列 async + リポジトリ/UoW は ExecuteInjectScopedAsync を使用する必要があります 注意が必要です。ExecuteUowTask を使用しないでください。 ExecuteUowTask は新しい UoW を作成しますが、外側の DI スコープを再使用します (同じ DbContext) — 並列反復が非スレッドセーフな DbContext を共有して、データを暗黙的に破損させます。ExecuteInjectScopedAsync は新しい UoW + 新しい DI スコープ (反復ごとに新しいリポジトリ) を作成します。
• [2026-03-31] バス メッセージ命名はサービス名プレフィックスを含める必要があります 注意が必要です — コア サービスは機能イベントを消費しません。 プレフィックス スキーマ所有権を宣言 (AccountUserEntityEventBusMessage = Accounts が所有). コア サービス (Accounts, Communication) がリーダー. 機能サービス (Growth, Talents) からコアに送信する場合 {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) ワンライナー、JavaScript の代替がある場合は node を優先してください.

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

---

最後のリマインダー

• 重要 注意が必要です 全体像優先: コード層仮説の前にすべての前提条件 (設定、環境、DB 名、エンドポイント、DI 登録) を検証 — 最も安価なチェックを最初に
• 重要 注意が必要です 責任のあるレイヤーで修正 — 症状の箇所にパッチを当てない; 呼び出し元 (データ誤り) vs 被呼び出元 (処理誤り) をトレース、ルート所有者で修正
• 重要 注意が必要です 並列 async + リポジトリ/UoW → 常に ExecuteInjectScopedAsync、ExecuteUowTask を使用しない (共有 DbContext = サイレント データ破損)
• 重要 注意が必要です バス メッセージ プレフィックス = スキーマ所有権; 機能サービスはコア サービス用のイベントを定義しない — {CoreServiceName}...RequestBusMessage を使用
• 重要 注意が必要です 目的で命名 — メンバーの追加/削除で強制的に名前変更 = 破損した抽象化
• 重要 注意が必要です サブエージェントは各ファイル/セクション後に検査結果を記述する必要があります — すべての検査結果を 1 つの最終書き込みにバッチしない
• 重要 注意が必要です Windows bash: python/python3 が解決すると想定しない — 最初に where python/where py を実行、py ランチャーまたは node を使用
• 重要 注意が必要です すべての主張は file:line 証拠が必要 — 信頼度 >80% で実行、推測しない

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

開始前に作業を小さなタスク (タスク追跡) に分割してください。最終タスクを追加: 「AI の誤りと学習した教訓を分析」。

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

1. 失敗モード (推論/想定失敗) に名前を付け、症状ではなく — 「ソースを読まずに API が存在すると想定」ではなく「間違った enum 値を使用」.
2. 汎化テスト: この失敗モード ≥3 のコンテキスト/コードベースに適用できますか? いいえ → 1 レベル上に抽象化.
3. ユニバーサル ルールとして記述 — プロジェクト固有の名前/パス/クラスをストリップ. 任意のコードベースで有用.
4. 統合: 複数の誤りが 1 つの失敗モードを共有 → 1 つのレッスン.
5. 再発ゲート: 「このセッションなしでこの失敗モードが将来再発しますか? WITHOUT このリマインダー?」 — いいえ → $learn をスキップ.
6. 自動修正ゲート: 「$code-review/$code-simplifier/$security/$lint がこれをキャッチできますか?」 — はい → レビュー スキルを改善してください代わりに.
7. 両方のゲート合格 → ユーザーに $learn を実行するよう尋ねてください. [タスク計画] [必須] ワークフローまたはスキル ステップを実行する前に、すべての計画されたステップのタスク追跡を作成/更新し、各ステップが開始/完了するたびにそれを同期に保ってください.

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