Codex互換性に関する注意:

• リポジトリスキルはCodexで $skill-name で呼び出します。このミラーコピーはレガシーな Claude /skill-name 参照を書き換えます。
• このCodexミラーの計画ガイダンスには plan-hard スキルを優先的に使用してください。
• タスクトラッカー委任: ワークフロー或いはスキルステップを実行する前に、全ステップのタスク追跡を作成/更新し、進捗に応じて同期を保ってください。
• ユーザー質問プロンプトはCodexでユーザーに直接質問することを意味します。
• Claude固有のモード切り替え命令が現れた場合は無視してください。
• 厳密な実行契約: ユーザーが明示的にスキルを呼び出した場合、そのスキルプロトコルを書かれた通りに実行してください。
• サブエージェント認可: スキルがユーザー呼び出しまたはAI検出され、そのプロトコルがサブエージェントを必要とする場合、そのスキル起動は必要な spawn_agent サブエージェント(複数可)の使用を当該タスクのために認可します。
• プロトコルステップをスキップ、並び替え、マージしないでください。ユーザーが明示的に偏差を事前に承認した場合を除きます。
• ワークフロースキルの場合、リストされた各子スキルステップを明示的に実行し、ステップごとの証拠をレポートしてください。
• 必要なステップ/ツールがこの環境で実行できない場合は、適応する前に停止してユーザーに確認してください。

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

Codexプロジェクト参照ローディング (フック無し)

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

常に読むべき項目:

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

クイックサマリー

目的: シンタックスハイライトとカスタムCSS対応でマークダウンファイルをPDFに変換する。

ワークフロー:

1. インストール -- 必要なツール (pandoc + wkhtmltopdf または weasyprint) が利用可能か確認する
2. 変換 -- シンタックスハイライトとオプションのCSSで変換を実行する
3. 検証 -- PDFの出力をフォーマットと完全性について確認する

重要ルール:

• pandoc + PDFエンジン (wkhtmltopdf または weasyprint) が必要です
• コードブロックのシンタックスハイライトをサポート
• スタイリング用のカスタムCSSを適用可能

懐疑的に、批判的思考と段階的思考を適用してください。すべての主張には証拠のトレースが必要で、信頼度は80%以上である必要があります。

markdown-to-pdf

コードシンタックスハイライトとカスタムCSS対応で、マークダウンファイルを高品質なPDFドキュメントに変換します。

インストール必須

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

# オプション1: ClaudeKit CLIでインストール (推奨)
ck init  # install.shを実行し、すべてのスキルを処理します

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

依存関係: md-to-pdf, gray-matter

注: 初回実行時は、システムChromeが検出されない限り、Chromium (~150MB) をダウンロードする場合があります。

クイックスタート

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

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

# カスタムCSSを使用
node .claude/skills/markdown-to-pdf/scripts/convert.cjs --input ./doc.md --css ./my-style.css

CLIオプション

オプション	短形	説明	デフォルト
--input	-i	入力マークダウンファイルパス	(必須)
--output	-o	出力PDFファイルパス	{input}.pdf
--css	-c	カスタムCSSファイルパス	内蔵
--no-highlight		シンタックスハイライトを無効化	false
--help	-h	ヘルプメッセージを表示

機能

• シンタックスハイライト: highlight.jsでレンダリングされたコードブロック
• カスタムCSS: デフォルトスタイルを独自のCSSで上書き
• クロスプラットフォーム: Windows、macOS、Linuxで動作
• システムChrome: 利用可能な場合、インストール済みChrome/Chromiumを使用
• フロントマター対応: YAMLフロントマターをタイトル/メタデータ用に抽出

デフォルトスタイリング

デフォルトのPDFスタイルには以下が含まれます:

• 本文用セリフフォント (Georgia)
• コード用モノスペースフォント (Consolas/Monaco)
• 適切なページマージン (2cm)
• コードブロック背景ハイライト
• テーブルの枠線と交互行色

出力

成功時にJSONを返す:

{
    "success": true,
    "input": "/path/to/input.md",
    "output": "/path/to/output.pdf",
    "pages": 3
}

トラブルシューティング

Chromeが見つからない: スキルは自動的にChromiumをダウンロードします。PUPPETEER_SKIP_DOWNLOAD=1 を設定してこれを防ぎます。

メモリ問題: 大規模なドキュメントはより多くのメモリが必要な場合があります。複数のファイルに分割することを検討してください。

フォントの問題: CSSで base64エンコードされたフォントを使用して @font-face でフォントを埋め込み、一貫したレンダリングを実現します。

---

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

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

