如何用 PRP 模式PRD→Plan→Implement→PR完成一个功能交付【免费下载链接】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/ECCECC 是一组面向 Claude Code、Codex、OpenCode、Cursor 等编码代理的命令、规则和 skills 集合其中的 PRP 工作流/prp-prd、/prp-plan、/prp-implement、/prp-commit、/prp-pr把一个功能从想法到 Pull Request 拆成四个阶段每个阶段的产物都是项目里可提交、可核对的 Markdown 文件而不是留在对话记忆里的状态。这篇文章描述的是在已安装 ECC 的 Claude Code 会话中按 PRD → Plan → Implement → PR 的顺序执行一条连续路径最终交付一个带实现报告、验证结果和 PR 链接的功能。适用前提来自 README.mdnpm 安装路径要求 Node.js 18 或更高版本、Git以及PATH上的 Claude Code 2.1 或更新版本/prp-pr阶段还需要 GitHub CLIgh并已执行过gh auth login整个流程在你的 Git 仓库内运行产物写入项目的.claude/PRPs/目录。准备确认命令可用ECC 安装后会注册 94 个全局斜杠命令见 COMMANDS-QUICK-REF.md 的 PRP Workflow 一节。任选一种安装方式例如 npm 路径的低配置安装不装 hook 运行时npx ecc-universal install --profile minimal --target claude或从源码检出执行./install.sh --profile minimal --target claude安装完成后在 Claude Code 会话里输入/能看到prp-prd、prp-plan、prp-implement、prp-commit、prp-pr这组命令即表示可以开始。/prp-pr依赖ghCLI如果命令缺失或未认证该阶段会直接停止并提示安装或执行gh auth login。第一步/prp-prd 生成 PRD在 Claude Code 会话中运行/prp-prd 你的功能想法也可以不带参数argument-hint为[feature/product idea]不带参数时命令会从提问开始。按 commands/prp-prd.md 的定义这是一个 8 个阶段的交互流程QUESTION SET 1 → GROUNDING → QUESTION SET 2 → RESEARCH → QUESTION SET 3 → GENERATEINITIATE复述你对要构建内容的理解等你确认后才继续这是一个 GATE必须响应。FOUNDATION一次性提出 5 个基础问题——谁有问题、问题是什么、为什么现在解决不了、为什么是现在、如何衡量成功。GROUNDING做市场与背景调研如果项目里有代码库会并行探索与功能相关的现有实现并记录文件位置、代码模式和约定。DEEP DIVE追问愿景、主要用户、Job to Be Done、明确排除的用户和约束条件。GROUNDING技术可行性如有代码库做两条并行调查——可复用的基础设施与已实现的相似模式、端到端的数据流与架构边界——并以file:line精确引用现有代码。DECISIONS确定 MVP 范围、Must Have 与 Nice to Have、关键假设、明确不做的事情、开放问题。GENERATE按内置 PRD 模板写出文件目录不存在时先执行mkdir -p .claude/PRPs/prds最终路径为.claude/PRPs/prds/{kebab-case-name}.prd.md模板强制包含 Problem Statement、Evidence、Key Hypothesis、What Were NOT Building、Success Metrics、MoSCoW 能力表和Implementation Phases表每行带Status: pending | in-progress | complete、Parallel、Depends、PRP Plan列。文档明确反模式信息缺失时写 TBD - needs research不允许编造看似合理的需求。生成结束后命令会报告 PRD 文件路径、各章节的验证状态、开放问题数量并给出下一步Run: /prp-plan .claude/PRPs/prds/{name}.prd.md核对点PRD 文件已落在.claude/PRPs/prds/下且 Implementation Phases 表中至少有一行pending。第二步/prp-plan 把 PRD 阶段变成实现计划/prp-plan .claude/PRPs/prds/{name}.prd.mdargument-hint为feature description | path/to/prd.md即既可以传 PRD 路径也可以传自由文本的功能描述见 commands/prp-plan.md。传入 PRD 路径时命令在 Phase 0 做 PRD 解析读取文件、解析 Implementation Phases 表、按状态找pending阶段并检查依赖链某阶段可能要求前置阶段为complete选出下一个符合条件的阶段用该阶段的描述作为要计划的功能。如果没有pending阶段了命令会报告所有阶段已完成。随后依次执行 PARSE把需求写成用户故事按文件数/行数做 Small/Medium/Large/XL 复杂度评估→ EXPLORE按 8 类搜索代码库相似实现、命名约定、错误处理、日志模式、类型定义、测试模式、配置、依赖→ RESEARCH涉及外部库时查官方文档格式为KEY_INSIGHT / APPLIES_TO / GOTCHA→ ARCHITECT → GENERATE。计划写入mkdir -p .claude/PRPs/plans # 输出: .claude/PRPs/plans/{kebab-case-feature-name}.plan.md计划模板里的关键段落是后续实施阶段直接消费的Mandatory Reading实现前必读的文件与行号按 P0/P1/P2 分级Patterns to Mirror从代码库中摘出的真实代码片段每条带SOURCE: [file:lines]Files to Change每个文件的 CREATE/UPDATE 动作与理由Step-by-Step Tasks每个任务含 ACTION、IMPLEMENT、MIRROR、IMPORTS、GOTCHA、VALIDATE 六个字段Validation Commands类型检查、单测、完整测试套件、构建等项目特定命令各自带 EXPECT如 Zero type errors、All tests passAcceptance Criteria与Completion Checklist。计划生成后命令会做两件事把 PRD 中该阶段的状态从pending更新为in-progress并在阶段里登记计划文件路径然后报告计划文件、复杂度、任务数、关键模式和 1–10 的单次实施置信度并提示下一步Run /prp-implement .claude/PRPs/plans/{name}.plan.md核对点.claude/PRPs/plans/下出现.plan.mdPRD 对应阶段已变为in-progress。第三步/prp-implement 按计划执行并逐层验证/prp-implement .claude/PRPs/plans/{name}.plan.md按 commands/prp-implement.md执行顺序是Phase 0 — DETECT按锁文件识别包管理器并确定 runnerbun.lockb→bun run、pnpm-lock.yaml→pnpm run、yarn.lock→yarn、package-lock.json→npm run、pyproject.toml/requirements.txt→ uv/pip、Cargo.toml→cargo、go.mod→go再检查package.json里可用的 type-check / lint / test / build 脚本记下后续验证要用的命令。Phase 1 — LOAD读取计划文件提取 Summary、Patterns to Mirror、Files to Change、Step-by-Step Tasks、Validation Commands、Acceptance Criteria 六个段落。文件不存在或不是有效计划时会直接报错提示先运行/prp-plan。Phase 2 — PREPARE检查 Git 状态并做分支决策git branch --show-current git status --porcelain当前状态动作在功能分支上使用当前分支在 main 且工作区干净创建功能分支git checkout -b feat/{plan-name}在 main 且工作区脏停止——要求先 stash 或提交已为该功能建好 git worktree使用 worktreePhase 3 — EXECUTE逐个任务循环——先读 MIRROR 引用的模式文件再严格按模式实现每个文件改完立即跑类型检查失败就当场修不允许累积坏状态。偏离计划时要记录改了什么、为什么改进入最终报告。Phase 4 — VALIDATE跑计划中定义的全部验证层级每层通过才进下一层静态分析类型检查零错误lint 先自动修复再手工修剩余错误单元测试每个新函数至少一个测试覆盖计划里列出的边界用例测试失败时默认修实现而不是修测试构建零错误集成测试如适用启动服务、轮询健康检查、跑集成测试、再停服务边界用例按计划 Testing Strategy 清单逐项过。Phase 5 — REPORT写实现报告到.claude/PRPs/reports/{plan-name}-report.md内容含预测 vs 实际对比表复杂度、置信度、改动文件数、逐任务完成表、五层验证结果、改动文件统计、偏离记录然后把 PRD 阶段状态从in-progress更新为complete并把计划归档mkdir -p .claude/PRPs/plans/completed mv $ARGUMENTS .claude/PRPs/plans/completed/该阶段的文档化成功标准TASKS_COMPLETE、TYPES_PASS、LINT_PASS、TESTS_PASS、BUILD_PASS、REPORT_CREATED、PLAN_ARCHIVED全部满足。核对点.claude/PRPs/reports/下出现-report.md.claude/PRPs/plans/completed/下出现归档的计划文件PRD 对应阶段为complete。如果某层验证失败文档给出的处理方式是类型错误——读错误信息、修源文件、重跑直到干净测试失败——先判断 bug 在实现还是测试修根因后重跑构建失败——通常是类型或导入问题修后重跑。第四步/prp-commit 与 /prp-pr 交付 PR实施完成后先提交可选但推荐/prp-pr要求工作区干净且分支有领先提交/prp-commit不带参数时暂存全部改动自动生成{type}: {description}格式的规范提交信息类型包括feat、fix、refactor、docs、test、chore、perf、ci要求祈使句、小写开头、72 字符内。也支持staged、*.ts、except tests、only new files等自然语言目标。然后创建 PR见 commands/prp-pr.md/prp-pr参数是可选的 base 分支名默认main和--draft标志。命令按五个阶段执行VALIDATE确认当前不在 base 分支上、工作区干净、git log origin/base..HEAD有领先提交、且gh pr list --head branch为空不存在同分支的 PR。任何一项不满足都会停止并给出具体原因例如工作区脏时提示先用/prp-commit提交。DISCOVER按顺序找 PR 模板.github/PULL_REQUEST_TEMPLATE/目录 →.github/PULL_REQUEST_TEMPLATE.md→.github/pull_request_template.md→docs/pull_request_template.md用git log origin/base..HEAD和git diff --stat/--name-only分析提交与文件并按 dominant type 生成 conventional 格式的 PR 标题检查.claude/PRPs/reports/、.claude/PRPs/plans/、.claude/PRPs/prds/下的 PRP 产物并引用到 PR 正文。PUSHgit push -u origin HEAD远端分叉时执行git fetch origin git rebase origin/base后重推rebase 冲突则停止并告知。CREATE有模板时保留模板全部章节不适用的写 N/A无模板时用 Summary / Changes / Files Changed / Testing / Related Issues 的默认结构最后执行gh pr create --title ... --base base-branch --body ...。VERIFYgh pr view --json number,url,title,state,baseRefName,headRefName,additions,deletions,changedFiles gh pr checks --json name,status,conclusion 2/dev/null || true最终输出 PR 编号、URL、分支、增删行数、CI 检查状态、被引用的 PRP 产物以及后续操作gh pr view number --web打开、/code-review number审查、gh pr merge number合并。文档还列了两个边界超过 20 个文件的大 PR 会提示拆分需要强推时只用--force-with-lease不用--force。一条完整路径的核对方式四个阶段跑完后磁盘上应该有如下产物链这就是整条路径完成的可核对证据.claude/PRPs/prds/{name}.prd.md # 阶段表最终为 complete .claude/PRPs/plans/completed/{name}.plan.md # 已归档 .claude/PRPs/reports/{name}-report.md # 五层验证结果 GitHub PRgh pr view 可查到正文引用了上述产物中间任何一个阶段都可以停下PRD 生成后隔天再开会话把文件路径传给/prp-plan即可从断点继续——这正是产物落在磁盘而不是上下文里的意义。限制与替代路径docs/PLAN-PRD-PATTERN.md 说明 ECC 同时提供一条更精简的原生路径/plan-prd→/plan→tdd-workflowskill →/pr产物在.claude/prds/、.claude/plans/而prp-*命令集被定位为 legacy/deep workflow仍然有效适合已有.claude/PRPs/产物或想要更重流程的场景。两条路径不要混用产物目录。范围已经清楚的小改动bug 修复、单文件增补不需要 PRD直接给/prp-plan传自由文本描述即可命令会跳过 PRD 解析直接做计划。/prp-implement会执行git checkout -b、git pull --rebase、移动计划文件等操作在工作区脏的 main 分支上它会拒绝继续先自行处理未提交改动。/prp-pr硬依赖ghCLI 与认证非 GitHub 远端环境无法走这一步。各阶段的完整阶段定义、模板和验证清单见 commands/prp-prd.md、commands/prp-plan.md、commands/prp-implement.md、commands/prp-commit.md 和 commands/prp-pr.md。【免费下载链接】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），仅供参考 如何用 PRP 模式（PRD→Plan→Implement→PR）完成一个功能交付？
如何用 PRP 模式PRD→Plan→Implement→PR完成一个功能交付【免费下载链接】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/ECCECC 是一组面向 Claude Code、Codex、OpenCode、Cursor 等编码代理的命令、规则和 skills 集合其中的 PRP 工作流/prp-prd、/prp-plan、/prp-implement、/prp-commit、/prp-pr把一个功能从想法到 Pull Request 拆成四个阶段每个阶段的产物都是项目里可提交、可核对的 Markdown 文件而不是留在对话记忆里的状态。这篇文章描述的是在已安装 ECC 的 Claude Code 会话中按 PRD → Plan → Implement → PR 的顺序执行一条连续路径最终交付一个带实现报告、验证结果和 PR 链接的功能。适用前提来自 README.mdnpm 安装路径要求 Node.js 18 或更高版本、Git以及PATH上的 Claude Code 2.1 或更新版本/prp-pr阶段还需要 GitHub CLIgh并已执行过gh auth login整个流程在你的 Git 仓库内运行产物写入项目的.claude/PRPs/目录。准备确认命令可用ECC 安装后会注册 94 个全局斜杠命令见 COMMANDS-QUICK-REF.md 的 PRP Workflow 一节。任选一种安装方式例如 npm 路径的低配置安装不装 hook 运行时npx ecc-universal install --profile minimal --target claude或从源码检出执行./install.sh --profile minimal --target claude安装完成后在 Claude Code 会话里输入/能看到prp-prd、prp-plan、prp-implement、prp-commit、prp-pr这组命令即表示可以开始。/prp-pr依赖ghCLI如果命令缺失或未认证该阶段会直接停止并提示安装或执行gh auth login。第一步/prp-prd 生成 PRD在 Claude Code 会话中运行/prp-prd 你的功能想法也可以不带参数argument-hint为[feature/product idea]不带参数时命令会从提问开始。按 commands/prp-prd.md 的定义这是一个 8 个阶段的交互流程QUESTION SET 1 → GROUNDING → QUESTION SET 2 → RESEARCH → QUESTION SET 3 → GENERATEINITIATE复述你对要构建内容的理解等你确认后才继续这是一个 GATE必须响应。FOUNDATION一次性提出 5 个基础问题——谁有问题、问题是什么、为什么现在解决不了、为什么是现在、如何衡量成功。GROUNDING做市场与背景调研如果项目里有代码库会并行探索与功能相关的现有实现并记录文件位置、代码模式和约定。DEEP DIVE追问愿景、主要用户、Job to Be Done、明确排除的用户和约束条件。GROUNDING技术可行性如有代码库做两条并行调查——可复用的基础设施与已实现的相似模式、端到端的数据流与架构边界——并以file:line精确引用现有代码。DECISIONS确定 MVP 范围、Must Have 与 Nice to Have、关键假设、明确不做的事情、开放问题。GENERATE按内置 PRD 模板写出文件目录不存在时先执行mkdir -p .claude/PRPs/prds最终路径为.claude/PRPs/prds/{kebab-case-name}.prd.md模板强制包含 Problem Statement、Evidence、Key Hypothesis、What Were NOT Building、Success Metrics、MoSCoW 能力表和Implementation Phases表每行带Status: pending | in-progress | complete、Parallel、Depends、PRP Plan列。文档明确反模式信息缺失时写 TBD - needs research不允许编造看似合理的需求。生成结束后命令会报告 PRD 文件路径、各章节的验证状态、开放问题数量并给出下一步Run: /prp-plan .claude/PRPs/prds/{name}.prd.md核对点PRD 文件已落在.claude/PRPs/prds/下且 Implementation Phases 表中至少有一行pending。第二步/prp-plan 把 PRD 阶段变成实现计划/prp-plan .claude/PRPs/prds/{name}.prd.mdargument-hint为feature description | path/to/prd.md即既可以传 PRD 路径也可以传自由文本的功能描述见 commands/prp-plan.md。传入 PRD 路径时命令在 Phase 0 做 PRD 解析读取文件、解析 Implementation Phases 表、按状态找pending阶段并检查依赖链某阶段可能要求前置阶段为complete选出下一个符合条件的阶段用该阶段的描述作为要计划的功能。如果没有pending阶段了命令会报告所有阶段已完成。随后依次执行 PARSE把需求写成用户故事按文件数/行数做 Small/Medium/Large/XL 复杂度评估→ EXPLORE按 8 类搜索代码库相似实现、命名约定、错误处理、日志模式、类型定义、测试模式、配置、依赖→ RESEARCH涉及外部库时查官方文档格式为KEY_INSIGHT / APPLIES_TO / GOTCHA→ ARCHITECT → GENERATE。计划写入mkdir -p .claude/PRPs/plans # 输出: .claude/PRPs/plans/{kebab-case-feature-name}.plan.md计划模板里的关键段落是后续实施阶段直接消费的Mandatory Reading实现前必读的文件与行号按 P0/P1/P2 分级Patterns to Mirror从代码库中摘出的真实代码片段每条带SOURCE: [file:lines]Files to Change每个文件的 CREATE/UPDATE 动作与理由Step-by-Step Tasks每个任务含 ACTION、IMPLEMENT、MIRROR、IMPORTS、GOTCHA、VALIDATE 六个字段Validation Commands类型检查、单测、完整测试套件、构建等项目特定命令各自带 EXPECT如 Zero type errors、All tests passAcceptance Criteria与Completion Checklist。计划生成后命令会做两件事把 PRD 中该阶段的状态从pending更新为in-progress并在阶段里登记计划文件路径然后报告计划文件、复杂度、任务数、关键模式和 1–10 的单次实施置信度并提示下一步Run /prp-implement .claude/PRPs/plans/{name}.plan.md核对点.claude/PRPs/plans/下出现.plan.mdPRD 对应阶段已变为in-progress。第三步/prp-implement 按计划执行并逐层验证/prp-implement .claude/PRPs/plans/{name}.plan.md按 commands/prp-implement.md执行顺序是Phase 0 — DETECT按锁文件识别包管理器并确定 runnerbun.lockb→bun run、pnpm-lock.yaml→pnpm run、yarn.lock→yarn、package-lock.json→npm run、pyproject.toml/requirements.txt→ uv/pip、Cargo.toml→cargo、go.mod→go再检查package.json里可用的 type-check / lint / test / build 脚本记下后续验证要用的命令。Phase 1 — LOAD读取计划文件提取 Summary、Patterns to Mirror、Files to Change、Step-by-Step Tasks、Validation Commands、Acceptance Criteria 六个段落。文件不存在或不是有效计划时会直接报错提示先运行/prp-plan。Phase 2 — PREPARE检查 Git 状态并做分支决策git branch --show-current git status --porcelain当前状态动作在功能分支上使用当前分支在 main 且工作区干净创建功能分支git checkout -b feat/{plan-name}在 main 且工作区脏停止——要求先 stash 或提交已为该功能建好 git worktree使用 worktreePhase 3 — EXECUTE逐个任务循环——先读 MIRROR 引用的模式文件再严格按模式实现每个文件改完立即跑类型检查失败就当场修不允许累积坏状态。偏离计划时要记录改了什么、为什么改进入最终报告。Phase 4 — VALIDATE跑计划中定义的全部验证层级每层通过才进下一层静态分析类型检查零错误lint 先自动修复再手工修剩余错误单元测试每个新函数至少一个测试覆盖计划里列出的边界用例测试失败时默认修实现而不是修测试构建零错误集成测试如适用启动服务、轮询健康检查、跑集成测试、再停服务边界用例按计划 Testing Strategy 清单逐项过。Phase 5 — REPORT写实现报告到.claude/PRPs/reports/{plan-name}-report.md内容含预测 vs 实际对比表复杂度、置信度、改动文件数、逐任务完成表、五层验证结果、改动文件统计、偏离记录然后把 PRD 阶段状态从in-progress更新为complete并把计划归档mkdir -p .claude/PRPs/plans/completed mv $ARGUMENTS .claude/PRPs/plans/completed/该阶段的文档化成功标准TASKS_COMPLETE、TYPES_PASS、LINT_PASS、TESTS_PASS、BUILD_PASS、REPORT_CREATED、PLAN_ARCHIVED全部满足。核对点.claude/PRPs/reports/下出现-report.md.claude/PRPs/plans/completed/下出现归档的计划文件PRD 对应阶段为complete。如果某层验证失败文档给出的处理方式是类型错误——读错误信息、修源文件、重跑直到干净测试失败——先判断 bug 在实现还是测试修根因后重跑构建失败——通常是类型或导入问题修后重跑。第四步/prp-commit 与 /prp-pr 交付 PR实施完成后先提交可选但推荐/prp-pr要求工作区干净且分支有领先提交/prp-commit不带参数时暂存全部改动自动生成{type}: {description}格式的规范提交信息类型包括feat、fix、refactor、docs、test、chore、perf、ci要求祈使句、小写开头、72 字符内。也支持staged、*.ts、except tests、only new files等自然语言目标。然后创建 PR见 commands/prp-pr.md/prp-pr参数是可选的 base 分支名默认main和--draft标志。命令按五个阶段执行VALIDATE确认当前不在 base 分支上、工作区干净、git log origin/base..HEAD有领先提交、且gh pr list --head branch为空不存在同分支的 PR。任何一项不满足都会停止并给出具体原因例如工作区脏时提示先用/prp-commit提交。DISCOVER按顺序找 PR 模板.github/PULL_REQUEST_TEMPLATE/目录 →.github/PULL_REQUEST_TEMPLATE.md→.github/pull_request_template.md→docs/pull_request_template.md用git log origin/base..HEAD和git diff --stat/--name-only分析提交与文件并按 dominant type 生成 conventional 格式的 PR 标题检查.claude/PRPs/reports/、.claude/PRPs/plans/、.claude/PRPs/prds/下的 PRP 产物并引用到 PR 正文。PUSHgit push -u origin HEAD远端分叉时执行git fetch origin git rebase origin/base后重推rebase 冲突则停止并告知。CREATE有模板时保留模板全部章节不适用的写 N/A无模板时用 Summary / Changes / Files Changed / Testing / Related Issues 的默认结构最后执行gh pr create --title ... --base base-branch --body ...。VERIFYgh pr view --json number,url,title,state,baseRefName,headRefName,additions,deletions,changedFiles gh pr checks --json name,status,conclusion 2/dev/null || true最终输出 PR 编号、URL、分支、增删行数、CI 检查状态、被引用的 PRP 产物以及后续操作gh pr view number --web打开、/code-review number审查、gh pr merge number合并。文档还列了两个边界超过 20 个文件的大 PR 会提示拆分需要强推时只用--force-with-lease不用--force。一条完整路径的核对方式四个阶段跑完后磁盘上应该有如下产物链这就是整条路径完成的可核对证据.claude/PRPs/prds/{name}.prd.md # 阶段表最终为 complete .claude/PRPs/plans/completed/{name}.plan.md # 已归档 .claude/PRPs/reports/{name}-report.md # 五层验证结果 GitHub PRgh pr view 可查到正文引用了上述产物中间任何一个阶段都可以停下PRD 生成后隔天再开会话把文件路径传给/prp-plan即可从断点继续——这正是产物落在磁盘而不是上下文里的意义。限制与替代路径docs/PLAN-PRD-PATTERN.md 说明 ECC 同时提供一条更精简的原生路径/plan-prd→/plan→tdd-workflowskill →/pr产物在.claude/prds/、.claude/plans/而prp-*命令集被定位为 legacy/deep workflow仍然有效适合已有.claude/PRPs/产物或想要更重流程的场景。两条路径不要混用产物目录。范围已经清楚的小改动bug 修复、单文件增补不需要 PRD直接给/prp-plan传自由文本描述即可命令会跳过 PRD 解析直接做计划。/prp-implement会执行git checkout -b、git pull --rebase、移动计划文件等操作在工作区脏的 main 分支上它会拒绝继续先自行处理未提交改动。/prp-pr硬依赖ghCLI 与认证非 GitHub 远端环境无法走这一步。各阶段的完整阶段定义、模板和验证清单见 commands/prp-prd.md、commands/prp-plan.md、commands/prp-implement.md、commands/prp-commit.md 和 commands/prp-pr.md。【免费下载链接】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），仅供参考