提案：团队模板仓库（team-template），降低新团队上手门槛

类型：Proposal / Discussion
影响面：在 teamai-hub GitHub 组织下新增公开模板仓库；teamai-cli 代码零改动（首版）

背景与问题

当前 teamai init 的流程假设团队 repo 已经存在：选 scope → 输入一个已有的 team repo → clone → 注册成员。

它解决的是「团队已有组织好的 repo，新成员如何接入」。但它没有解决另一个更前置的缺口：

• 一个新团队 / 新用户，手上根本没有 team repo。
• 不知道 manifest/roles.yaml、skills/、rules/ 该长什么样、怎么摆。
• 只能对着 README 手搓目录结构 —— 这是当前最大的上手摩擦点。

代码确认：仓库内目前没有任何 template / scaffold 能力（import --from-org --bootstrap 是从已有 org 反向抽取，方向相反）。

目标

提供一个开箱即用的团队模板仓库。用户通过 GitHub「Use this template」一键生成自己的 team repo（history 干净、无 fork 关系），改成自己的 remote 后即可：

teamai init --repo <我的-team-repo>
# init 时选择自己的角色，只拿到对应命名空间的 skills/rules

方案：两种模式，单一内容源

同时提供两种模板形态，覆盖不同上手偏好。所有模板仓库统一落在 teamai-hub GitHub 组织下。

• 落点：GitHub 公开组织 teamai-hub，不进 teamai-cli 代码仓库。
• CLI 改动：首版为零。仅可选地在 teamai init「还没有 team repo」的分支打印一行指向 teamai-hub 组织的引导文案（后续再议）。

⚠️ 关键约束：单一内容源，B 从 A 派生

两种模式绝不各自手写内容，否则 common/ rules 和各角色内容必然漂移（改了 A 的 frontend rule，B 的 template-frontend 不会跟着变）。

做法：teamai-hub/team-template（模式 A）是唯一 source of truth。模式 B 的单角色 repo 由一个拆分脚本从 A 派生生成：

• 按角色切出 skills/<role>/、rules/<role>/；
• 自动注入全员共享的 common/ rules；
• 生成只含该角色的 roles.yaml。

这样两种模式共用一套内容、单点维护、不漂移。派生脚本放在 team-template repo 内，可由 CI 在内容更新时自动重建 teamai-hub 下的各单角色 repo。

目录约定（已从源码核对，非推测）

team-template/
├── README.md                # 上手引导：Use this template → init → 选角色
├── manifest/roles.yaml      # 全部角色的命名空间映射
├── skills/<role>/<skill>/SKILL.md
└── rules/
    ├── common/              # 全员共享：沟通规范、保密红线、AI 使用准则
    └── <role>/*.md

首批角色范围（6 个）

按「受众是否确定在用 AI 编码工具」+「内容能否做出真血肉」筛选，首批 6 个，分两层区别对待起草标准：

common/ rules（全员）：communication、confidentiality-redline、ai-usage-conduct。

重叠治理：qa 只放用例设计 / 缺陷分级 / 回归策略，「代码质量」类内容归 frontend/backend。scanRoleAwareSkills 有重名检测，同名 skill 会直接报错，命名空间必须划分干净。

粗估首版 30–40 个文件。

待讨论的开放问题

1. 模板是否同时作为「长期 source」？（本提案最关键的未决点）
   teamai 已有 source add 能力。若把 team-template 设计成既能一键起点、又能被用户 source add 订阅，则后续对 frontend 等 rules 的改进能回流给老用户；否则「clone 完即断线」是路径 A 的固有硬伤。

   • 选项 A：一次性脚手架（rules 写成起点占位）。
   • 选项 B：活的团队基线（rules 写成可持续维护，支持 source 订阅回流）。倾向 B。
   • 这是唯一可能需要碰一点 CLI 的方向。

2. 非技术角色的工具前提：PM / 设计师日常是否真在 Claude Code / Cursor 里工作？首批用 pm/data/design 各 1 个标志性 skill 来验证，再决定是否加深。

3. 命名与可发现性：teamai-hub 组织下的仓库命名规范（模式 A 的 team-template / 模式 B 的 template-<role>）、如何在 teamai-cli README 中让用户发现它。

非目标（首版明确不做）

• 不改 teamai init 核心逻辑、不新增 --template 内置脚手架（CLI 内置生成，验证需求后再议）。
• 不做 HR / marketing / techwriter / sre / pmo（第二批 roadmap）。
• 不做法务 / 财务 / 销售（强公司特异性 & 合规，通用模板给不出价值，交由各公司自行 push）。

Roadmap（第二批，先写进模板 README 不实现）

hr、marketing、techwriter、sre、pmo —— 需求真实但内容更因公司而异，留 push 接口让各团队自填。