ECC 通用模式规则解读骨架工程选型流程与 Repository、API Response 两大设计模式落地【免费下载链接】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本文基于 ECC 仓库中的 Cursor 规则文件 common-patterns.md 展开完整覆盖其三大核心内容新功能实现时的骨架工程Skeleton Projects四步选型流程、Repository 仓储模式的数据访问封装原则以及 API Response 统一响应包裹envelope规范。读完本文你可以理解这套规则为何设置alwaysApply: true使其始终生效、它如何与 rules/common/patterns.md 源文件及语言特定扩展文件分层协作并能直接参考仓库中 TypeScript 扩展规则与 backend-patterns 技能给出的可运行代码示例在自己的项目中落地这两大模式。规则定位为什么这是一条 alwaysApply 规则common-patterns.md 是 ECC 提供给 Cursor 的规则文件其 YAML frontmatter 声明如下description: Common patterns: repository, API response, skeleton projects alwaysApply: true两个要点值得注意alwaysApply: true该规则不依赖文件通配globs或路径匹配在所有会话中始终被注入上下文。这是因为模式选择属于全局性工程约定——无论你当前编辑的是哪个文件业务代码都应当依赖抽象的数据访问接口、使用统一的 API 响应结构。对照参考语言特定的扩展规则则采用相反策略。例如 typescript-patterns.md 的 frontmatter 声明alwaysApply: false并通过globs: [**/*.ts, **/*.tsx, **/*.js, **/*.jsx]仅在触碰 TypeScript/JavaScript 文件时生效。这种通用规则常驻 语言规则按需的分层设计正是 rules/README.md 所描述的整体架构。该文件与仓库中的 rules/common/patterns.md 内容一致后者是通用层规则的源文件属于 common 目录下的九条语言无关原则之一。按照 rules/README.md 的 Rule Priority 约定当语言特定规则与通用规则冲突时语言特定规则优先specific overrides general——例如 rules/typescript/patterns.md 就在这个通用骨架之上补充了带类型签名的具体实现。骨架工程Skeleton Projects新功能实现的四步流程原文档第一段给出了实现新功能时的标准作业流程搜索经过实战检验的骨架项目Search for battle-tested skeleton projects使用并行 Agent 评估候选方案Use parallel agents to evaluate options评估维度包括安全评估Security assessment可扩展性分析Extensibility analysis相关性打分Relevance scoring实施规划Implementation planning克隆最匹配的骨架作为基础Clone best match as foundation在已验证的结构内迭代Iterate within proven structure这条流程的工程含义是不要从零搭建项目骨架而是复用成熟结构。ECC 仓库自身就是该理念的实践样本——仓库根目录的 RULES.md 在 Must Always 一节中明确要求 Follow established repository patterns before inventing new ones在发明新模式前先遵循仓库已有模式与骨架流程的精神完全一致。流程第二步并行 Agent 评估并非空泛口号而是对应 ECC 的 Agent 协作体系仓库agents/目录下按职责划分了 code-architect.md、security-reviewer.md、planner.md 等专职 Agent恰好覆盖评估清单中的架构扩展性、安全评估与实施规划三个维度。从源码结构看ECC 将评估拆分为多个可并行的子任务正是其 Skills, instincts, memory, security, and research-first development 项目定位在流程层面的体现。Repository 模式把数据访问封装在统一接口之后原文档对 Repository 模式给出四条原则定义标准操作findAll、findById、create、update、delete具体实现处理存储细节数据库、API、文件系统等业务逻辑依赖抽象接口而非存储机制好处便于替换数据源、简化用 mock 进行测试这五条含接口定义在 TypeScript 扩展规则 rules/typescript/patterns.md 中落地为泛型接口interface RepositoryT { findAll(filters?: Filters): PromiseT[] findById(id: string): PromiseT | null create(data: CreateDto): PromiseT update(id: string, data: UpdateDto): PromiseT delete(id: string): Promisevoid }注意接口的类型细节findById返回T | null显式表达可能查不到create/update接收 Dto数据传输对象而非实体本身delete返回Promisevoid。这些签名约定就是具体实现处理存储细节的落点——任何存储后端只要满足同一组签名即可互换。仓库中 skills/backend-patterns/SKILL.md 进一步展示了该模式在真实场景中的两层用法第一层是接口 具体实现的组合// 抽象数据访问逻辑 interface MarketRepository { findAll(filters?: MarketFilters): PromiseMarket[] findById(id: string): PromiseMarket | null create(data: CreateMarketDto): PromiseMarket update(id: string, data: UpdateMarketDto): PromiseMarket delete(id: string): Promisevoid } class SupabaseMarketRepository implements MarketRepository { async findAll(filters?: MarketFilters): PromiseMarket[] { let query supabase.from(markets).select(*) if (filters?.status) { query query.eq(status, filters.status) } if (filters?.limit) { query query.limit(filters.limit) } const { data, error } await query if (error) throw new Error(error.message) return data } // 其余方法... }第二层是装饰/组合——该技能中的CachedMarketRepository接收一个基础MarketRepository和 Redis 客户端对外仍实现同一接口内部在findById时先查缓存redis.get未命中再查库并setex300 秒。这正是原文档便于替换数据源原则的直接证明加一层缓存、换一个后端接口契约与调用方业务逻辑均不变。API Response 格式统一响应包裹envelope原文档对 API 响应提出一致 envelope 的四要素包含success/status 指示器包含data 数据负载出错时可为 null包含error 消息字段成功时可为 null分页响应包含metadatatotal、page、limit这四条原则在 rules/typescript/patterns.md 中具象化为interface ApiResponseT { success: boolean data?: T error?: string meta?: { total: number page: number limit: number } }字段可选性data?、error?精确对应错误时 data 为 null、成功时 error 为 null的约束任一时刻二选一。skills/backend-patterns/SKILL.md 展示了这个 envelope 如何贯穿请求处理链。集中的错误处理器统一产出该结构export function errorHandler(error: unknown, req: Request): Response { if (error instanceof ApiError) { return NextResponse.json({ success: false, error: error.message }, { status: error.statusCode }) } // 参数校验失败... return NextResponse.json({ success: false, error: Internal server error }, { status: 500 }) } // 用法 export async function GET(request: Request) { try { const data await fetchData() return NextResponse.json({ success: true, data }) } catch (error) { return errorHandler(error, request) } }成功路径输出{ success: true, data }失败路径输出{ success: false, error }与ApiResponseT接口逐字段对应。统一 envelope 的实际收益在于前端只需一套解析逻辑处理所有端点且错误消息字段被限制在固定位置避免了有的接口报错用message、有的用error、有的直接抛裸 JSON的混乱。规则体系中的位置common 层与语言扩展层的协作理解这条规则时有必要看清它在 ECC 规则体系中的位置。rules/README.md 定义了整体结构rules/ ├── common/ # 语言无关原则always install │ ├── patterns.md │ └── ... ├── typescript/ # TypeScript/JavaScript 特定 ├── python/ # Python 特定 ├── golang/ # Go 特定 └── ...其中三条与本主题直接相关的协作规则common 层不含语言特定代码示例只提供原则即本文解读的通用模式规则语言目录在 common 规则基础上扩展框架特定模式、工具与代码示例每个文件通过相对链接引用其 common 对应文件例如 rules/typescript/patterns.md 首行即声明 This file extends common/patterns.md with TypeScript/JavaScript specific content。冲突时语言特定规则优先遵循分层配置模式类似 CSS 特异性。Rules 与 Skills 分工Rules 定义广泛适用的标准与清单what to doSkills如 skills/backend-patterns/SKILL.md提供具体任务的可操作参考how to do it。本文引用的MarketRepository完整实现即来自 skill 层。对于 Cursor 用户规则以.cursor/rules/下的扁平文件分发common-patterns.md对应 common 层typescript-patterns.md对应 TypeScript 层frontmatter 中的alwaysApply与globs共同控制注入时机。ECC 仓库还通过 scripts/sync-ecc-to-codex.sh 把这套规则打包为 Codex 会话可用的扩展提示其中ecc-rules-pack-common.md的清单明确把common-patterns.md与其他八条 common 规则并列并要求将它们在规划、实现、评审和验证中视为严格默认值同时注明语言特定指引在冲突时覆盖通用规则。小结两条模式 一条选型流程如何形成闭环选型阶段新功能先找成熟骨架项目用并行 Agent 从安全、扩展性、相关性、实施规划四个维度评估克隆最优基础再迭代——避免从零造轮子。数据访问阶段所有存储细节收敛到五个标准操作findAll/findById/create/update/delete的接口之后业务逻辑只依赖接口天然支持换后端与 mock 测试。对外契约阶段所有 API 响应使用统一 envelopesuccess/data/error/meta让前端解析与错误处理只需一套逻辑。三者配合后仓库内业务逻辑 → 数据访问 → 外部契约的每一层边界都固定下来这正是 RULES.md 所强调的 Follow established repository patterns before inventing new ones 在模式层面的具体含义。若要在自己的项目中引入这套约定可参考 rules/README.md 给出的两种安装方式./install.sh typescript一键安装或手动将rules/common与语言目录复制进~/.claude/rules/ecc/命名空间注意按目录整体拷贝、不可拍平以免语言特定文件覆盖通用规则并破坏../common/相对引用。【免费下载链接】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），仅供参考 ECC 通用模式规则解读：骨架工程选型流程与 Repository、API Response 两大设计模式落地
ECC 通用模式规则解读骨架工程选型流程与 Repository、API Response 两大设计模式落地【免费下载链接】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本文基于 ECC 仓库中的 Cursor 规则文件 common-patterns.md 展开完整覆盖其三大核心内容新功能实现时的骨架工程Skeleton Projects四步选型流程、Repository 仓储模式的数据访问封装原则以及 API Response 统一响应包裹envelope规范。读完本文你可以理解这套规则为何设置alwaysApply: true使其始终生效、它如何与 rules/common/patterns.md 源文件及语言特定扩展文件分层协作并能直接参考仓库中 TypeScript 扩展规则与 backend-patterns 技能给出的可运行代码示例在自己的项目中落地这两大模式。规则定位为什么这是一条 alwaysApply 规则common-patterns.md 是 ECC 提供给 Cursor 的规则文件其 YAML frontmatter 声明如下description: Common patterns: repository, API response, skeleton projects alwaysApply: true两个要点值得注意alwaysApply: true该规则不依赖文件通配globs或路径匹配在所有会话中始终被注入上下文。这是因为模式选择属于全局性工程约定——无论你当前编辑的是哪个文件业务代码都应当依赖抽象的数据访问接口、使用统一的 API 响应结构。对照参考语言特定的扩展规则则采用相反策略。例如 typescript-patterns.md 的 frontmatter 声明alwaysApply: false并通过globs: [**/*.ts, **/*.tsx, **/*.js, **/*.jsx]仅在触碰 TypeScript/JavaScript 文件时生效。这种通用规则常驻 语言规则按需的分层设计正是 rules/README.md 所描述的整体架构。该文件与仓库中的 rules/common/patterns.md 内容一致后者是通用层规则的源文件属于 common 目录下的九条语言无关原则之一。按照 rules/README.md 的 Rule Priority 约定当语言特定规则与通用规则冲突时语言特定规则优先specific overrides general——例如 rules/typescript/patterns.md 就在这个通用骨架之上补充了带类型签名的具体实现。骨架工程Skeleton Projects新功能实现的四步流程原文档第一段给出了实现新功能时的标准作业流程搜索经过实战检验的骨架项目Search for battle-tested skeleton projects使用并行 Agent 评估候选方案Use parallel agents to evaluate options评估维度包括安全评估Security assessment可扩展性分析Extensibility analysis相关性打分Relevance scoring实施规划Implementation planning克隆最匹配的骨架作为基础Clone best match as foundation在已验证的结构内迭代Iterate within proven structure这条流程的工程含义是不要从零搭建项目骨架而是复用成熟结构。ECC 仓库自身就是该理念的实践样本——仓库根目录的 RULES.md 在 Must Always 一节中明确要求 Follow established repository patterns before inventing new ones在发明新模式前先遵循仓库已有模式与骨架流程的精神完全一致。流程第二步并行 Agent 评估并非空泛口号而是对应 ECC 的 Agent 协作体系仓库agents/目录下按职责划分了 code-architect.md、security-reviewer.md、planner.md 等专职 Agent恰好覆盖评估清单中的架构扩展性、安全评估与实施规划三个维度。从源码结构看ECC 将评估拆分为多个可并行的子任务正是其 Skills, instincts, memory, security, and research-first development 项目定位在流程层面的体现。Repository 模式把数据访问封装在统一接口之后原文档对 Repository 模式给出四条原则定义标准操作findAll、findById、create、update、delete具体实现处理存储细节数据库、API、文件系统等业务逻辑依赖抽象接口而非存储机制好处便于替换数据源、简化用 mock 进行测试这五条含接口定义在 TypeScript 扩展规则 rules/typescript/patterns.md 中落地为泛型接口interface RepositoryT { findAll(filters?: Filters): PromiseT[] findById(id: string): PromiseT | null create(data: CreateDto): PromiseT update(id: string, data: UpdateDto): PromiseT delete(id: string): Promisevoid }注意接口的类型细节findById返回T | null显式表达可能查不到create/update接收 Dto数据传输对象而非实体本身delete返回Promisevoid。这些签名约定就是具体实现处理存储细节的落点——任何存储后端只要满足同一组签名即可互换。仓库中 skills/backend-patterns/SKILL.md 进一步展示了该模式在真实场景中的两层用法第一层是接口 具体实现的组合// 抽象数据访问逻辑 interface MarketRepository { findAll(filters?: MarketFilters): PromiseMarket[] findById(id: string): PromiseMarket | null create(data: CreateMarketDto): PromiseMarket update(id: string, data: UpdateMarketDto): PromiseMarket delete(id: string): Promisevoid } class SupabaseMarketRepository implements MarketRepository { async findAll(filters?: MarketFilters): PromiseMarket[] { let query supabase.from(markets).select(*) if (filters?.status) { query query.eq(status, filters.status) } if (filters?.limit) { query query.limit(filters.limit) } const { data, error } await query if (error) throw new Error(error.message) return data } // 其余方法... }第二层是装饰/组合——该技能中的CachedMarketRepository接收一个基础MarketRepository和 Redis 客户端对外仍实现同一接口内部在findById时先查缓存redis.get未命中再查库并setex300 秒。这正是原文档便于替换数据源原则的直接证明加一层缓存、换一个后端接口契约与调用方业务逻辑均不变。API Response 格式统一响应包裹envelope原文档对 API 响应提出一致 envelope 的四要素包含success/status 指示器包含data 数据负载出错时可为 null包含error 消息字段成功时可为 null分页响应包含metadatatotal、page、limit这四条原则在 rules/typescript/patterns.md 中具象化为interface ApiResponseT { success: boolean data?: T error?: string meta?: { total: number page: number limit: number } }字段可选性data?、error?精确对应错误时 data 为 null、成功时 error 为 null的约束任一时刻二选一。skills/backend-patterns/SKILL.md 展示了这个 envelope 如何贯穿请求处理链。集中的错误处理器统一产出该结构export function errorHandler(error: unknown, req: Request): Response { if (error instanceof ApiError) { return NextResponse.json({ success: false, error: error.message }, { status: error.statusCode }) } // 参数校验失败... return NextResponse.json({ success: false, error: Internal server error }, { status: 500 }) } // 用法 export async function GET(request: Request) { try { const data await fetchData() return NextResponse.json({ success: true, data }) } catch (error) { return errorHandler(error, request) } }成功路径输出{ success: true, data }失败路径输出{ success: false, error }与ApiResponseT接口逐字段对应。统一 envelope 的实际收益在于前端只需一套解析逻辑处理所有端点且错误消息字段被限制在固定位置避免了有的接口报错用message、有的用error、有的直接抛裸 JSON的混乱。规则体系中的位置common 层与语言扩展层的协作理解这条规则时有必要看清它在 ECC 规则体系中的位置。rules/README.md 定义了整体结构rules/ ├── common/ # 语言无关原则always install │ ├── patterns.md │ └── ... ├── typescript/ # TypeScript/JavaScript 特定 ├── python/ # Python 特定 ├── golang/ # Go 特定 └── ...其中三条与本主题直接相关的协作规则common 层不含语言特定代码示例只提供原则即本文解读的通用模式规则语言目录在 common 规则基础上扩展框架特定模式、工具与代码示例每个文件通过相对链接引用其 common 对应文件例如 rules/typescript/patterns.md 首行即声明 This file extends common/patterns.md with TypeScript/JavaScript specific content。冲突时语言特定规则优先遵循分层配置模式类似 CSS 特异性。Rules 与 Skills 分工Rules 定义广泛适用的标准与清单what to doSkills如 skills/backend-patterns/SKILL.md提供具体任务的可操作参考how to do it。本文引用的MarketRepository完整实现即来自 skill 层。对于 Cursor 用户规则以.cursor/rules/下的扁平文件分发common-patterns.md对应 common 层typescript-patterns.md对应 TypeScript 层frontmatter 中的alwaysApply与globs共同控制注入时机。ECC 仓库还通过 scripts/sync-ecc-to-codex.sh 把这套规则打包为 Codex 会话可用的扩展提示其中ecc-rules-pack-common.md的清单明确把common-patterns.md与其他八条 common 规则并列并要求将它们在规划、实现、评审和验证中视为严格默认值同时注明语言特定指引在冲突时覆盖通用规则。小结两条模式 一条选型流程如何形成闭环选型阶段新功能先找成熟骨架项目用并行 Agent 从安全、扩展性、相关性、实施规划四个维度评估克隆最优基础再迭代——避免从零造轮子。数据访问阶段所有存储细节收敛到五个标准操作findAll/findById/create/update/delete的接口之后业务逻辑只依赖接口天然支持换后端与 mock 测试。对外契约阶段所有 API 响应使用统一 envelopesuccess/data/error/meta让前端解析与错误处理只需一套逻辑。三者配合后仓库内业务逻辑 → 数据访问 → 外部契约的每一层边界都固定下来这正是 RULES.md 所强调的 Follow established repository patterns before inventing new ones 在模式层面的具体含义。若要在自己的项目中引入这套约定可参考 rules/README.md 给出的两种安装方式./install.sh typescript一键安装或手动将rules/common与语言目录复制进~/.claude/rules/ecc/命名空间注意按目录整体拷贝、不可拍平以免语言特定文件覆盖通用规则并破坏../common/相对引用。【免费下载链接】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），仅供参考