@colin4k1024/tsp 2.4.0

package/examples/full-lifecycle-demo.md

@@ -0,0 +1,446 @@
+# 完整交付生命周期演示脚本
+
+> 适用对象：要向团队、管理层或客户演示 Team Skills Platform 如何把“从需求到最终上线”串成一条完整流水线的人。  
+> 当前版本已对齐新版主链：`/team-intake -> /team-plan -> /team-execute -> /handoff -> /team-review -> /team-release -> /team-closeout`。
+
+## 1. 演示目标
+
+这份脚本不是单纯展示“命令能跑”，而是展示平台如何解决 4 个实际问题：
+
+1. 需求进入后不会立刻跳到实现
+2. 方案阶段必须先 challenge，再 design review
+3. 上线前会留下测试放行、部署上下文和发布方案
+4. 发布不是结束，观察窗口后的 `/team-closeout` 才是正式收口
+
+## 2. 演示建议时长
+
+- 压缩版：12-15 分钟
+- 标准版：20-25 分钟
+- 深度版：30 分钟以上
+
+如果时间有限，优先演示这 5 个节点：
+
+- `/team-intake`
+- `/team-plan`
+- `/team-review`
+- `/team-release`
+- `/team-closeout`
+
+## 3. 推荐演示场景
+
+继续沿用审批与协作项目语境，场景设为：
+
+**审批与交付协同系统**
+
+这个场景适合演示的原因：
+
+- 同时包含产品需求、流程审批、权限、前后端、通知、归档
+- 很容易展示 custom overlay、shared skills 和主链命令的配合
+- 既有业务验收，也有发布和观察窗口
+
+## 4. 演示前准备
+
+正式演示前，建议先准备好这些内容：
+
+- 已安装好当前平台
+- 已生成最新产物
+- 打开项目仓库根目录
+- 预先准备一份需求文档
+- 预先准备一个空的 `docs/artifacts/` 区域，便于现场展示文件落盘
+
+建议现场先执行：
+
+```bash
+node scripts/build-platform-artifacts.js
+node scripts/validate-library.js
+```
+
+## 5. 演示总览
+
+本次演示按下面 9 段走：
+
+1. 原始需求输入
+2. `/team-intake`
+3. `/team-plan`
+4. `/team-execute` 后端
+5. `/handoff`
+6. `/team-execute` 前端
+7. `/team-review`
+8. `/team-release`
+9. `/team-closeout`
+
+建议开场就先给观众看这条链路，让他们知道今天不是“演示一个命令”，而是“演示一条可治理的流水线”。
+
+## 6. 原始需求输入
+
+### 6.1 可以直接展示的需求摘要
+
+```text
+需求名称：审批与交付协同系统
+
+目标：
+1. 替代邮件 + Excel 的跨团队审批与交付协作方式
+2. 覆盖申请、审批、任务、通知、归档全流程
+3. 支持申请人、审批人、协作人、运营和管理员等多类角色
+
+约束：
+1. 可能存在私有流程、权限和内部系统集成
+2. 技术栈：Spring Boot + MySQL + Redis + React + TypeScript
+3. 员工数据涉及合规与审计
+```
+
+### 6.2 主持人串词
+
+可以这样说：
+
+> 现在我们不是从“开发怎么写”开始，而是从一份真实需求开始。接下来每一步都不是口头讨论，而是会形成结构化输出，并最终落盘成项目级 artifact。
+
+## 7. 阶段一：/team-intake
+
+### 7.1 演示目标
+
+让观众看到平台不会一上来就拆任务，而是先锁定：
+
+- 目标
+- 范围
+- 不做项
+- 风险
+- 参与角色
+- 是否命中企业扩展能力
+
+### 7.2 建议输入脚本
+
+```text
+请按 Team Skills Platform 工作模型处理当前任务。
+先执行 /team-intake，基于下面需求锁定目标、范围、约束、参与角色和主要风险。
+
+任务背景：
+[粘贴需求摘要]
+
+特别关注：
+1. 是否属于企业内部应用
+2. 是否需要启用审批流、数据权限、企业 SDK
+3. 前后端和 QA、DevOps 是否都要进入主链
+4. 哪些问题必须进入 requirement challenge
+```
+
+### 7.3 屏幕上要强调的看点
+
+- 有明确的 `In Scope / Out of Scope`
+- 有 `待确认项`
+- 有 `风险`
+- 有 `候选技能装配`
+- 不会直接开始排期或开发
+
+### 7.4 现场要展示的落盘文件
+
+- `docs/artifacts/{date}-{slug}/prd.md`
+- `docs/artifacts/INDEX.md`
+
+### 7.5 主持人串词
+
+> Intake 的价值不是“写个摘要”，而是防止错误的需求直接进入 plan。这里已经开始建立事实源，后面所有角色都消费同一套输入。
+
+## 8. 阶段二：/team-plan
+
+### 8.1 演示目标
+
+展示新版主链最重要的变化：
+
+- 先 challenge
+- 再动态分组讨论
+- 再 design review
+- 最后才进入 `handoff-ready`
+
+### 8.2 建议输入脚本
+
+```text
+基于当前 intake 结果执行 /team-plan。
+
+要求：
+1. 先完成 Requirement Challenge Session
+2. 明确动态讨论分组和各角色质疑点
+3. 输出 delivery plan、风险、依赖、阶段负责人
+4. 明确什么时候才算 handoff-ready
+5. 若需要，补充架构设计与 API contract 的落盘位置
+```
+
+### 8.3 现场要展示的看点
+
+- `Requirement Challenge Session`
+- `Dynamic Discussion Group`
+- `Design Review Board`
+- `handoff-ready` 不是默认 true
+- 计划里明确角色责任和依赖
+
+### 8.4 现场要展示的落盘文件
+
+- `docs/artifacts/{date}-{slug}/delivery-plan.md`
+- `docs/artifacts/{date}-{slug}/arch-design.md`
+- 必要时的 `docs/adr/ADR-xxx-*.md`
+- `docs/memory/project-context.md`
+
+### 8.5 主持人串词
+
+> 旧式流程最常见的问题是需求没分析透就开始 plan。这里的演示重点，是让大家看到 plan 不是第一反应，而是 challenge 和设计收口之后的冻结结果。
+
+## 9. 阶段三：/team-execute（后端）
+
+### 9.1 演示目标
+
+展示实现不是“自由开工”，而是消费已经准备好的方案、契约和 handoff。
+
+### 9.2 建议输入脚本
+
+```text
+按已确认的 delivery plan 和 arch design 执行 /team-execute。
+
+本轮只做后端部分：
+1. 离职申请接口
+2. 交接任务生成
+3. 数据权限接入边界
+
+请输出：
+- 实现范围
+- 关键改动
+- 自测结果
+- 风险与未完成项
+```
+
+### 9.3 现场要展示的看点
+
+- 是否检查了 `handoff-ready`
+- 是否有明确的“不做项”
+- 是否留下 `execute-log`
+- 是否把阻塞问题写出来，而不是藏在对话里
+
+### 9.4 现场要展示的落盘文件
+
+- `docs/artifacts/{date}-{slug}/execute-log.md`
+- 必要时追加 `docs/memory/decisions.md`
+
+## 10. 阶段四：/handoff
+
+### 10.1 演示目标
+
+让观众看到 handoff 不是“顺嘴说一下”，而是正式的阶段切换凭证。
+
+### 10.2 建议输入脚本
+
+```text
+请基于当前后端实现结果执行 /handoff。
+
+要求：
+1. 说明已完成事实
+2. 说明未完成项和风险
+3. 说明下一跳角色要做什么
+4. 标明当前阶段、目标阶段与 readiness
+```
+
+### 10.3 现场要展示的看点
+
+- handoff 有固定结构
+- 有 `当前阶段 -> 目标阶段`
+- 下游可以直接消费，不需要重新猜背景
+
+### 10.4 现场要展示的落盘文件
+
+- `docs/artifacts/{date}-{slug}/handoffs/001-tech-lead-to-backend-engineer.md`
+
+## 11. 阶段五：/team-execute（前端）
+
+### 11.1 演示目标
+
+展示前端同样处在主链里，而且会消费前面的设计、契约和 handoff，而不是单独飞。
+
+### 11.2 建议输入脚本
+
+```text
+继续执行 /team-execute，本轮只做前端部分：
+1. 离职申请表单
+2. 交接任务看板
+3. HR 汇总视图
+
+要求：
+1. 说明 UI 范围和边界态
+2. 说明复用了哪些组件或设计约束
+3. 输出自测结果与 QA 关注点
+```
+
+### 11.3 现场要展示的看点
+
+- UI 不是最后才想
+- QA 关注点在 execute 阶段就提前写出来
+- 前后端都通过主链回到同一套 artifact
+
+## 12. 阶段六：/team-review
+
+### 12.1 演示目标
+
+把“测试通过”和“允许上线”拆开，这是新版主链非常适合拿来演示的点。
+
+### 12.2 建议输入脚本
+
+```text
+请执行 /team-review。
+
+要求：
+1. 基于前后端交付物做测试与风险评审
+2. 给出阻塞项和放行建议
+3. 单独输出 launch acceptance 结论
+4. 明确是 Go、Conditional Go 还是 No-Go
+```
+
+### 12.3 现场要展示的看点
+
+- `test-plan.md`：测试范围、矩阵、风险
+- `launch-acceptance.md`：上线准入结论
+- 这两个文件职责不同
+
+### 12.4 现场要展示的落盘文件
+
+- `docs/artifacts/{date}-{slug}/test-plan.md`
+- `docs/artifacts/{date}-{slug}/launch-acceptance.md`
+
+### 12.5 主持人串词
+
+> 很多团队的问题不是不会测，而是“测试结论”和“上线决定”混在一起。这里故意把它拆开，演示平台如何强制留下准入结论。
+
+## 13. 阶段七：/team-release
+
+### 13.1 演示目标
+
+展示 release 不是一句“可以发了”，而是明确：
+
+- 怎么发
+- 怎么回滚
+- 看什么
+- 谁值守
+
+### 13.2 建议输入脚本
+
+```text
+请执行 /team-release。
+
+要求：
+1. 基于 launch acceptance 结论组织发布
+2. 输出 deployment context 与 release plan
+3. 明确观察窗口、关键指标和值守责任
+4. 给出回滚条件与回滚入口
+```
+
+### 13.3 现场要展示的看点
+
+- `deployment-context.md`
+- `release-plan.md`
+- 观察窗口是 release 阶段定义的，不是事后补写的
+
+### 13.4 现场要展示的落盘文件
+
+- `docs/artifacts/{date}-{slug}/deployment-context.md`
+- `docs/artifacts/{date}-{slug}/release-plan.md`
+
+## 14. 阶段八：/team-closeout
+
+### 14.1 演示目标
+
+这是昨天新主链里最值得重点展示的新增阶段。
+
+要让观众清楚看到：
+
+- 发布完成 != 任务完成
+- 观察窗口结束后才进入 closeout
+- closeout 会回写 backlog 和最终状态
+
+### 14.2 建议输入脚本
+
+```text
+请基于发布结果和观察窗口数据执行 /team-closeout。
+
+要求：
+1. 判断观察窗口是否可以结束
+2. 给出最终验收状态
+3. 说明残余风险如何处置
+4. 把遗留项回写 backlog
+5. 明确任务状态是 closed、follow-up-required 还是 re-open
+```
+
+### 14.3 现场要展示的看点
+
+- `closeout-summary.md`
+- `docs/memory/backlog.md` 或 backlog 回写结果
+- `docs/memory/lessons-learned.md`
+- `docs/memory/sessions/*.md`
+
+### 14.4 现场要展示的落盘文件
+
+- `docs/artifacts/{date}-{slug}/closeout-summary.md`
+- `docs/memory/backlog.md`
+- `docs/memory/lessons-learned.md`
+- `docs/memory/sessions/{date}-{nnn}-{slug}.md`
+
+### 14.5 主持人串词
+
+> 这一步是新版平台和旧式“做到 release 就结束”的最大差别。现在我们不仅知道系统发上去了，还知道它有没有稳定、风险有没有被正式接受、哪些事进入了下一轮 backlog。
+
+## 15. 演示时推荐展示的 artifact 清单
+
+如果你只想开一个文件树给观众看，建议按这个顺序展开：
+
+1. `docs/artifacts/{date}-{slug}/prd.md`
+2. `docs/artifacts/{date}-{slug}/delivery-plan.md`
+3. `docs/artifacts/{date}-{slug}/arch-design.md`
+4. `docs/artifacts/{date}-{slug}/execute-log.md`
+5. `docs/artifacts/{date}-{slug}/test-plan.md`
+6. `docs/artifacts/{date}-{slug}/launch-acceptance.md`
+7. `docs/artifacts/{date}-{slug}/deployment-context.md`
+8. `docs/artifacts/{date}-{slug}/release-plan.md`
+9. `docs/artifacts/{date}-{slug}/closeout-summary.md`
+
+这样观众会很直观地看到：每个阶段都有落盘，不是只有聊天记录。
+
+## 16. 压缩版讲法
+
+如果只有 10 分钟，建议这样讲：
+
+1. 先展示总链路
+2. 重点演示 `/team-intake`
+3. 快速展示 `/team-plan` 里的 challenge / design review
+4. 快速展示 `/team-review` 里的 `launch-acceptance.md`
+5. 快速展示 `/team-release` 里的 `deployment-context.md`
+6. 最后重点展示 `/team-closeout`
+
+一句话收尾：
+
+> 这套平台不是把一个任务拆得更复杂，而是把原来散落在聊天、脑子和临场决定里的关键事实，变成一条可治理、可演示、可交接的交付流水线。
+
+## 17. Solo Mode 怎么讲
+
+如果观众会追问“一人开发是不是也要这么重”，可以补这一段：
+
+- `team mode`：多人分工，强调 handoff
+- `solo mode`：单人承接，但保留同样的 gate
+- 在 `solo mode` 下，最重要的不是减少命令，而是不丢掉：
+  - review
+  - release
+  - closeout
+
+可直接引用：
+
+- [solo-delivery-mode.md](../docs/runbooks/solo-delivery-mode.md)
+- [solo-delivery-one-page.md](../docs/runbooks/solo-delivery-one-page.md)
+
+## 18. 关联入口
+
+- 总体使用说明：[../docs/runbooks/team-skills-usage.md](../docs/runbooks/team-skills-usage.md)
+- 主链字段规范：[../docs/runbooks/team-command-output-contracts.md](../docs/runbooks/team-command-output-contracts.md)
+- 持久化规则：[../docs/runbooks/artifact-persistence.md](../docs/runbooks/artifact-persistence.md)
+- 发布示例：[../docs/runbooks/team-release-example.md](../docs/runbooks/team-release-example.md)
+- 收口示例：[../docs/runbooks/team-closeout-example.md](../docs/runbooks/team-closeout-example.md)
+
+## 19. 这份演示脚本最适合的使用方式
+
+- 对内做平台宣讲
+- 对新项目做 onboarding 演示
+- 对管理层演示“为什么主链不是做到 release 就结束”
+- 对一人开发者演示“solo mode 也能保留治理”

