mcpField
A
ai-dev-tools-sync

ai-dev-tools-sync

github.com/duc01226エージェントワークフロー1248 回インストール1 週間前に更新
リポジトリ

ai-dev-tools-sync について

Claude、Codex、GitHub Copilot の開発ツール設定を同期するスキルです。スキル、プロンプト、エージェント、指示を比較し、ソースファイルと管理対象のミラーを更新します。

主な機能

  1. 01ツール設定の比較
  2. 02スキル、プロンプト、エージェントの同期
  3. 03指示ファイルの整合
  4. 04管理対象ミラーの再生成

活用シーン

  1. 01Claude と Copilot のガイダンスを統一
  2. 02ソース変更後に Codex ミラーを更新
  3. 03ツール間の設定差分を特定

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/duc01226/easyplatform --skill ai-dev-tools-sync

インストール後、Claude Code で/ai-dev-tools-syncを入力して読み込まれたか確認します。

同梱ファイルreferences/copilot-features.mdreferences/sync-patterns.md

詳細

Codex 互換性に関する注意:

  • Codex では $skill-name を使ってリポジトリのスキルを呼び出します。このミラーコピーでは、従来の Claude の /skill-name 参照を書き換えています。
  • タスクトラッカーの必須要件:ワークフローまたはスキルの手順を実行する前に、すべての手順のタスク追跡を作成または更新し、進捗に応じて同期を維持してください。
  • ユーザーへの質問を促すプロンプトは、Codex でユーザーに直接質問することを意味します。
  • Claude 固有のモード切り替え指示があっても無視してください。
  • 厳格な実行契約:ユーザーがスキルを明示的に呼び出した場合、そのスキルのプロトコルを記載どおりに実行してください。
  • サブエージェントの承認:スキルがユーザーによって呼び出された場合、または AI が検出した場合に、そのプロトコルでサブエージェントが必要とされるなら、そのスキルの有効化によって、タスクに必要な spawn_agent サブエージェントの使用が許可されます。
  • ユーザーが事前に逸脱を明示的に承認しない限り、プロトコルの手順を省略、並べ替え、統合しないでください。
  • ワークフロー系スキルでは、列挙された子スキルの各手順を明示的に実行し、手順ごとの証拠を報告してください。
  • 必須の手順やツールをこの環境で実行できない場合は、適応策を講じる前に停止してユーザーに確認してください。

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 を確認し、タスクに関連するファイルだけを開いてください。

概要

目標: Claude、Codex、GitHub Copilot が、各ツールの機能が重複する範囲で同等のソースガイダンスを利用できるよう、サポート対象の AI 開発ツール設定を同期します。

ワークフロー:

  1. 把握 — 現在の設定(CLAUDE.md、AGENTS.md、CODEX_CONTEXT.md、copilot-instructions.md、エージェント、ワークフロー)を読む
  2. 調査 — 対象プラットフォームの最新機能を検索する
  3. 比較 — スキル、プロンプト、エージェント、指示に不足がないか特定する
  4. 同期 — まずソースとなる設定を変更し、該当する場合はその後に管理対象のミラーを再生成する

