TOSR Publish Then Update Test_开发编程 skill-PHP中文网

TOSR Publish Then Update Test

Polar Sponsor

爱发电赞助

.NET 9.0

立即下载

专业代码审查和Git提交工作流管理。当用户提及“push”、“commit”、“提交”或任何Git提交操作时使用此技能。

Push Flow

功能概述

Push Flow是一项面向实际任务的技能，主要用于Overview. 这种技能提供专业代码审查, Git 承诺工作流程管理；它通过系统的预承诺检查、构建验证和遵守来保证代码质量。

核心要点

它将相关步骤、工具调用和结果整理方式集中到统一流程中，帮助使用者更快完成目标并减少重复操作。
使用时应结合输入条件选择合适的执行方式，核对必要参数、依赖环境与输出内容，并按原始要求处理异常情况。
该技能适合需要稳定复用相关能力的场景，可作为自动化工作流的一部分，也便于后续检查、调整和扩展。

使用与执行

从功能定位来看，该技能强调把分散的操作要求整理成清晰、可复用的处理流程，使用户能够围绕既定目标快速准备输入、选择执行方式并获得结构化结果。实际使用前应先确认任务范围、数据来源、运行环境、必要权限和关键参数，再依据技能说明逐步执行；

结果检查与注意事项

若输入条件不完整，应先补齐信息或采用保守配置，避免因错误假设导致结果偏离需求。执行过程中需要关注工具调用是否成功、接口或依赖是否可用、输出格式是否符合预期，并对异常提示、缺失字段和边界情况进行处理；涉及批量任务时，还应保存进度，避免中断后重复操作。

推送流程（Push Flow）

概述

本技能提供专业的代码审查与 Git 提交工作流管理。它通过系统化的提交前检查、构建验证以及对 Git 最佳实践的遵循，确保在任何代码提交前均满足质量要求。

关键规则

切勿在未经用户明确批准的情况下自动提交或推送代码。

所有 Git 操作均需在每一步获得用户确认。

提交信息（commit message）必须始终使用中文。

所有提交信息须以中文撰写，并遵循 Conventional Commits 规范（含中文描述）。

工作流决策树

当用户提及 push / commit / 提交时：

检查是否存在未提交的变更 → 若存在，进入步骤 2
提供代码审查选项 → 向用户询问是否需要进行 Code Review
若用户请求代码审查 → 执行全面审查
生成提交信息 → 向用户展示并等待批准
执行 git commit → 仅在用户批准提交信息后执行
运行构建验证 → 执行 go build 确保可成功编译
执行 git pull → 在推送前同步远程最新变更
若 pull 拉取了新变更 → 再次执行 go build
执行 git push → 仅在全部检查通过后执行

提交前工作流

步骤 1：自动提交已有变更

在进行任何代码修改前，自动提交当前所有未提交的变更：

# 检查是否存在未提交的变更
git status

# 若存在变更，则提交
git add .
git commit -m "chore: 保存当前工作进度"

注意：此为本地提交（不执行 push），用于保留进行中的工作状态。

步骤 2：提供代码审查选项

明确向用户提问：

“检测到有代码变更，是否需要进行 Code Review？”

若用户同意，则进入全面代码审查环节。

步骤 3：代码审查流程

执行系统性审查，覆盖以下维度：

代码质量：

逻辑正确性与边界情况处理
错误处理完整性
代码可读性与可维护性
性能考量

Go 特定规范：

是否符合 Go 编码规范
错误处理模式是否恰当
Goroutine 与并发安全性
资源管理（如 defer 使用）

项目规范：

是否符合项目编码指南
命名规范一致性
注释完整性
测试覆盖率

安全性：

输入校验
SQL 注入防护
敏感数据处理方式

提供可操作的反馈意见，包含具体行号引用及改进建议。

步骤 4：生成提交信息

按 Conventional Commits 格式生成简洁、准确的中文提交信息：

: 

[可选正文]

类型说明：

feat: 新功能
fix: 修复 bug
refactor: 重构
docs: 文档更新
style: 代码格式调整
test: 测试相关
chore: 构建/工具相关

示例：

feat: 添加用户认证中间件

- 实现 JWT token 验证
- 添加权限检查逻辑
- 完善错误处理

向用户提交审批：

“建议的 commit message：

[commit message]

是否同意使用此 commit message？”

步骤 5：执行提交

仅在用户批准后执行：

git add .
git commit -m "[approved commit message]"

步骤 6：构建验证

在任何推送操作前，验证构建是否成功：

go build

若构建失败：

向用户报告错误详情
禁止继续执行推送
主动提供协助修复构建问题的支持

步骤 7：推送前拉取最新变更

推送前始终拉取远程最新变更：

git pull

若 pull 引入新变更：

再次运行 go build 验证兼容性
若构建失败，须先解决冲突再推送

步骤 8：执行推送

仅在全部检查通过后执行：

git push

文件大小与类型限制

提交前须验证：

禁止提交二进制文件（除非明确要求）
禁止提交大于 1MB 的文件
禁止提交敏感数据（如凭据、密钥、token 等）

若检测到违规项，须向用户发出警告，并请求确认是否排除对应文件。

Git 配置偏好

远程仓库 URL 格式：始终使用 SSH 格式（git@github.com:user/repo.git），而非 HTTPS。

若检测到 HTTPS 格式的远程地址，建议转换为 SSH：

git remote set-url origin git@github.com:user/repo.git

Go 构建要求

针对 Go 项目：

每次提交前必须运行 go build
每次 pull 合并新变更后必须再次运行 go build
任何推送操作前必须确保编译成功

汇总检查清单

推送前请确保完成以下各项：

已自动提交现有变更（如存在）
已完成代码审查（如已请求）
提交信息已获用户批准
go build 执行成功
已执行 git pull
若 pull 引入新变更，则 go build 再次执行成功
无二进制文件或大于 1MB 的文件
用户已明确批准推送操作

交互示例

用户： “帮我提交代码”

助理：

“检测到有未提交的代码变更，是否需要进行 Code Review？”
[若用户同意] 执行代码审查并提供反馈
“建议的 commit message：feat: 添加用户登录功能，是否同意？”
[用户批准后] 执行 git commit
执行 go build 进行验证
执行 git pull
[若 pull 引入新变更] 再次执行 go build
“所有检查通过，是否执行 git push？”
[用户批准后] 执行 git push

其他

密码检测规则 🔒 在「关键规则」部分新增：禁止提交包含密码的文件提交前自动扫描敏感信息，包括：明文密码 API keys、tokens、secrets 数据库凭证私钥任何敏感认证信息若检测到敏感数据，立即中止提交并向用户发出警告检测模式包括： password =, PASSWORD =, pwd = api_key =, secret =, token = private_key, 密码, 口令数据库连接字符串中的凭证 JWT secrets、加密密钥
多功能分离提交规则 📦 在「关键规则」部分新增：当变更涉及多个不同功能时，必须分别提交自动分析与分组文件：按文件路径和模块结构分组按相关功能分组（如认证、API、数据库、UI 等）按逻辑功能边界分组为每个功能组生成独立的 commit message 按顺序依次提交，而非一次性提交全部文件示例：若变更同时包含“用户认证”和“数据导出”两个功能，则生成两个独立 commit： feat: 添加用户认证功能（认证相关文件） feat: 实现数据导出功能（导出相关文件）