技能适配策略¶

ECC 接受来自外部仓库的想法，但已发布的技能需要成为 ECC 原生能力面。

默认规则¶

当贡献源自另一个开源仓库、Prompt 包、插件、测试框架或个人配置时：

• 复制其底层想法、工作流或结构
• 将其适配到 ECC 当前的安装面、验证流程和仓库约定
• 移除不必要的外部品牌、依赖假设和上游特定表述

目标是复用，而不是将 ECC 变成围绕他人运行时的薄封装。

何时保留原始名称¶

仅当以下所有条件都成立时，才保留原始技能名称：

• 该贡献接近直接移植
• 名称本身已经具有描述性且中立
• 该能力面仍然表现为上游概念
• 仓库中不存在更合适的 ECC 原生名称

示例：

• 框架名称，例如 nestjs-patterns
• 作为主题而非厂商宣传的协议或产品名称

何时重命名¶

当 ECC 对原始工作进行了有意义的扩展、收窄或重新打包时，应重命名该技能。

典型触发条件：

• ECC 增加了大量新行为、结构或指导
• 原始名称偏向厂商或社区品牌，而非工作流
• 该贡献与现有 ECC 能力面重叠，需要更清晰的边界
• 该贡献现在更适合作为能力、运营工作流或策略层，而非字面意义上的移植

示例：

• 将可复用的图原语保留为 social-graph-ranker，但将更广泛的工作流层命名为 lead-intelligence 或 connections-optimizer
• 如果范围发生实质性变化，优先使用 product-capability 等 ECC 原生名称，而不是模糊的导入规划标签

依赖策略¶

ECC 偏好能够完成任务的最窄原生能力面：

• rules/ 用于确定性约束
• skills/ 用于按需工作流
• 当长期交互式工具边界合理时，使用 MCP
• 本地脚本/CLI 用于确定性一次性执行
• 当远程调用范围较窄且不足以证明使用 MCP 时，使用直接 API

避免发布一个主要只是告诉用户安装或信任未经审核的第三方包的技能。

如果外部功能值得保留：

• 在可行时，在 ECC 内部内置或重新创建相关逻辑
• 或将集成保持为可选，并明确标记为外部
• 在没有明确理由的情况下，绝不让新的外部依赖成为默认路径

审查问题¶

在合并贡献的技能之前，回答以下问题：

1. 这是 ECC 中真正可复用的能力面，还是只是另一个工具的文档？
2. 当前名称是否仍然匹配 ECC 形态的能力面？
3. 是否已有 ECC 技能拥有该行为的大部分？
4. 我们是在导入一个概念，还是在导入他人的产品身份？
5. ECC 用户在不了解上游仓库的情况下，能否理解该技能的用途？

如果这些答案不够充分，请进一步适配、缩小范围，或不发布它。