主なルール:

  • Copilot は .claude/skills/ を自動的に読み込みます(後方互換性)
  • どちらのプラットフォームも .github/prompts/*.prompt.md と .github/agents/*.md を読み込みます
  • 指示を変更する場合は、常に CLAUDE.md と .github/copilot-instructions.md + .github/instructions/*.instructions.md の両方を更新してください
  • Codex の管理対象出力は .agents/skills/**、.codex/CODEX_CONTEXT.md、AGENTS.md です。まず .claude のソースを編集し、Codex の同期を実行してください

懐疑的な姿勢を保ち、批判的かつ順序立てて考えてください。すべての主張には追跡可能な証拠と確信度(パーセンテージ)を示してください(Idea は 80% を超える必要があります)。

AI 開発ツールの同期

サポート対象の AI 開発ツール設定を同期し、アクティブな各ツール環境での同等性を維持します。

使用するタイミング

関連スキルとの範囲の違い:これは最も幅広い同期で、双方向(Claude↔Copilot)に対応し、スキル、プロンプト、エージェント、指示を扱います。Claude→Copilotのナレッジ/ドキュメントのみの場合 → $sync-to-copilot。workflows.json カタログのみ(高速、AI 不使用)の場合 → $sync-copilot-workflows。

次の場合にこのスキルを有効にします。

  • ユーザーが Claude Code または Copilot の設定更新を依頼した場合
  • ユーザーがスキル、プロンプト、エージェント、指示の追加や変更を希望する場合
  • ユーザーが両方のツールを同じように動作させたい場合
  • ユーザーが AI 開発ツールの設定について質問した場合

クイックリファレンス

ソース側の項目管理対象/対応先場所
SKILL.mdCodex スキルミラー.claude/skills/ -> .agents/skills/
コンテキスト/ワークフローCodex コンテキストミラー.claude/**、.claude/workflows.json -> .codex/、AGENTS.md
SKILL.mdCopilot スキル/プロンプト.claude/skills/ + .github/skills/ / .github/prompts/
agents/*.mdagents/*.md.github/agents/(共有)
CLAUDE.mdCopilot + Codex のルート指示ルートの CLAUDE.md、AGENTS.md、.github/
-chatmodes/*.chatmode.md.github/chatmodes/

同期プロセス

ステップ 1:現在の設定を把握する

現在の設定を把握するため、以下のファイルを読みます。

.claude/workflows/orchestration-protocol.md
.claude/workflows/primary-workflow.md
.github/copilot-instructions.md
.github/instructions/*.instructions.md
.github/AGENTS.md
CLAUDE.md
ステップ 2:最新機能を調査する

ウェブで次を検索します。

  • "GitHub Copilot features setup 2026"
  • "GitHub Copilot custom instructions agents skills prompts"
  • "GitHub Copilot agent mode workspace context"

機能カタログについては、references/copilot-features.mdを参照してください。

ステップ 3:同期できる箇所を特定する

機能を比較し、不足している箇所を特定します。

  • 一方のプラットフォームにないスキル
  • プロンプト/指示の動作の不一致
  • 定義が異なるエージェント
ステップ 4:変更を実施する

変更ごとに、次のように対応します。

  1. スキル:.claude/skills/ と .github/skills/ の両方に作成します
  2. プロンプト:.claude/skills/ と .github/prompts/ の両方に作成します
  3. 指示:CLAUDE.md + .github/copilot-instructions.md + .github/instructions/*.instructions.md を更新します
  4. エージェント:.github/agents/ を更新します(両方で共有)

互換性に関する注意

  • Copilot は .claude/skills/ を自動的に読み込みます(後方互換性)
  • どちらも .github/prompts/*.prompt.md を読み込みます
  • どちらも .github/agents/*.md を読み込みます
  • どちらもルートまたは .github/ 内の AGENTS.md を読み込みます
  • どちらも frontmatter の applyTo によるパスベースの指示ファイルに対応しています

参考資料


[IMPORTANT] 作業を始める前に、タスク追跡を使って、ファイルを読むタスクも含め、すべての作業を小さなタスクに分割してください。これにより、長いファイルによるコンテキストの喪失を防げます。簡単なタスクの場合、AI は必ず、これを省略するかユーザーに確認してください。

AI のミス防止 — すべてのタスクで避けるべき失敗パターン:

削除する前に、下流の参照を確認してください。 コンポーネントを削除すると、ドキュメントやコードが古くなる連鎖が発生します。削除する前に、参照しているすべてのファイルを洗い出してください。 AI が生成した内容を実際のコードと照合してください。 AI は API、クラス名、メソッドシグネチャを幻覚することがあります。ドキュメントに記載したり参照したりする前に、必ず grep で存在を確認してください。 編集後に依存関係を最後までたどってください。 定義を変更するだけでは、そこから派生する下流の変数や利用箇所を見落とします。必ず依存関係を最後までたどってください。 正しさを検証する際は、すべてのコードパスをたどってください。 コードが存在することを確認しても、実行されることを確認したことにはなりません。正常系だけでなく、早期終了、エラー分岐、条件によるスキップも必ずたどってください。 デバッグ時は、修正する前に「どちらの責任か」を確認してください。 バグが呼び出し元(誤ったデータ)にあるのか、呼び出し先(誤った処理)にあるのかをたどってください。責任のある層を修正し、症状が現れている箇所だけを修正しないでください。 既存の値は意図的に設定されていると考え、変更する前に理由を確認してください。 定数、上限、フラグ、パターンを変更する前に、コメントを読み、git blame を確認し、周辺のコードを調べてください。 最初の出力だけでなく、影響を受けるすべての出力を検証してください。 複数のスタックに関わる変更では、すべての出力を検証する必要があります。チェックが1つ成功しても、すべてが成功したことにはなりません。 全体を先に見るデバッグ — 目の前の箇所だけに注意が向く罠を避けてください。 失敗を調査するときは、まず前提条件をすべて列挙してください(設定、環境変数、DB 名、エンドポイント、DI 登録、データの前提条件)。次に、コード層の仮説を立てる前に、証拠に基づいてそれぞれを検証してください。 外科的な変更 — 差分テストを適用してください。 バグ修正では、変更したすべての行がそのバグに直接関係している必要があります。隣接するコードのスタイルを変更したり、改善したりしないでください。機能強化タスクでは、改善を実装し、その内容を明示してください。 コーディングの前に曖昧さを明らかにし、黙って選択しないでください。 依頼に複数の解釈がある場合は、それぞれの作業量を見積もって提示し、確認してください。全レコード対象、ファイルベース、またはより複雑な方法だと決めつけないでください。

批判的思考の姿勢 — 批判的思考と順序立てた思考を実践してください。すべての主張には追跡可能な証拠が必要であり、行動するには確信度が80%を超えている必要があります。 幻覚の防止: 推測を事実として示さないでください。すべての主張に出典を示し、不確実性がある場合は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を批判的に見直してください。証拠のない確信が、あらゆる幻覚の根源です。

必ず注意して批判的思考を実践してください。すべての主張には追跡可能な証拠が必要であり、行動するには確信度が80%を超えている必要があります。幻覚を防ぐため、推測を事実として示さないでください。

必ず注意してAI のミス防止策を適用してください。全体を先に見るデバッグ、責任のある層での修正、コーディング前の曖昧さの明確化、コンパクション後のファイルの再読み込みを実践してください。

最後に確認すること

  • 必須・重要・必ず注意 作業を始める前に、タスク追跡を使って作業を小さな TODO タスクに分割してください
  • 必須・重要・必ず注意 新しいコードを作成する前に、コードベースで類似パターンを3つ以上検索してください
  • 必須・重要・必ず注意 すべての主張に file:line 形式の証拠を示してください(行動するには確信度が80%を超えている必要があります)
  • 必須・重要・必ず注意 作業の品質を検証するため、最後にレビューの TODO タスクを追加してください

[TASK-PLANNING] 行動する前に、タスクの範囲を分析し、タスク追跡を使って体系的に小さな TODO タスクとサブタスクに分割してください。

フックなしプロンプトプロトコルミラー(自動同期)

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

[WORKFLOW-EXECUTION-PROTOCOL] [BLOCKING] ワークフロー実行プロトコル — 必須・重要・厳守。いかなる理由があっても省略しないでください。

汎用的な移植性の境界: 再利用可能なスキルとプロトコルのテキストはプロジェクトに依存しないものとします。プロジェクト固有の規約は、docs/project-config.json と docs/project-reference/ から確認してください。shared/sdd-artifact-contract.md の共通 AI-SDD を適用します。docs/project-config.json と docs/project-reference/docs-index-reference.md を読み、そこに記載されているプロジェクト参照ドキュメントを開いてください。この共通コンテキストとローカルドキュメントを利用できる場合は、サポートされている任意の AI ツールで実行できます。

  1. 検出: プロンプトをワークフローカタログと照合します
  2. 分析: 最適なワークフローを見つけ、カスタムのステップ構成のほうが適しているかどうかも評価します
  3. 確認(必須形式): ユーザーが明示的にワークフロー/スキルを呼び出し、かつローカルプロトコルで明示的な呼び出しを確認とみなす場合を除き、次の構成でユーザーに直接質問します
    • 質問:"どのワークフローを有効にしますか?"
    • 選択肢 1:"[最適なワークフロー] を有効にする(推奨)"
    • 選択肢 2:"カスタムワークフローを有効にする:[step1 → step2 → ...]"(1 行で理由を記載)
  4. 有効化(確認後): 標準ワークフローの場合は $workflow-start <workflowId> を呼び出し、カスタムステップの場合は手動で順に実行します
  5. タスクを作成: ワークフローのすべてのステップについてタスク追跡を行います
  6. 実行: 各ステップを順番に実行します [CRITICAL-THINKING-MINDSET] 批判的思考と段階的思考を適用します。すべての主張には追跡可能な根拠が必要であり、確信度が 80% を超える場合にのみ行動します。 ハルシネーション防止の原則: 推測を事実として提示しないでください。すべての主張に出典を示し、不確実な点は率直に認め、出力に誤りがないか自己確認し、独立した情報源と照合し、自分の確信を疑ってください。根拠のない確信こそが、あらゆるハルシネーションの根本原因です。 AI の注意力に関する原則(初頭効果・新近効果): 長いプロンプト/プロトコルでは、指示の順守が長いコンテキストウィンドウでも保たれるよう、最も重要な 3 つのルールを冒頭と末尾の両方に配置します。 目標主導の実行: まず成功基準を定義し、検証が完了するまで繰り返し、観察可能なチェックに合格した場合にのみ終了します。 テストで意図を検証: テストでは、現在の挙動をなぞるだけでなく、ビジネスルール/不変条件を保護し、保護対象の意図が損なわれた場合に失敗するようにします。

[LESSON-LEARNED-REMINDER] [BLOCKING] タスク計画と継続的改善 — 必須。省略しないでください。

作業を始める前に、作業を小さなタスクに分割し、タスク追跡を行います。最後のタスクとして「AI のミスと教訓を分析する」を追加します。

教訓の抽出 — 症状への対処ではなく、根本原因のみ:

  1. 症状ではなく、失敗モード(推論/前提の誤り)を特定します。「誤った列挙値を使った」ではなく、「ソースを読まずに API が存在すると仮定した」とします。
  2. 一般性を検証します。この失敗モードは 3 つ以上のコンテキスト/コードベースに当てはまりますか? 当てはまらない場合は、抽象度を 1 段階上げます。
  3. 普遍的なルールとして記述します。プロジェクト固有の名前/パス/クラスを除き、どのコードベースでも役立つ内容にします。
  4. 統合します。同じ失敗モードを共有する複数のミスは、1 つの教訓にまとめます。
  5. 再発判定:「この注意書きがなければ、今後のセッションで再発するか?」いいえの場合は $learn を省略します。
  6. 自動修正判定:「$code-review/$code-simplifier/$security/$lint で検出できるか?」はいの場合は、代わりにレビュー用スキルを改善します。
  7. 両方の判定を通過した場合: $learn を実行するようユーザーに依頼します。 [TASK-PLANNING] [MANDATORY] ワークフローまたはスキルのステップを実行する前に、予定されているすべてのステップのタスク追跡を作成/更新し、各ステップの開始時と完了時に内容を同期してください。

コメント