Exploration: [Feature/Area Name]【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECCEntry Points[Entry point]: [How it is triggered]Execution Flow[Step][Step]Architecture Insights[Pattern]: [Where and why it is used]Key FilesFileRoleImportanceDependenciesExternal: [...]Internal: [...]Recommendations for New DevelopmentFollow [...]Reuse [...]Avoid [...]注意其中的 **Recommendations for New Development** 小节侦察不是终点它要为后续设计直接产出该跟随什么、该复用什么、该避开什么三条建议——这正是从 Phase 2 平滑过渡到 Phase 4 Architecture Design 的桥梁。 ### 3.3 与仓库实践对齐的印证 仓库中其他 Agent/指令对理解优先的强调可以佐证这一设计并非孤例 - MLE机器学习工程工作流在 [skills/mle-workflow/SKILL.md](https://link.gitcode.com/i/35234dc3bd29e72427e80163325c3c83) 中将 plan / feature-dev 定位为把模型变更作为带数据、评估、serving、回滚阶段的产能力来圈定范围的手段 - orch-add-feature 流水线的第 2 步也是先 Research existing libraries/patterns, then plan a task_list见 [commands/orch-add-feature.md](https://link.gitcode.com/i/c33296dc37e89d4d2bffbc258dca8fdf)再进入实现——模式完全一致**先研究再计划后实现**。 --- ## 四、Phase 3Clarifying Questions——带着发现去提问且必须等待回答 阶段动作 - **present findings from exploration** —— 把 Phase 2 的发现汇报给用户 - **ask targeted design and edge-case questions** —— 提有针对性的设计与边界问题 - **wait for user response before proceeding** —— **在继续之前等待用户回应**。 这一阶段是硬性闸门。feature-dev 用它保证两点一是用户能基于真实代码事实而不是 Agent 脑补做决策二是 Agent 不会在边界情况未澄清时贸然设计。与 [commands/orch-add-feature.md](https://link.gitcode.com/i/40aa6122832e2d39eb5af81fa4574cc3) 中 do not write implementation before Gate 1Gate 1 之前不得编写实现的约束在语义上是同构的——只是 feature-dev 的 Gate 依赖用户显式回复来放行而 orch-add-feature 的 Gate 1 依赖用户对计划清单的批准。 **实操要点**此处的提问应聚焦侦察发现中的矛盾点/空白点/多解点例如新功能与既有模块在错误处理语义上的差异、异步边界的取舍、复用某个共享工具 vs 新建抽象的边界、数据兼容性等。避免提问这个需求要什么这类 Phase 1 已应解决的问题。 --- ## 五、Phase 4Architecture Design——派 code-architect 出蓝图获批后再实现 阶段动作 - **use code-architect to design the feature** —— 调用 [agents/code-architect.md](https://link.gitcode.com/i/ba3ccd6a2516dff8c6e0f6ff81d4f4f7) 定义的 Code Architect Agent - **provide the implementation blueprint** —— 产出实现蓝图 - **wait for approval before implementing** —— **实现前等待用户批准**。 这是继 Phase 3 之后的第二个等待点也是**写代码前的最后一道闸**。之所以把设计与实现分开是为了防止 Agent边设计边写、架构漂移不可见。 ### 5.1 Code Architect Agent 的设计流程 [agents/code-architect.md](https://link.gitcode.com/i/ba3ccd6a2516dff8c6e0f6ff81d4f4f7) 定义了四步 1. **Pattern Analysis模式分析**研究既有代码组织与命名约定、识别已用架构模式、注意测试模式与既有边界、在提出新抽象前先理解依赖图 2. **Architecture Design架构设计**让新特性**自然地嵌入既有模式**选择满足需求的最简架构除非仓库已在用否则避免投机性抽象avoid speculative abstractions unless the repo already uses them 3. **Implementation Blueprint实现蓝图**对每个重要组件给出——文件路径、用途、关键接口、依赖、在数据流中的角色 4. **Build Sequence构建顺序**按依赖排序实施类型与接口 → 核心逻辑 → 集成层 → UI → 测试 → 文档。 ### 5.2 蓝图的标准输出格式 设计阶段的输出有强制模板[agents/code-architect.md#L60-L86](https://link.gitcode.com/i/ba3ccd6a2516dff8c6e0f6ff81d4f4f7#L60-L86) markdown ## Architecture: [Feature Name] ### Design Decisions - Decision 1: [Rationale] - Decision 2: [Rationale] ### Files to Create | File | Purpose | Priority | |------|---------|----------| ### Files to Modify | File | Changes | Priority | |------|---------|----------| ### Data Flow [Description] ### Build Sequence 1. Step 1 2. Step 2这份模板把设计决策的理由放在最前随后落到新建/修改文件清单 优先级 数据流 构建顺序恰好满足用户在 Phase 4 需要审批的一切信息改哪些文件、为什么这么改、按什么顺序改。5.3 关键设计原则提炼从 agents/code-architect.md 可以提炼三条可移植的设计准则值得在你自己团队内复用贴近现状设计要 fit into current patterns而非另起炉灶最小充分choose the simplest architecture that meets the requirement反对投机抽象仓库没用过的新抽象默认不引入除非有明确收益。六、Phase 5Implementation——按批准设计实现优先 TDD、小步提交设计获批后进入实现。feature-dev.md规定三条纪律implement the feature following the approved design—— 严格按已批准设计实现不得擅自偏离prefer TDD where appropriate—— 在合适的场景优先采用测试驱动开发TDDkeep commits small and focused—— 保持提交小且聚焦。6.1 实现顺序参考实现顺序不必自己拍脑袋code-architect的 Build Sequence 已经按依赖给出推荐顺序types/interfaces → core logic → integration layer → UI → tests → docs。仓库 agents/code-architect.md#L47-L56 中明确此顺序Order the implementation by dependency。实现时直接沿用该顺序即可让每个提交保持小而聚焦正好满足第三条纪律。6.2 TDD 与质量门禁的仓库支持prefer TDD where appropriate在 ECC 仓库内不是孤立的建议——仓库同时提供了语言级测试指令族如cpp-test、go-test、react-test、kotlin-test、rust-test等与 commands/quality-gate.md 所述的格式质量门禁。commands/quality-gate.md 揭示了实现后需要面对的自动格式化约束该门禁以单文件格式化检查驱动post:quality-gatePostToolUse hook实现于scripts/hooks/quality-gate.js通过 stdin JSON 读取tool_input.file_path行为开关是环境变量ECC_QUALITY_GATE_FIXtrue应用修复而非仅检查、ECC_QUALITY_GATE_STRICTtrue格式化失败记为门禁失败覆盖文件类型.ts/.tsx/.js/.jsx/.json/.md走 Biome/Prettier.go走gofmt.py走ruff formatlint 与类型检查不属于该门禁范畴需交由verification-loop技能或对应语言验证技能处理。手动对单个文件跑一次门禁的命令来自 commands/quality-gate.mdecho {tool_input:{file_path:src/example.ts}} \ | ECC_QUALITY_GATE_FIXtrue node scripts/hooks/quality-gate.js这条命令表明实现阶段的完成定义不仅包括功能与测试还包含通过仓库的格式化质量门禁。七、Phase 6Quality Review——派code-reviewer审查处理关键问题并核验覆盖率实现完成后进入质量把关。feature-dev.md要求usecode-reviewerto review the implementation—— 调用 agents/code-reviewer.md 定义的 Code Reviewer Agentaddress critical and important issues—— 修复 CRITICAL 与 HIGH重要级别问题verify test coverage—— 核验测试覆盖。7.1 审查者先取 diff再读上下文agents/code-reviewer.md 给出的审查流程第一步是 Gather context运行git diff --staged与git diff查看全部改动若无 diff 则git log --oneline -5看最近提交。随后理解改动范围、阅读周边完整文件与调用点再进入清单式检查。7.2 分级过滤宁可零发现也不灌水该 Agent 最值得借鉴的机制是Confidence-Based Filtering置信度过滤见 agents/code-reviewer.md#L31-L74对真实问题置信度 80% 才报告风格偏好除非违反项目约定一律跳过未改动代码中的问题除非是 CRITICAL 级安全项否则不报相似问题合并上报例如5 个函数缺错误处理作为一条而非 5 条写每条发现前过四道Pre-Report Gate能否给出精确行号能否描述具体失败模式输入、状态、后果是否读过周边上下文严重级别是否站得住——任一为否即降级或删除HIGH/CRITICAL 必须附带精确片段行号、具体失败场景、为何既有防线拦不住三件套该 Agent 明确写道It Is Acceptable And Expected To Return Zero Findings零发现是可接受且预期的合法结论干净的小 diff 正确输出就是 0 行发现、结论APPROVE禁止为刷存在感制造噪音见 agents/code-reviewer.md#L66-L74。这一设计对feature-dev的 Phase 6 含义是Quality Review 的产出可信度来自少而准而非多而全。LLM 审查者最大的失效模式是炮制无触发场景的假阳性——仓库用这套过滤机制明确对抗这一点。7.3 审查清单速览审查清单按严重级别组织详见 agents/code-reviewer.md#L113-L291CRITICAL安全硬编码凭据、SQL 注入、XSS、路径穿越、CSRF、认证绕过、危险依赖、日志泄露敏感数据HIGH代码质量 框架模式超大函数/文件、嵌套过深、缺失错误处理、可变性反模式、缺失测试、死代码React 依赖数组缺失、渲染期 setState、列表缺 key、过期闭包等后端输入未校验、缺限流、N1 查询、外部调用缺超时等MEDIUM性能低效算法、非必要重渲染、包体积过大、缺缓存、同步阻塞 I/OLOW最佳实践无工单的 TODO、公共 API 缺 JSDoc、命名差、魔法数、格式不一致。每条发现按固定格式输出文件:行号、Issue、Fix并在最后输出汇总表与结论## Review Summary | Severity | Count | Status | |----------|-------|--------| | CRITICAL | 0 | pass | | HIGH | 2 | warn | | MEDIUM | 3 | info | | LOW | 1 | note | Verdict: WARNING — 2 HIGH issues should be resolved before merge.批准判据无 CRITICAL/HIGH含零发现→ APPROVE仅 HIGH → Warning可谨慎合并有 CRITICAL → Block。仓库特别强调Do not withhold approval to appear rigorous不要为了显得严谨而扣下批准。对应到feature-dev的 Phase 6address critical and important issues就是按这份判据处理到至少达到 APPROVE/Warning 边界并在进入下一阶段前完成测试覆盖核验。7.4 面向 AI 生成代码的额外把关agents/code-reviewer.md#L312-L323 的 v1.8 附录专门针对 AI 生成代码要求优先关注四类风险行为回归与边界处理、安全假设与信任边界、隐藏耦合或意外架构漂移、不必要的模型成本诱导型复杂度——其中成本检查建议对确定性重构默认用低成本档模型。这条与 ECC 的 agent harness 性能优化主题一脉相承。八、Phase 7Summary——收尾报告与后续清单feature-dev的收尾阶段要求summarize what was built—— 总结构建了什么list follow-up items or limitations—— 列出后续事项或已知限制provide testing instructions—— 给出测试指引。这一阶段让一次特性开发可被审计、可被续接后续维护者或 Agent 依据 Summary 中的限制/后续项决定下一轮迭代依据测试指引验证行为。从源码结构看这与仓库中强调清单化交付、显式记录边界的文档风格如 code-reviewer 的汇总表、orch-add-feature 的 GATE 划分一致——每个阶段都以结构化的、可追溯的产物结束。建议的 Summary 最小模板## What Was Built - [核心能力/文件级变更摘要] ## Follow-ups / Limitations - [已知限制 1] - [后续项 1] ## Testing Instructions 1. [运行测试的命令/入口] 2. [手工验证步骤]【免费下载链接】ECCThe agent harness performance optimization system. Skills, instincts, memory, security, and research-first development for Claude Code, Codex, Opencode, Cursor and beyond.项目地址: https://gitcode.com/GitHub_Trending/ev/ECC创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考