AI間違い防止 — すべてのタスクで回避すべき失敗モード: 削除前に下流参照を確認してください。 コンポーネント削除はドキュメントとコードの陳腐化カスケードを引き起こします。削除前にすべての参照ファイルをマップしてください。 AI生成コンテンツを実際のコードに照らして検証してください。 AIはAPI、クラス名、メソッドシグネチャを幻覚化します。ドキュメント化または参照する前に、常にgrepで存在を確認してください。 編集後に完全な依存関係チェーンをトレースしてください。 定義を変更すると、それから派生した下流変数と消費者をミスします。常に完全なチェーンをトレースしてください。 正確性を検証する際にはすべてのコードパスをトレースしてください。 コードが存在することを確認することは、それが実行されることを確認することではありません。常に早期終了、エラーブランチ、条件付きスキップをトレースしてください — 正常系だけでなく。 デバッグ時に「誰の責任か?」と尋ねてから修正してください。 バグが呼び出し元 (誤ったデータ) か被呼び出し側 (誤った処理) にあるかをトレースしてください。責任レイヤーで修正してください — 症状発生地を決してパッチしないでください。 既存値が意図的であると仮定してください — 変更前にWHYを聞いてください。 定数、制限、フラグ、またはパターンを変更する前に: コメントを読み、gitblameをチェックし、周辺コードを検査してください。 最初のものだけでなく、すべての影響を受ける出力を検証してください。 複数のスタックに触れる変更は、すべての出力を検証する必要があります。1つのチェック成功は全てが成功していることではありません。 全体的なデバッグ — 最も近い注意の罠に抵抗してください。 失敗を調査するとき、最初にすべての前提条件をリストしてください (設定、環境変数、DBNames、エンドポイント、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 orchestration、環境。

トップルール (常に適用):

• 注意が必要です すべての前提条件 (設定、環境、DB名、DI登録) を検証してからコード層の仮説を立てる
• 注意が必要です 責任レイヤーを修正してください — 症状発生地を呼び出し元固有の防守コードで決してパッチしないでください
• 注意が必要です 並列非同期 + repo/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] 並列非同期 + repo/UoW は ExecuteInjectScopedAsync を使用する必要があります 注意が必要です、決して ExecuteUowTask を使用しないでください。 ExecuteUowTask は新しい UoW を作成しますが、外側のDI スコープを再利用します (同じDbContext) — 並列反復が非スレッドセーフな DbContext を共有し、黙ってデータを破損させます。ExecuteInjectScopedAsync は新しい UoW + 新しいDI スコープを作成します (反復あたりの新鮮なrepo)。
• [2026-03-31] バスメッセージ命名は服務名プレフィックスを含める必要があります 注意が必要です — コアサービスは機能イベントを決して消費しません。 プレフィックスはスキーマ所有権を宣言します (AccountUserEntityEventBusMessage = Accounts所有)。コアサービス (Accounts、Communication) はリーダーです。機能サービス (Growth、Talents) がコアに送信する場合、{CoreServiceName}...RequestBusMessage を使用する必要があります 注意が必要です — コアが消費する独自のイベントを定義しないでください。

命名と抽象化

• [2026-04-12] コンテンツではなく目的で命名してください — "OrXxx"アンチパターン。 HrManagerOrHrOrPayrollHrOperationsPolicy は集合メンバーを命名します、何を保護するかではなく。ロールを追加 → 名前変更を強制 = 破損した抽象化。ルール: 名前はDOES/GUARDS を表現します、CONTAINS ではなく。テスト: メンバーを追加/削除すると強制名前変更ですか? はい = コンテンツ駆動 = 悪い → 目的に名前変更してください (例: 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登録) を検証してください — 最も安い確認を最初に
• 重要 注意が必要です 責任レイヤーを修正してください — 症状サイトを決してパッチしないでください; 呼び出し元 (誤ったデータ) vs被呼び出し側 (誤った処理) をトレースし、ルート所有者を修正してください
• 重要 注意が必要です 並列非同期 + repo/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. 再発ゲート: 「このリマインダーなしで将来のセッションでこれは再発しますか?」 — いいえ → $learn をスキップしてください。
6. 自動修正ゲート: 「$code-review/$code-simplifier/$security/$lint がこれをキャッチできますか?」 — はい → レビュースキルを改善してください。
7. 両方のゲートを通す → ユーザーに $learn の実行を求めてください。 [タスク計画] [必須] ワークフロー或いはスキルステップを実行する前に、計画されたすべてのステップのタスク追跡を作成/更新し、その後各ステップが開始/完了するにつれて同期を保ってください。

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