package/examples/github-actions-supply-chain-CLAUDE.md

@@ -0,0 +1,83 @@
+# Example GitHub Actions Supply Chain CLAUDE.md
+
+适用于 GitHub Actions 为主的 CI/CD、供应链治理、发布自动化和 workflow 安全仓库。
+
+这类仓库的重点不是业务页面或接口，而是 workflow、token 权限、artifact、attestation、签名、发布与审计链路是否稳定可控。
+
+## 适用信号
+
+- 仓库大量依赖 `.github/workflows/` 完成构建、测试、发布或安全检查
+- 需求经常是 actionlint、scorecard、token 权限、attestation、签名或 runner 治理
+- 最终输出常常是 workflow 变更、门禁策略、审计记录和发布基线，而不是业务接口
+
+## 相对通用版的主要差异
+
+### 1. 角色链路更偏平台治理与发布
+
+- 默认保留：`tech-lead`、`architect`、`qa-engineer`、`devops-engineer`
+- 若需要排期治理，再引入 `project-manager`
+- 一般不把 `frontend-engineer`、`backend-engineer` 作为默认主力角色，除非仓库同时承载业务服务代码
+
+### 2. 命令流更强调 `/harness-audit` 与发布治理
+
+- 建议链路：`/team-intake` -> `/team-plan` -> `/tdd` -> `/team-execute` -> `/harness-audit` -> `/team-review` -> `/team-release`
+- 若重点是 workflow 语法或安全问题，可中间插 `/code-review` 或 `/build-fix`
+- `/harness-audit` 适合在大量 workflow / runbook / 门禁入口调整后统一收敛缺口
+
+### 3. 项目约束更偏 workflow 与证据链
+
+- workflow 变更必须说明触发条件、权限边界、失败路径和回滚方式
+- 所有供应链门禁结论要回写到 review、release 或治理记录，不只停在 CI 产物
+- 重点 runbook 包括 actionlint、scorecard、github token permissions、zizmor、attestation、SLSA、SBOM
+
+## 一份更适合 workflow / 供应链治理仓库的精简成品
+
+````md
+# GitHub Actions Supply Chain Working Agreement
+
+## 项目定位
+
+- 类型：CI/CD 与供应链治理仓库
+- 重点：workflow 结构、token 权限、artifact 证明、发布安全、审计记录
+
+## 默认角色
+
+- `tech-lead`
+- `architect`
+- `qa-engineer`
+- `devops-engineer`
+
+## 默认命令流
+
+1. `/team-intake`
+2. `/team-plan`
+3. `/tdd`
+4. `/team-execute`
+5. `/harness-audit`
+6. `/team-review`
+7. `/team-release`
+
+## 项目约束
+
+- workflow 改动必须说明触发条件、权限边界、失败路径和回滚方式
+- token 权限收敛、attestation、SBOM、签名和 provenance 结论必须进入 review 或 release
+- workflow 静态检查、安全审计和供应链基线需要分层说明，不能混成一个结论
+
+## 常用提示模板
+
+```text
+/team-intake
+目标：重构 GitHub Actions 发布链路并补齐供应链门禁
+范围：workflow、permissions、attestation、SBOM、签名、review 说明
+不做：业务服务代码改造
+约束：必须区分 actionlint、scorecard、token 权限、SLSA 和 artifact attestation 的边界
+```
+
+```text
+/team-plan
+基于当前 intake 结果，拆 workflow 结构调整、权限治理、发布证据链和校验收口动作。
+要求指出哪些完成标准应先进入 /tdd，哪些缺口最终应通过 /harness-audit 验证。
+```
+````
+
+继续阅读：看 [../docs/runbooks/actionlint-workflow-gates.md](../docs/runbooks/actionlint-workflow-gates.md)、[../docs/runbooks/scorecard-supply-chain-gates.md](../docs/runbooks/scorecard-supply-chain-gates.md)、[../docs/runbooks/github-token-permissions-baseline.md](../docs/runbooks/github-token-permissions-baseline.md)。

