本目录是 CodeBuddy Agent 在本项目中的行为规范和可复用能力包。任何 AI Agent 或人类开发者接手本项目前,先读本文。
.codebuddy/
├── README.md # 本文件:总览与导航
├── rules/ # 规则(强制性约束)—— 开发者 / Agent 执行层
│ ├── *.md # 9 份规则,详见下表
│ └── .archived/
│ ├── feedback/ # 使用框架过程中发现的问题与改进记录
│ └── README.md # 归档说明
├── skills/ # 技能(可复用工作流)—— 开发者 / Agent 执行层
│ └── */SKILL.md # 9 个 skill,详见下表
└── governance/ # 治理层 —— Leader / workshop 负责人视角
├── README.md # 治理层导航
├── delivery-lifecycle.md # 交付流程契约(流程通用性)
├── quality-dashboard.md # 质量仪表盘(质量维度)
├── retrospective-sop.md # 复盘 SOP(经验沉淀)
├── architecture-fitness.md # 架构健康度(技术先进性)
└── tooling-landscape.md # 管理工具全景(管理工具协同)
三层分工:
| 层次 | 读者 | 产出 |
|---|---|---|
governance/ | Leader、workshop 负责人 | 治理框架、健康度评估、经验复盘机制 |
rules/ | 开发者、Agent | 执行期的强制约束 |
skills/ | Agent | 可按需加载的工作流模板 |
上层不重复下层内容,只做导航和抽象;下层变更不引起上层级联修改。
Rules 是强制性约束。Agent 在本项目内工作时必须遵守。
| 编号 | 文件 | 主题 | 关键约束 |
|---|---|---|---|
| R0 | meta-principles.md | 元原则(所有规则的根) | 真实编译 / 不可执行测试 / 棘轮阈值 / 抽象化 / 契约优先——技术栈无关,alwaysApply: true |
| R1 | requirement-expansion.md | 需求扩写规范 | 将原始需求扩写为结构化文档,强制审视 + 主动提问 |
| R2 | project-architecture.md | 项目架构规范 | 三层架构、模块化、目录组织、技术栈声明 |
| R3 | frontend-core.md | 前端核心规范(技术栈无关) | 组件设计 / 类型系统 / 状态分层 / API 契约消费 / 路由 / 样式 / 错误边界 / 性能 |
| R3-vue | frontend-vue.md | 前端规范 · Vue 3 + TypeScript 参考实现 | R3 在 Vue 栈的完整落地 |
| R4 | backend-core.md | 后端核心规范(技术栈无关) | 分层 / 边界对象 / API 契约 / 异常 / 配置 / 日志 / 并发 / 安全基线 |
| R4-java | backend-java-spring.md | 后端规范 · Java Spring Boot 参考实现 | R4 在 Java 栈的完整落地(~1600 行) |
| R4+ | domain-modeling.md | 领域建模指引(DDD 工程化) | 限界上下文 / 聚合 / 领域事件 / 仓储 / CQRS / 防腐层——中等以上复杂度业务必读 |
| R4++ | microservice-architecture.md | 微服务架构规范 | 服务划分 / 通信(同步+异步)/ 分布式事务(Saga)/ 治理 / 可观测性 / 部署演进——采用微服务时必读 |
| R5 | testing-standards.md | 测试规范总纲 | 单元/集成/功能测试分层;派生自 R0 原则 1~3 |
| R5a | unit-testing.md | 单元测试规范与打分 | JUnit 5 + Mockito;6 维度打分(满分 100) |
| R5b | functional-testing.md | 功能测试规范与打分 | @SpringBootTest + 真实外部依赖(compose 或容器库);验收标准驱动 |
| R6 | git-conventions.md | Git 提交规范 | 分支策略、Conventional Commits、commit 粒度 |
| — | requirement-analysis.md | 需求分析原则 | 最小必要原则,避免"所有需求都搭全家桶" |
Skills 是可按需加载的工作流模板。通过
use_skill工具调用。详细元数据与依赖图见
skills/SKILLS.md(v2 Agent Harness 规格);规格定义见skills/_AGENT_HARNESS_SPEC.md。
| Skill | 定位 | 典型触发场景 |
|---|---|---|
requirement-workflow | 需求处理 SOP(顶层工作流) | 确认处理 <PM-Tool> 需求:自动分支切换、分析、开发、测试、验证、通知 |
requirement-analysis | 需求复杂度分析 | 从 <PM-Tool> 读取需求后,判断需要前端/后端/数据库/Docker |
scaffold | 模块脚手架生成 | 按字段清单生成后端分层文件 + 前端 api/store/view |
code-review | 深度代码审查 | 完成开发后、提交前的代码质量审查 |
api-docs | API 文档生成 | 基于 OpenAPI / 等效契约输出 Markdown API 文档 |
cicd-pipeline | CI/CD 配置生成 | 生成 <CI-Platform> 流水线 + 质量门禁配置 |
changelog | 变更日志生成 | 基于 Conventional Commits 生成 CHANGELOG |
tapd | <PM-Tool> 集成(以 TAPD 为参考实现) | 查询/更新需求、bug、迭代、工时;替换 <PM-Tool> 时此 skill 需整体替换 |
skill-creator | 元能力:创建 skill | 创建新 skill 时的引导 |
关键字段(每个 skill 的 _meta.json 都含):
triggers — 关键词 + 上下文触发规则dependencies — 依赖的其他 skills / rules / 外部工具inputs / outputs — 机器可读的输入输出契约side_effects — 五维副作用分类(fs / net / db / git / external-api)idempotent / requires_confirmation — 幂等性与用户确认要求cost — 成本预估(时长、LLM 调用数、复杂度)"静态检查通过 ≠ 代码能运行"。任何交付必须跑通真实编译(mvn compile / tsc --noEmit),不允许仅凭 read_lints 0 错误、括号平衡通过来断言代码正确。工具链版本不匹配时用容器锁死项目目标版本。
代码评审前必须已通过:
@SpringBootTest 或等效)从 <PM-Tool> 拿到需求后必须:
| 场景 | 该读什么 |
|---|---|
| 刚接手项目 | 本 README → project-architecture.md → requirement-workflow/SKILL.md |
| 准备写后端代码 | backend-core.md(通用)+ 对应栈实现(如 backend-java-spring.md)→ code-review checklist |
| 准备写测试 | testing-standards.md 总纲 → unit-testing.md 或 functional-testing.md |
| 准备提交代码 | git-conventions.md → code-review skill |
| 想新增模块 | scaffold skill → 产出后跑 mvn compile → 补业务逻辑 |
| 改动涉及循环依赖、拦截器、过滤器 | backend-core.md §1.2 + 对应栈参考实现(Java 见 backend-java-spring.md §1.1 §6.8) |
| 场景 | 该读什么 |
|---|---|
| 刚接手团队 / 项目 | governance/README.md → 按 5 维度依次读 |
| 流程卡壳、责任不清 | governance/delivery-lifecycle.md |
| 不知道质量怎么衡量 | governance/quality-dashboard.md |
| 要启动复盘(周会 / 季度 / 事故) | governance/retrospective-sop.md |
| 判断技术栈要不要升级 | governance/architecture-fitness.md |
| 新人不知道用哪个工具 / 告警分派 | governance/tooling-landscape.md |
在使用本框架过程中发现的问题(规则漏洞、skill 缺陷、工具盲区)记录在 .archived/feedback/FB-XX-*.md,每条 FB 有明确的"来源 / 触发条件 / 建议修复 / 状态"。RESOLVED 的 FB 保留作为历史案例追溯;OPEN 的是下一轮迭代的待办输入。完整的复盘触发时机与闭环机制见 governance/retrospective-sop.md。