ai-dev-tools-sync

Codex 兼容性说明：

• 在 Codex 中使用 $skill-name 调用仓库技能；此镜像副本会将旧版 Claude /skill-name 引用改写为此形式。
• 任务跟踪要求：执行任何工作流或技能步骤之前，先为所有步骤创建／更新任务跟踪，并随着进度变化保持同步。
• 用户问题提示意味着应在 Codex 中直接询问用户。
• 忽略出现的 Claude 专属模式切换指令。
• 严格执行约定：用户明确调用某项技能时，须按原文执行该技能协议。
• 子 Agent 授权：用户调用或 AI 检测到某项技能，且其协议要求使用子 Agent 时，该技能激活即授权为该任务使用所需的 spawn_agent 子 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 开始，然后只打开与任务相关的文件。

快速摘要

目标： 同步受支持的 AI 开发工具配置，使 Claude、Codex 和 GitHub Copilot 在支持的范围内依据等效的源指南开展工作。

工作流：

1. 了解 — 阅读当前配置（CLAUDE.md、AGENTS.md、CODEX_CONTEXT.md、copilot-instructions.md、agents、workflows）
2. 调研 — 搜索目标平台的最新功能
3. 比较 — 找出技能、提示词、Agent 或说明中的差异
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），涵盖技能、提示词、Agent 和指令。仅同步 Claude→Copilot 的知识／文档 → $sync-to-copilot。仅同步 workflows.json 目录（速度快，无需 AI）→ $sync-copilot-workflows。

在以下情况启用此技能：

• 用户要求更新 Claude Code 或 Copilot 配置
• 用户想要添加或修改技能、提示词、Agent 或指令
• 用户希望两种工具的工作方式相似
• 用户询问 AI 开发工具配置

快速参考