package/examples/iac-kubernetes-platform-CLAUDE.md

@@ -0,0 +1,81 @@
+# Example IaC Kubernetes Platform CLAUDE.md
+
+适用于 Kubernetes 平台仓库、Helm Chart 仓库、GitOps / Policy 仓库、集群配置治理仓库或 IaC 安全门禁仓库。
+
+这类项目的重点不是业务页面或接口，而是 chart、manifest、policy、schema、dry-run、镜像与集群发布基线是否稳定可验证。
+
+## 适用信号
+
+- 仓库主要变更集中在 Helm Chart、Kubernetes YAML、Policy、环境配置或发布基线
+- 需求经常涉及 checkov、kubeconform、conftest、kyverno、helm unittest、kubectl server-side dry-run
+- 最终输出常常是 chart / manifest 变更、策略结果、环境风险评估和 release 说明，而不是业务功能上线
+
+## 相对通用版的主要差异
+
+### 1. 命令流更强调结构校验、策略门禁和发布收口
+
+- 建议链路：`/team-intake` -> `/team-plan` -> `/tdd` -> `/team-execute` -> `/verify` -> `/team-review` -> `/team-release`
+- 如果仓库同时承担平台规范维护，可在收口前补 `/harness-audit`
+- `/build-fix` 适合处理模板渲染、schema、policy 或 CI 失败
+
+### 2. 项目约束更偏 chart / manifest / policy 分层
+
+- 必须区分 chart 渲染问题、schema 问题、policy 问题和 server-side 接收问题
+- 所有 IaC 变更都要说明影响环境、失败路径和回滚方式
+- 验证结果必须回写到 review / release，而不是只停在 CI 输出
+
+### 3. 角色链路更偏架构、QA 与发布治理
+
+- 默认保留：`tech-lead`、`architect`、`qa-engineer`、`devops-engineer`
+- 若仓库同时生成服务配置或平台工具，再按需引入 `backend-engineer`
+
+## 一份更适合 IaC / Kubernetes 平台仓库的精简成品
+
+````md
+# IaC Kubernetes Platform Working Agreement
+
+## 项目定位
+
+- 类型：IaC / Kubernetes 平台治理仓库
+- 重点：Chart、Manifest、Policy、Schema、Release 与回滚基线
+
+## 默认角色
+
+- `tech-lead`
+- `architect`
+- `qa-engineer`
+- `devops-engineer`
+
+## 默认命令流
+
+1. `/team-intake`
+2. `/team-plan`
+3. `/tdd`
+4. `/team-execute`
+5. `/verify`
+6. `/team-review`
+7. `/team-release`
+
+## 项目约束
+
+- IaC 变更必须区分 chart、schema、policy 和 server-side 四层验证
+- 必须说明环境范围、失败路径、回滚方式和发布窗口
+- review 和 release 必须记录关键门禁结果与剩余风险
+
+## 常用提示模板
+
+```text
+/team-intake
+目标：补齐 Kubernetes 平台仓库的 chart、schema、policy 和发布门禁
+范围：Helm Chart、manifest、policy、验证脚本、release 说明
+不做：业务服务逻辑改造
+约束：必须区分 helm unittest、kubeconform、conftest/kyverno 和 server-side dry-run 的边界
+```
+
+```text
+/verify
+请基于当前 IaC 变更，汇总 chart 渲染、schema、policy、server-side 预检结果，并整理成可直接进入 /team-review 或 /team-release 的结论。
+```
+````
+
+继续阅读：看 [../docs/runbooks/helm-unittest-playbook.md](../docs/runbooks/helm-unittest-playbook.md)、[../docs/runbooks/kubeconform-schema-gates.md](../docs/runbooks/kubeconform-schema-gates.md)、[../docs/runbooks/conftest-policy-gates.md](../docs/runbooks/conftest-policy-gates.md)、[../docs/runbooks/kubectl-server-dry-run-gates.md](../docs/runbooks/kubectl-server-dry-run-gates.md)。

