name: safe-workflow description: SAFe开发工作流程指南，包括分支命名规范、提交信息格式、rebase-first工作流程和CI验证。适用于在Linear票证上开始工作、准备提交、创建分支、编写PR描述或询问贡献指南。
SAFe工作流程技能
📋 模板：此技能使用
{{TICKET_PREFIX}}作为占位符。替换为您项目的票证前缀（例如，WOR、PROJ、FEAT）。
目的
强制执行符合SAFe的git工作流程，包括标准化的分支命名、提交信息格式和rebase-first合并策略。确保线性历史和与Linear票证的完全可追溯性。
何时应用此技能
在以下情况调用此技能：
- 用户提到开始处理票证（例如，“我正在开始 {{TICKET_PREFIX}}-447”）
- 用户即将创建提交
- 用户正在创建或命名分支
- 用户询问PR工作流程或贡献指南
- 用户引用CONTRIBUTING.md或工作流程过程
- 用户询问“我应该如何提交这个？”或类似问题
分支命名规范
必需格式：{{TICKET_PREFIX}}-{number}-{short-description}
规则
- 必须以
{{TICKET_PREFIX}}-开头，后跟票证编号 - 使用小写字母和连字符进行描述
- 保持描述简短但有意义（总字符数最多50）
- 绝不包含个人名称或日期
示例
{{TICKET_PREFIX}}-447-create-safe-workflow-skill
{{TICKET_PREFIX}}-123-fix-login-redirect
{{TICKET_PREFIX}}-234-add-stripe-checkout
反模式（请勿使用）
feature/add-dark-mode （缺少票证编号）
fix/broken-login （缺少票证编号）
john-new-feature （个人命名）
WIP （不具描述性）
SAFe提交信息格式
必需格式：type(scope): description [{{TICKET_PREFIX}}-XXX]
类型（必需）
| 类型 | 何时使用 |
|---|---|
feat |
新功能 |
fix |
错误修复 |
docs |
仅文档 |
style |
格式化（无逻辑更改） |
refactor |
代码重构（无功能/错误） |
test |
添加或更新测试 |
chore |
维护、依赖项 |
ci |
CI/CD流水线更改 |
范围（可选）
常见范围：payments、auth、ui、api、db、harness、rls
票证引用（强制）
每个提交必须以 [{{TICKET_PREFIX}}-XXX] 结尾，引用票证。
示例
feat(harness): create safe-workflow skill [{{TICKET_PREFIX}}-447]
fix(auth): resolve login redirect issue [{{TICKET_PREFIX}}-57]
docs: update API documentation [{{TICKET_PREFIX}}-123]
refactor(db): optimize query performance [{{TICKET_PREFIX}}-234]
chore: upgrade dependencies [{{TICKET_PREFIX}}-337]
Rebase-First工作流程
此项目通过rebase-first工作流程强制执行线性历史。绝不创建合并提交。
工作流程步骤
# 1. 从最新 {{MAIN_BRANCH}} 开始
git checkout {{MAIN_BRANCH}} && git pull origin {{MAIN_BRANCH}}
# 2. 创建功能分支
git checkout -b {{TICKET_PREFIX}}-{number}-{description}
# 3. 进行提交（SAFe格式）
git add .
git commit -m "type(scope): description [{{TICKET_PREFIX}}-XXX]"
# 4. 在开发期间保持分支更新
git fetch origin
git rebase origin/{{MAIN_BRANCH}}
# 5. 推送前 - 最后进行一次rebase
git fetch origin
git rebase origin/{{MAIN_BRANCH}}
# 在本地解决任何冲突
# 6. 使用force-with-lease推送（rebase后安全）
git push --force-with-lease origin {{TICKET_PREFIX}}-{number}-{description}
# 7. 使用模板创建PR
# 仅使用“Rebase and merge”策略
为什么使用 --force-with-lease？
- 比
--force更安全（不会覆盖未见的远程更改） - rebase后需要以干净推送
- 防止在团队环境中意外覆盖
预PR验证清单
在创建PR前，所有这些都必须通过：
1. 代码质量验证
{{CI_VALIDATE_COMMAND}}
这运行：type-check、lint、test:unit、format:check
2. Markdown代码检查
{{LINT_MD_COMMAND}}
3. Git状态检查
git status
# 必须显示：nothing to commit, working tree clean（无内容提交，工作树干净）
4. Rebase状态
git fetch origin
git rebase origin/{{MAIN_BRANCH}}
# 必须与 {{MAIN_BRANCH}} 分支保持最新
5. 提交信息审计
git log origin/{{MAIN_BRANCH}}..HEAD --oneline
# 所有提交必须遵循带 [{{TICKET_PREFIX}}-XXX] 的SAFe格式
快捷方式：使用 /pre-pr 命令运行所有验证步骤。
可用斜杠命令
| 命令 | 目的 | 何时使用 |
|---|---|---|
/start-work |
开始处理票证 | 开始任何新工作 |
/check-workflow |
快速状态检查 | 在工作期间定期进行 |
/pre-pr |
PR前的完整验证 | 创建PR前 |
/end-work |
干净地完成会话 | 工作会话结束时 |
/quick-fix |
小错误修复的快速通道 | 次要、孤立的修复 |
多团队协调
高风险文件（在接触前宣布）
| 文件 | 风险 | 所需操作 |
|---|---|---|
prisma/schema.prisma |
高 | 在接触前在Slack中宣布 |
prisma/migrations/* |
高 | 与所有团队协调 |
docker-compose*.yml |
高 | 所有团队必须重启容器 |
package.json |
中 | 同步后运行 {{INSTALL_COMMAND}} |
.env.template |
中 | 更新本地 .env 文件 |
开始工作前
始终与最新 {{MAIN_BRANCH}} 同步：
git checkout {{MAIN_BRANCH}} && git pull origin {{MAIN_BRANCH}}
或使用 /local-sync 命令进行完全同步。
权威参考
有关完整工作流程文档，请参阅：
- CONTRIBUTING.md - 完整贡献者指南（单一真相来源）
- CLAUDE.md - 开发命令和架构
- .claude/README.md - Harness配置和命令
为什么这些规则重要
- 线性历史：Rebase-first防止团队间的合并冲突
- 票证可追溯性：每个提交链接到票证以进行审计跟踪
- 质量门控：CI验证在生产前捕捉问题
- 团队协调：分支命名支持自动化工作流程
- SAFe合规：标准化格式支持冲刺报告
自定义指南
| 占位符 | 描述 | 示例 |
|---|---|---|
{{TICKET_PREFIX}} |
您的票证/问题前缀 | WOR、PROJ、FEAT |
{{MAIN_BRANCH}} |
主要git分支名称 | main、dev |
{{CI_VALIDATE_COMMAND}} |
CI验证命令 | yarn ci:validate |
{{LINT_MD_COMMAND}} |
Markdown代码检查命令 | yarn lint:md |
{{INSTALL_COMMAND}} |
包安装命令 | yarn install |