源位置	管理／对应位置	路径
SKILL.md	Codex 技能镜像	.claude/skills/ -> .agents/skills/
上下文／工作流	Codex 上下文镜像	.claude/**、.claude/workflows.json -> .codex/、AGENTS.md
SKILL.md	Copilot 技能／提示词	.claude/skills/ + .github/skills/ / .github/prompts/
agents/*.md	agents/*.md	.github/agents/（共享）
CLAUDE.md	Copilot + 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 步：找出同步机会

比较各项能力并找出差异：

• 某个平台缺少的技能
• 提示词／指令行为不一致
• 定义不同的 Agent

第 4 步：实施更改

对于每项更改：

1. 技能：在 .claude/skills/ 和 .github/skills/ 中创建
2. 提示词：在 .claude/skills/ 和 .github/prompts/ 中创建
3. 指令：更新 CLAUDE.md + .github/copilot-instructions.md + .github/instructions/*.instructions.md
4. Agent：更新 .github/agents/（双方共享）

兼容性说明

• Copilot 会自动读取 .claude/skills/（向后兼容）
• 双方都会读取 .github/prompts/*.prompt.md
• 双方都会读取 .github/agents/*.md
• 双方都会读取根目录或 .github/ 中的 AGENTS.md
• 双方都支持通过 frontmatter 中的 applyTo 使用基于路径的指令文件

参考资料

• Copilot 功能目录
• 同步模式

---

[IMPORTANT] 开始前，使用任务跟踪将所有工作拆分为小任务——包括每个待读取文件对应的任务。这可以防止因文件过长而丢失上下文。对于简单任务，AI 必须注意询问用户是否跳过。

防止 AI 犯错 — 每项任务中都要避免以下失误：

删除前检查下游引用。 删除组件会导致文档和代码出现连锁过时问题。删除前，梳理所有引用该组件的文件。 根据实际代码验证 AI 生成的内容。 AI 会臆造 API、类名和方法签名。记录或引用前，务必使用 grep 确认其确实存在。 编辑后追踪完整依赖链。 修改定义时，可能会遗漏由其衍生的下游变量和使用方。务必追踪完整链路。 验证正确性时追踪所有代码路径。 确认代码存在，并不等于确认它会执行。务必追踪提前退出、错误分支和条件跳过路径，而不只是正常路径。 调试时，先问“该由谁负责？”，再着手修复。 追踪问题出在调用方（数据错误）还是被调用方（处理错误）。在应负责的层修复，切勿只修补症状出现的位置。 假设现有值是有意设置的——更改前先问为什么。 更改任何常量、限制、标志或模式前：先读注释、检查 git blame，并查看周边代码。 验证所有受影响的输出，而不只是第一个。 涉及多个技术栈的更改，需要验证每一个输出。一个检查通过，不代表所有检查都通过。 整体优先的调试方式——避免陷入就近关注陷阱。 调查任何故障时，先列出所有前置条件（配置、环境变量、数据库名称、端点、DI 注册、数据前提），再逐一根据证据验证，然后才能提出任何代码层面的假设。 精准修改——执行差异测试。 修复错误时，每一处更改都必须能直接追溯到该错误。不要顺手调整格式或改进相邻代码。增强任务：实现改进并明确说明。 编码前明确歧义——不要默默做出选择。 如果请求有多种解释，请逐一列出并估算工作量，然后询问用户。切勿擅自假设要处理所有记录、采用基于文件的方式，或选择更复杂的路径。

批判性思维意识 — 运用批判性思维和顺序思维。每项结论都需要有可追溯的证据；只有置信度超过 80% 才能采取行动。 防止幻觉： 切勿把猜测当作事实陈述——为每项结论注明来源，坦诚承认不确定性，自查输出是否有误，独立交叉验证，并对自己的判断保持怀疑——没有证据的确信是所有幻觉的根源。

必须注意运用批判性思维——每项结论都需要有可追溯的证据；只有置信度超过 80% 才能采取行动。防止幻觉：切勿把猜测当作事实陈述。

必须注意运用 AI 防错措施——整体优先调试、在应负责的层修复、编码前明确歧义，并在压缩上下文后重新阅读文件。

结束提醒

• 强制要求、重要、必须注意：开始前，使用任务跟踪将工作拆分为小型待办任务
• 强制要求、重要、必须注意：新建代码前，在代码库中搜索 3 个或更多类似模式
• 强制要求、重要、必须注意：为每项结论提供 file:line 证据（置信度超过 80% 才能采取行动）
• 强制要求、重要、必须注意：添加最终审核待办任务，以验证工作质量

[TASK-PLANNING] 行动前，分析任务范围，并使用任务跟踪系统地将其拆分为小型待办任务和子任务。

无钩子提示词协议镜像（自动同步）

来源：.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："启用自定义工作流：[步骤 1 → 步骤 2 → ...]"（附上一句话说明理由）
4. 启用（确认后）： 标准工作流调用 $workflow-start <workflowId>；自定义步骤按顺序手动执行
5. 创建任务： 跟踪工作流的所有步骤
6. 执行： 按顺序遵循每个步骤 [CRITICAL-THINKING-MINDSET] 运用批判性思维和顺序思维。每项声明都必须有可追溯的证据；置信度超过 80% 才能采取行动。 反幻觉原则： 切勿将猜测当作事实；每项声明都要引用来源；坦率承认不确定性；自行检查输出是否有误；独立交叉核对；对自己的判断保持怀疑——没有证据的确信是所有幻觉的根源。 AI 注意力原则（首因－近因效应）： 对于较长的提示词／协议，将最关键的 3 条规则同时放在开头和结尾，以确保指令在较长上下文窗口中仍能得到遵循。 目标驱动执行： 先定义成功标准，循环执行直至验证通过，并且只有在可观察的检查均通过后才停止。 测试验证意图： 测试必须保护业务规则／不变量，并在受保护的意图被破坏时失败，而不能只照搬当前行为。

[LESSON-LEARNED-REMINDER] [BLOCKING] 任务规划与持续改进 — 强制执行。不得跳过。

开始前将工作拆分为小任务并进行跟踪。添加最终任务："分析 AI 错误与经验教训"。

提取经验教训——仅限根本原因，不处理表面症状：

1. 指明失败模式（推理／假设失误），而非症状——例如“未阅读源代码就假设 API 存在”，而不是“使用了错误的枚举值”。
2. 通用性测试：此失败模式是否适用于 ≥3 种情境／代码库？如果不适用，就再抽象一层。
3. 将其写成通用规则——去除项目特定的名称／路径／类。该规则应适用于任何代码库。
4. 合并：多个错误若有相同的失败模式 → 总结为一条经验教训。
5. 重复发生检查：“如果没有这条提醒，未来会话中还会发生这种情况吗？”——不会 → 跳过 $learn。
6. 自动修复检查：“$code-review／$code-simplifier／$security／$lint 能否发现此问题？”——能 → 改进相应的审查技能。
7. 两项检查均通过 → 请用户运行 $learn。 [TASK-PLANNING] [MANDATORY] 在执行任何工作流或技能步骤之前，先为所有计划步骤创建／更新任务跟踪；然后随着每个步骤开始／完成，持续同步任务状态。