package/examples/internal-developer-platform-CLAUDE.md

@@ -0,0 +1,79 @@
+# Example Internal Developer Platform CLAUDE.md
+
+适用于内部开发者平台、工程门户、服务目录、模板脚手架平台、交付自助平台或研发基础设施入口仓库。
+
+这类项目的重点不是单点业务能力，而是开发者入口、一致性约束、自助体验、平台集成点和交付路径是否稳定可维护。
+
+## 适用信号
+
+- 需求经常涉及服务模板、环境自助、统一入口、平台 API、开发者体验或多系统编排
+- 成功标准常常是流程缩短、入口统一、平台集成稳定和 handoff 清晰
+- 仓库通常同时包含文档、命令、接口、门户或模板资产
+
+## 相对通用版的主要差异
+
+### 1. 命令流更强调平台流程与多角色协调
+
+- 建议链路：`/team-intake` -> `/team-plan` -> `/tdd` -> `/team-execute` -> `/handoff` -> `/team-review` -> `/team-release`
+- 如果仓库同时承担命令 / 文档 / 规则治理，可在关键阶段补 `/harness-audit`
+
+### 2. 项目约束更偏入口一致性与体验收口
+
+- 必须说明开发者入口、模板行为、失败兜底和人工介入路径
+- 改动平台入口时，文档、模板和 release 说明必须同步
+- handoff 需要对接开发者体验、运营支持和发布侧约束
+
+### 3. 角色链路更偏平台架构与前后端协作
+
+- 默认保留：`tech-lead`、`architect`、`frontend-engineer`、`backend-engineer`、`qa-engineer`
+- 若发布与环境变更复杂，再引入 `devops-engineer`
+
+## 一份更适合内部开发者平台的精简成品
+
+````md
+# Internal Developer Platform Working Agreement
+
+## 项目定位
+
+- 类型：内部开发者平台 / 工程门户
+- 重点：开发者入口、模板链路、平台集成、自助体验、交付收口
+
+## 默认角色
+
+- `tech-lead`
+- `architect`
+- `frontend-engineer`
+- `backend-engineer`
+- `qa-engineer`
+
+## 默认命令流
+
+1. `/team-intake`
+2. `/team-plan`
+3. `/tdd`
+4. `/team-execute`
+5. `/handoff`
+6. `/team-review`
+7. `/team-release`
+
+## 项目约束
+
+- 必须说明模板入口、失败兜底、人工介入和可观察性路径
+- 平台入口、文档、模板和集成说明必须同步更新
+- handoff 必须能让 QA 和 DevOps 直接接住验证范围与发布前提
+
+## 常用提示模板
+
+```text
+/team-intake
+目标：为内部开发者平台新增自助交付入口并补齐模板、验证和发布说明
+范围：门户入口、平台 API、模板行为、测试计划、release 说明
+不做：无关业务系统改造
+约束：必须说明失败兜底、人工介入路径、权限边界和发布前提
+```
+
+```text
+/handoff
+请把当前平台实现与验证结果整理成可直接交给 QA、DevOps 或下一角色的结构化内容，明确入口行为、失败兜底、已验证范围和剩余风险。
+```
+````