老项目的屎山代码很多，功能模块庞杂，让 codex 改代码偶尔会出现漏改，或动了本不该动的代码，所以整个项目需要先炼化后再 vibe coding. 使用 /goal 命令就很合适，把整个项目炼成 skills AGENT.md 再搭配手中的工作流 spec/superpower等等，codex再写起代码来能更精准，思考会更全面。 注意：需要开启 subagent 和 goal 功能,搭配 gpt-5.5 xhigh 效果更好，我试过用 5.4 也可以 但是炼化出的 skill 没 5.5 数量多和细节更完整。
/goal 你的任务是基于当前项目代码库，使用多路 subagent 和 $skill-creator 并行梳理项目知识，补充或完善开发过程中 AI 需要依赖的 `.agents/skills/` 与 `AGENTS.md`，目的是后续 AI 在修改、重构、排障、测试、扩展功能时能更准确理解项目，避免 AI 出现遗漏、重复造轮子、破坏既有架构、重复求证和错误假设等问题。
核心要求：
1. 始终保持当前环境允许的最大并发 subagent 数量。
2. 只要存在可独立分析的模块、目录、技术栈或开发场景，就立即分派新的 subagent。
3. 不要让 subagent 做重复工作；每个 subagent 必须有清晰边界、输入范围和预期产出。
4. 所有结论必须来自现有代码、配置、文档、测试、提交记录或可验证的项目事实，不允许凭空编造。
5. 优先补充对后续 AI 开发最有帮助的信息，而不是写泛泛的项目介绍。
第一阶段：主 agent 快速盘点项目
- 查找并阅读现有的 `AGENTS.md`、`.agents/skills`、README、docs、package/build 配置、测试配置、CI 配置、主要入口文件。
- 用 `rg --files` 或等价方式建立项目结构认知。
- 识别项目的主要技术栈、运行方式、测试方式、代码分层、核心业务域、关键模块和高风险区域。
- 基于盘点结果拆分 subagent 任务。
第二阶段：并行分派 subagent
根据项目实际情况，将以下方向拆成多个 subagent 并行执行；如果某方向不存在则跳过，如果某方向过大则继续拆分：
- 架构与目录结构：分析项目整体分层、入口、模块边界、核心数据流。
- 本地开发与构建：分析安装、启动、构建、环境变量、脚本、依赖管理。
- 测试与质量保障：分析测试框架、测试命令、fixture、mock、覆盖重点、常见失败原因。
- 前端/UI：分析组件组织、样式系统、状态管理、路由、交互约定、设计约束。
- 后端/API：分析服务边界、路由、控制器、业务逻辑、错误处理、接口契约。
- 数据层：分析数据库、schema、迁移、ORM、缓存、存储、数据模型约定。
- 集成与外部服务：分析第三方 API、认证、支付、消息队列、文件存储、邮件等。
- 安全与权限：分析鉴权、授权、敏感信息、输入校验、权限边界。
- 运维与发布：分析 CI/CD、部署、配置、日志、监控、故障排查路径。
- 既有工具与复用点：找出现有 helper、utils、hooks、services、组件库、脚手架，避免后续重复实现。
- 历史文档与隐性约定：从 docs、注释、测试、配置和命名中提炼项目约定。
每个 subagent 的产出必须包含：
- 分析范围：读了哪些目录、文件、配置或测试。
- 关键事实：项目中已经存在什么能力、模式、工具、约定。
- 后续 AI 必须知道的注意事项。
- 容易误改、重复造轮子或遗漏的点。
- 建议写入 `AGENTS.md` 的内容。
- 建议新增或更新的 `.agents/skills`，并说明触发场景。
- 未确认的信息和需要主 agent 二次核验的地方。
第三阶段：主 agent 汇总与去重
- 汇总所有 subagent 结果，去除重复、冲突和泛泛描述。
- 对冲突结论进行二次查证，以代码事实为准。
- 不要把所有内容堆进一个大 skill；按真实开发场景拆成小而明确的 skills。
- 如果已有 `.agents/skills` 或 `AGENTS.md`，必须在保留原有有效内容的基础上增量修改，不要粗暴覆盖。
- 如果某个 skill 只是通用工程建议，且没有项目特异性，不要创建。
第四阶段：补充 `.agents/skills`
为后续 AI 高频开发场景创建或更新项目专属 skill。每个 skill 应该包含：
- 何时使用这个 skill。
- 该场景下必须先阅读的关键文件。
- 推荐执行流程。
- 常用命令。
- 项目内已有可复用模块、helper、组件或服务。
- 禁止事项或高风险误区。
- 验证方式。
优先考虑这些 skill 类型，但必须根据项目实际裁剪：
- 本地开发与环境启动 skill。
- 测试、排障与质量验证 skill。
- 前端功能开发 skill。
- 后端/API 开发 skill。
- 数据模型/迁移 skill。
- 权限/认证相关 skill。
- 外部集成相关 skill。
- 发布/部署/CI 排障 skill。
- 项目架构导航 skill。
- 代码复用与避免重复实现 skill。
第五阶段：补充 `AGENTS.md`
`AGENTS.md` 应该作为 AI 进入项目后的第一份上下文，内容应简洁、可执行、项目专属。至少包括：
- 项目是什么，以及主要技术栈。
- 关键目录和模块职责。
- 本地启动、构建、测试、lint/typecheck 命令。
- 修改代码前应先阅读的文件。
- 核心架构约定和代码风格约定。
- 已有能力和复用入口，避免重复造轮子。
- 常见开发任务应该走哪些路径。
- 高风险区域和禁止随意改动的地方。
- 环境变量、外部依赖、生成文件、迁移文件等注意事项。
- 完成修改后的验证清单。
第六阶段：验证
完成写入后必须执行以下检查：
- 确认新增或修改的 skill 文件路径正确、结构清晰、触发场景明确。
- 确认 `AGENTS.md` 不包含无法从项目中验证的臆测。
- 确认引用的命令、目录、文件名真实存在。
- 运行适合文档变更的轻量验证，例如查看 git diff、检查 Markdown 结构、必要时执行项目已有的 lint/test 命令。
- 最后输出总结：新增/更新了哪些 skills，`AGENTS.md` 补充了哪些内容，仍有哪些项目知识无法确认。
工作原则：
- 并行优先：始终保持 subagent 满额运行，直到没有可独立推进的分析任务。
- 事实优先：所有项目说明必须能追溯到代码、配置、文档或测试。
- 场景优先：skills 面向后续 AI 的具体开发场景，而不是泛泛介绍。
- 增量优先：尊重已有文档和用户改动，不覆盖无关内容。
- 简洁优先：写对后续开发有用的内容，不制造冗长背景文档。
1 个帖子 - 1 位参与者
来源: LinuxDo 最新话题查看原文