amanjotx/Agent-Skills

/ship

提交当前工作，推送并打开一个拉取请求。调用此技能即表示明确允许创建/切换分支、提交、推送以及运行gh pr create。

严格规则

• 遵循用户的git安全协议：绝不更改git配置；绝不跳过钩子；绝不强制推送到main/master；仅在用户修正规则完全满足时才能修正提交。
• 绝不确定、提交密钥（.env、凭据、私钥、令牌）。如果存在，警告并排除它们。
• 仅暂存属于此更改的文件。除非工作树显然是有意且干净的，否则不使用全局git add ./git add -A。
• 使用HEREDOC编写提交消息和PR正文。
• 保持此工作流与项目无关。从仓库推断验证命令和布局；不要硬编码应用或包名。
• 完成后返回PR URL。

常规提交前缀

使用生产级别的常规提交。选择一个主要类型：

前缀	何时使用
feat	新的用户可见功能
fix	错误修复
refactor	内部重构，不改变预期行为
perf	性能改进
chore	维护、工具、依赖、日常事务
docs	仅文档
test	仅测试
ci	CI配置/流水线
build	构建系统或打包器更改
style	格式化/lint驱动的改动，无逻辑变化
revert	回滚之前的提交

格式：

type(optional-scope): imperative summary

Optional body: why this change exists (1–2 sentences).

示例：feat(auth): add refresh token rotation、fix: prevent double-submit on checkout、chore: bump lint config。

工作流程

1. 检查（并行执行）

• git status
• git diff and git diff --staged
• git branch -vv（当前分支 + 跟踪信息）
• git log -8 --oneline（消息风格）
• 默认基分支（优先main，否则master或仓库默认）
• 远程同步状态（git status -sb、未推送的提交）

如果没有任何提交或未推送的提交与此工作相关，则停止。不要打开空PR。

2. 确保正确的分支

目标：在专用功能分支上基于最新基分支完成工作。

1. 确定当前分支是否旨在包含这些更改：

   • 如果它已经是该工作的描述性主题分支（feat/…、fix/…、chore/…或明确匹配更改意图），并且不是默认分支，则为是。
   • 如果在main/master/默认分支、不匹配的主题分支、过时的无关分支或分离HEAD上，则为否。

2. 如果当前分支不是旨在包含这些更改：

   • 如果工作树是脏的，暂存并附带清晰的消息（默认；除非无法暂存，否则不要询问）。
   • git checkout <base>
   • git pull --ff-only（或从跟踪远程进行等效的快进更新）
   • 创建并切换到新的描述性分支，例如feat/short-topic、fix/short-topic、chore/short-topic
   • 将暂存的内容弹出到新分支；如有冲突，解决它们。

3. 如果当前分支是旨在包含这些更改：

   • 停留在该分支上。
   • 在提交之前，在需要时从基分支更新（根据仓库规范，从最新基分支进行变基或合并；优先选择非破坏性选项；除非用户明确要求，否则不要强制推送）。

绝不直接从默认分支构建PR。

3. 提交

• 优先选择一个连贯的提交，除非用户要求拆分。
• 消息使用适当的常规前缀和祈使句摘要。
• 正文（可选）：关注原因，而不是文件列表。
• 提交后，运行git status确认预期状态。
• 如果钩子失败：修复问题并创建新提交。除非修正规则完全满足，否则不要修正。

4. 推送

git push -u origin HEAD

当沙箱/网络/gh阻止操作时，请求所需权限。

5. 打开PR

分析所有即将合并到基分支的提交（而不仅仅是最新的）。

**标题：**与提交摘要相同的精神——清晰、具体、在必要时使用常规格式。避免含糊的标题。

正文模板（必需）：

## 摘要

- 2–5个要点，说明提交什么以及为什么重要

## 原因

- 此更改的问题、动机或触发因素

## 更改内容

- 按关注领域分组的要点（行为、API/合约、数据、UI、基础设施、测试、文档）
- 明确说明破坏性更改、迁移或认证/会话行为的变化

## 架构/流程

至少包含以下一项：

1. 主要路径的Mermaid图（序列图、流程图或状态图）
2. 结构、分层或前后的ASCII图

使用Mermaid表示控制流；使用ASCII表示树或层映射。
图表必须与实际差异匹配——不要发明架构。

## 风险/回滚

- 可能的故障模式
- 安全回滚/缓解说明

## 测试计划

- [ ] 审阅者可以运行的具体步骤
- [ ] 从项目中发现的、适合仓库的验证命令

使用gh pr create和HEREDOC正文创建。在需要时显式设置--base。

6. 报告结果

保持简洁：

• 分支名称
• 提交摘要
• PR标题
• PR URL
• 任何有意未提交的文件