Plugin 只是手段，真正决定团队工程质量的，是"工作如何被正确组装和使用"这套机制本身。
我们发现最优解不是构建一个大而全的 Plugin 体系，而是：用开源 Skills 串联流程，用领域 Skills 填补空白，用项目 CLAUDE.md 积累上下文。
本文介绍一种闭环的团队工程流程设计，将日常开发活动系统化为 Planning → Execution → Verification → Closing 四个阶段。
流程全貌
团队工程流程的四个阶段形成闭环：
┌─────────────────────────────────────────────────────────────┐
│ │
│ 【规划阶段 - Planning】 ←───────→ 【执行阶段 - Execution】 │
│ ↓ ↓ │
│ │ │ │
│ ↓ ↓ │
│ 【收尾阶段 - Closing】 ←───────→ 【验证阶段 - Verification】 │
│ │
└─────────────────────────────────────────────────────────────┘
本文将依次展开：反思弧线（我们如何形成这套认识）→ 四阶段框架 → 核心原则。
反思弧线
起点：整理团队 Plugin
我们想构建一套团队 Plugin 来整理 AI 工具经验。把个人在项目中的 Skill 配置、工具链、使用模式整理成可复用的"团队资产"。
这个思路看起来合理：如果个人 Skill 能提升个人效率，那团队 Plugin 就能提升团队效率。
发现：Plugin 是资源合集，流程是另一回事
Plugin 是资源的合集（Skills / MCP / Hooks / 文档模板），但资源摆在那里不会自动产生价值。
Plugin 解决的是"用什么工具"，而不是"如何正确使用工具"。一个团队可能拥有所有工具，但如果没有共识的使用方式，工具就是散乱的。
这是两个不同维度的问题。
关键洞察：开源 Skills 已覆盖 80% 核心流程
在研究如何构建团队 Plugin 的过程中，我们发现一个事实：业界已经提供了非常完整的 Skills 体系，覆盖软件工程的核心流程。
从需求探讨（brainstorming）、到计划制定（writing-plans）、到代码构建（Skills + MCP + Hooks）、到调试（debugging-strategies）、到验证（simplify）、到标准化交付（git-commit + changelog-generator）——这套体系不是某个公司闭门造车，而是 AI 辅助软件工程领域的社区智慧沉淀。
真正需要内部维护的是领域 Skills。流程 Skills 用开源的，串联团队工作流程；领域 Skills（特定业务领域的知识积累，如能源行业）由内部维护。
核心认识：工具不自动产生价值，价值来自流程共识
Plugin 是工具箱，但工具本身不会自动产生价值。
决定团队工程质量的，是"工作如何被正确组装和使用"这套机制本身。团队真正的护城河是流程共识——在什么阶段用什么资源、如何串联、验收标准是什么。
结论：护城河是流程，不是工具
最终的认识：团队工程流程的最优解不是构建一个大而全的 Plugin 体系，而是：
- 用开源 Skills 串联团队工作流程（四阶段闭环）
- 用领域 Skills 填补垂直知识空白
- 用项目 CLAUDE.md + docs 积累上下文
三层资源的取舍：
| 类型 | 来源 | 是否内部维护 | 示例 |
|---|---|---|---|
| 流程 Skills | 开源，直接用 | 否 | brainstorming, simplify, git-commit |
| 领域 Skills | 内部维护 | 是 | 能源行业特定逻辑、业务校验规则 |
| 项目上下文 | CLAUDE.md + docs | 是（各项目独立迭代） | 架构决策、踩坑记录 |
四阶段框架
规划阶段 - Planning
目标：在动手之前先共识问题与验收标准。
使用资源：brainstorming → writing-plans
我们踩过的坑：跳过讨论直接实现是最大的时间浪费。
执行阶段 - Execution
目标：小步迭代，持续积累上下文。
使用资源：Skills + MCP + Hooks + 迭代 CLAUDE.md/docs
我们踩过的坑：追求完美而非可接受，导致迭代停滞。
验证阶段 - Verification
目标：交付前发现问题。
使用资源：simplify（AI 审技术）+ 人工（审业务）
我们踩过的坑：Code Review 流于形式或过于细节，都是无效验证。
收尾阶段 - Closing
目标：知识沉淀，每次变更有据可查。
使用资源：git-commit（Conventional Commits）+ changelog-generator
我们踩过的坑：形式化执行等于无效。
四阶段为何闭环
四个阶段不是随意拼凑的，它们之间有内在的闭环逻辑：
- Planning → Execution：Planning 的输出是 Execution 的输入。没有清晰的计划和验收标准，Execution 就是盲目的迭代。
- Execution → Verification：Execution 的产出必须经过 Verification 才能交付。跳过验证是一种技术债。
- Verification → Closing：Verification 通过的产出才能进入 Closing 阶段。修复计划没完成，就不会进入标准化交付。
- Closing → Planning（下一个循环）：每一次 Closing 都积累了新的上下文——新的 changelog、更新的文档、迭代后的 CLAUDE.md——这些成为下一个 Planning 阶段的起点。
核心原则
- brainstorming 是强制入口 — 先共识问题，再共识方案
- 构建循环是小步迭代 — 没有"完成"，只有"当前可接受"
- 验证是双重保障 — AI 审技术，人工审业务
- 交付是知识沉淀 — 标准化提交，自动化 changelog