Everything Claude Code (ECC) — 代理指令书¶

这是一个生产就绪的 AI 编码插件，提供 60 个专业代理、228 项技能、75 条命令以及自动化钩子工作流。

版本： 2.0.0-rc.1

核心原则¶

1. 代理优先 — 将领域任务委托给专业代理
2. 测试驱动 — 在实现之前编写测试，要求 80% 以上的覆盖率
3. 安全第一 — 绝不在安全上妥协，验证所有输入
4. 不可变性 — 始终创建新对象，不修改现有对象
5. 先计划后执行 — 复杂功能在编写代码之前先制定计划

可用代理¶

代理编排¶

在用户未提示的情况下主动使用代理：

• 复杂功能请求 → ecc:planner
• 创建/修改代码后立即 → ecc:code-reviewer
• 缺陷修复或新功能 → ecc:tdd-guide
• 架构决策 → ecc:architect
• 涉及安全的代码 → ecc:security-reviewer
• 自主循环 / 循环监控 → ecc:loop-operator
• harness 配置的可靠性与成本 → ecc:harness-optimizer

对于独立操作使用并行执行 — 同时启动多个代理。

安全准则¶

提交前务必确认：

• 没有硬编码的机密（API 密钥、密码、令牌）
• 所有用户输入均已验证
• SQL 注入防护（参数化查询）
• XSS 防护（HTML 清理）
• CSRF 保护已启用
• 认证/授权已验证
• 所有端点均有速率限制
• 错误消息不泄露敏感数据

机密管理： 绝不对机密进行硬编码。使用环境变量或机密管理器。在启动时验证所需机密。已泄露的机密立即轮换。

如果发现安全问题： 停止 → 使用 security-reviewer 代理 → 修复 CRITICAL 问题 → 轮换已泄露的机密 → 审查代码库中是否存在类似问题。

编码风格¶

不可变性（必需）： 始终创建新对象，不修改现有对象。返回应用了更改的新副本。

文件结构： 优先使用多个小文件而非少数大文件。200-400 行为标准，最多 800 行。按功能/领域而非类型组织。高内聚、低耦合。

错误处理： 在每一层处理错误。在 UI 代码中提供用户友好的消息。在服务端记录带有详细上下文的日志。不要隐式吞掉错误。

输入验证： 在系统边界验证所有用户输入。使用基于模式(schema)的验证。以明确的消息尽早失败。绝不信任外部数据。

代码质量检查清单：

• 函数保持短小（<50 行），文件保持聚焦（<800 行）
• 无深层嵌套（不超过 4 层）
• 适当的错误处理，无硬编码值
• 可读性强、命名恰当的标识符

测试要求¶

最低覆盖率：80%

测试类型（全部必需）：

1. 单元测试 — 单个函数、工具、组件
2. 集成测试 — API 端点、数据库操作
3. E2E 测试 — 关键用户流程

TDD 工作流（必需）：

1. 先编写测试（RED）— 测试应当失败
2. 编写最小实现（GREEN）— 测试应当通过
3. 重构（IMPROVE）— 确认覆盖率在 80% 以上

失败排查：确认测试隔离 → 验证 mock → 修复实现（除非测试本身有误，否则应修复实现而非测试）。

开发工作流¶

1. 计划 — 使用 planner 代理，识别依赖关系和风险，划分为多个阶段
2. TDD — 使用 tdd-guide 代理，先编写测试，实现，重构
3. 审查 — 立即使用 code-reviewer 代理，处理 CRITICAL/HIGH 问题
4. 将知识记录在合适的位置
5. 个人调试笔记、偏好、临时上下文 → 自动记忆
6. 团队/项目知识（架构决策、API 变更、运行手册） → 项目现有的文档结构
7. 如果当前任务中已生成相关文档或代码注释，请勿在其他位置复制相同信息
8. 如果没有明确的项目文档位置，在创建新的顶级文件之前先进行确认
9. 提交 — 采用 Conventional Commits 格式，提供全面的 PR 摘要

工作流表层策略¶

• skills/ 是正式的工作流表层。
• 新的工作流贡献应首先放置在 skills/ 中。
• commands/ 是遗留的斜杠命令兼容表层，仅当为了迁移或跨 harness 对等性而需要 shim 时，才应添加或更新。

Git 工作流¶

提交格式： <type>: <description> — 类型：feat、fix、refactor、docs、test、chore、perf、ci

PR 工作流： 分析完整的提交历史 → 创建全面的摘要 → 包含测试计划 → 使用 -u 标志推送。

架构模式¶

API 响应格式： 包含成功指示器、数据负载、错误消息和分页元数据的一致信封(envelope)结构。

仓储模式： 将数据访问封装在标准接口（findAll、findById、create、update、delete）之后。业务逻辑依赖抽象接口而非存储机制。

骨架项目： 搜索经过验证的模板，使用并行代理（安全性、可扩展性、相关性）进行评估，克隆最佳模板，并在经过验证的结构内迭代。

性能¶

上下文管理： 对于大规模重构或多文件功能，避免使用上下文窗口的最后 20%。低敏感度任务（单次编辑、文档、简单修复）可容忍更高的使用率。

构建故障排查： 使用 build-error-resolver 代理 → 分析错误 → 逐步修复 → 每次修复后进行验证。

项目结构¶

agents/          — 60の専門サブエージェント
skills/          — 228のワークフロースキルとドメイン知識
commands/        — 75のスラッシュコマンド
hooks/           — トリガーベースの自動化
rules/           — 常に従うべきガイドライン（共通 + 言語別）
scripts/         — クロスプラットフォームNode.jsユーティリティ
mcp-configs/     — 14のMCPサーバー設定
tests/           — テストスイート

commands/ 出于兼容性考虑仍保留在仓库中，但长期方向是技能优先（skills-first）。

成功指标¶

• 所有测试均以 80% 以上的覆盖率通过
• 无安全漏洞
• 代码可读且易于维护
• 性能在可接受范围内
• 用户需求得到满足