技能介绍

解决什么问题

代码合并前总有人想绕过检查，或者把 lint、测试、类型检查、构建放到部署后才跑，结果问题直到生产才暴露。这个技能要解决的是质量门禁不一致、检查位置太晚、失败后靠人工补锅的问题。它把“变更必须通过测试、lint、类型检查、构建”变成流水线里的硬约束，而不是靠 reviewer 记得执行。

技能如何工作

先定义质量门禁流水线：每次变更在合并前按顺序过 lint、type check、test、build；后一阶段应建立在前一阶段通过的基础上。
坚持 Shift Left：静态分析尽量前置，测试早于 staging，staging 早于 production。linting 能拦住的问题不应拖到生产。
执行 Faster is Safer：小批量、高频发布降低回滚和定位成本，3 个变更比 30 个变更更容易追因。
用 GitHub Actions 作为可落地示例：在 .github/workflows/ci.yml 中为 pull_request 和 main 分支配置 quality job，按步骤跑检查。
门禁不可跳过：lint 失败就修 lint，测试失败就修代码，不能改规则、skip test 或绕过检查。

适用边界与注意点

它适合新建项目 CI、补充自动化检查、配置部署流水线、PR 触发验证和排查 CI 失败。但它不替你决定项目该用哪个 linter、测试框架或部署目标；具体命令、依赖安装和缓存策略仍需按仓库技术栈补全。示例配置已截断，实际接入时要补完 steps，并把构建产物、通知和权限收敛到团队规范里。不要把门禁当成唯一防线，合并后的监控和回滚流程仍要存在。