name	git-rebase-workflow
description	Git Rebase 分支同步流程，用于将当前功能分支 rebase 到最新的目标分支（如 master/main），保持提交历史整洁。适用于功能分支落后于目标分支时，需要同步最新代码的场景。

Git Rebase 工作流

将当前功能分支 rebase 到最新的目标分支（通常是 master/main），保持线性提交历史。

使用场景

功能分支落后于 master，需要同步最新代码
提交 MR/PR 前保持提交历史整洁
避免使用 git merge 产生的合并提交

前置检查

确认当前分支状态：
```
git branch -v
git status
```
确认工作区干净（无未提交的更改）

Rebase 流程

1. 获取最新代码

git fetch origin <目标分支>

2. 执行 Rebase

git rebase origin/<目标分支>

3. 解决冲突（如有）

如果出现冲突，按以下步骤处理：

查看冲突文件：
```
git status
```

查看冲突详情：

grep -n "<<<<<<< HEAD\|=======\|>>>>>>>" <冲突文件>

解决冲突策略：
- 保留目标分支版本（ours）：
```
git checkout --ours <文件路径>
```
- 保留当前分支版本（theirs）：
```
git checkout --theirs <文件路径>
```
- 手动编辑： 直接修改冲突文件，删除冲突标记
标记冲突已解决：
```
git add <文件路径>
```
继续 rebase：
```
git rebase --continue
```
在非交互环境或自动化执行中，避免 rebase --continue 打开编辑器后挂起。可临时禁用编辑器：
```
GIT_EDITOR=true git rebase --continue
```
如果命令已因编辑器挂起，先确认当前进程和 rebase 状态，再结束卡住的编辑器进程；不要中止 rebase 或重复执行会改写状态的命令。
如需中止 rebase：
```
git rebase --abort
```

4. 推送更新

git push origin <当前分支> --force-with-lease

注意：必须使用 --force-with-lease 安全地强制推送

常见问题

冲突解决原则

版本号冲突： 通常保留较新的版本
API 变更： 根据具体情况分析，询问用户意图
配置变更： 评估变更影响，选择合适的版本

安全建议

rebase 前确保有备份或已推送的分支
不要对公共分支（如 master）执行 rebase
使用 --force-with-lease 而非 --force 推送
如有不确定，先询问用户选择

完整示例

# 1. 检查状态
git branch -v
git status

# 2. 获取最新代码
git fetch origin master

# 3. 执行 rebase
git rebase origin/master

# 4. 解决冲突（如需要）
# - 查看冲突: git status
# - 保留 ours/theirs 或手动编辑
# - git add <文件>
# - git rebase --continue

# 5. 推送
git push origin feature-branch --force-with-lease

Más de este repositorio

mismo repositorio

daily-work-summary

nangongwentian-fe/jay-skills

根据指定 Git 仓库和日期，从 commit、提交正文、文件变更及必要的 diff 中提炼每日工作内容。用于用户要求按项目和日期生成日报、每日工作总结、根据 Git commit 总结工作，或要求用 1、2、3 编号列出某天或某段日期完成事项的场景。

2026-07-1812

web-content-fetcher

nangongwentian-fe/jay-skills

获取公开网页的正文或 Markdown 内容。当用户要求抓取链接、读取文章、提取网页正文、将页面转为 Markdown，或获取 X/Twitter、微信、知乎、Medium 等公开页面的文字内容时使用。支持在直接抓取失败或内容不完整时，通过内容提取代理和网页搜索逐级回退；不适用于需要登录的页面、付费墙绕过、媒体下载或结构化数据抓取。

2026-07-1312

post-task-learning-review

nangongwentian-fe/jay-skills

Review a completed or nearly completed non-trivial task and maintain durable lessons across project docs, memory, existing skills, or new skills. Use after complex debugging, deployment, live verification, repo documentation work, repeated workflow discovery, creating or updating a skill, or when the user asks whether anything is worth remembering, updating, or deleting.

2026-07-0512

browser-mcp-resource-guard

nangongwentian-fe/jay-skills

Use when Codex is about to use, is using, or has just used browser automation MCP tools such as chrome-devtools-mcp, Chrome DevTools MCP, Playwright MCP, @playwright/mcp, browser MCP, or browser/computer automation helpers; when the user mentions high CPU, high energy usage, battery drain, fans, heat, lag, duplicate browser MCP processes, stale Chrome Helper processes, or MCP cleanup; or when long-running Codex sessions may leave browser automation MCP helper processes behind.

2026-07-0212

git-topic-commit-push

nangongwentian-fe/jay-skills

Create one or more Git commits grouped by coherent change topic, then push the current branch. Use when the user asks to commit and push, submit by topic, split current changes into topical commits, or do "按照主题提交 commit 并 push"; especially when a worktree has mixed staged, unstaged, or untracked changes that need honest commit boundaries before `git push`. Commit messages must be written in Chinese unless the user explicitly requests another language.

2026-07-0112

goal-loop-builder

nangongwentian-fe/jay-skills

Create copy-ready, verifiable run contracts for long-horizon agent work. Use when the user asks to write, improve, or review Codex `/goal` prompts, Claude Code `/goal` conditions, Claude `/loop` prompts, `.claude/loop.md`, `goal.md`, loop engineering prompts, autonomous run instructions, stop/pause conditions, verification criteria, bounded iteration policy, or persistent Markdown instructions for agents.

2026-06-1612

name	git-rebase-workflow
description	Git Rebase 分支同步流程，用于将当前功能分支 rebase 到最新的目标分支（如 master/main），保持提交历史整洁。适用于功能分支落后于目标分支时，需要同步最新代码的场景。

Git Rebase 工作流

将当前功能分支 rebase 到最新的目标分支（通常是 master/main），保持线性提交历史。

使用场景

功能分支落后于 master，需要同步最新代码
提交 MR/PR 前保持提交历史整洁
避免使用 git merge 产生的合并提交

前置检查

确认当前分支状态：
```
git branch -v
git status
```
确认工作区干净（无未提交的更改）

Rebase 流程

1. 获取最新代码

git fetch origin <目标分支>

2. 执行 Rebase

git rebase origin/<目标分支>

3. 解决冲突（如有）

如果出现冲突，按以下步骤处理：

查看冲突文件：
```
git status
```

查看冲突详情：

grep -n "<<<<<<< HEAD\|=======\|>>>>>>>" <冲突文件>

解决冲突策略：
- 保留目标分支版本（ours）：
```
git checkout --ours <文件路径>
```
- 保留当前分支版本（theirs）：
```
git checkout --theirs <文件路径>
```
- 手动编辑： 直接修改冲突文件，删除冲突标记
标记冲突已解决：
```
git add <文件路径>
```
继续 rebase：
```
git rebase --continue
```
在非交互环境或自动化执行中，避免 rebase --continue 打开编辑器后挂起。可临时禁用编辑器：
```
GIT_EDITOR=true git rebase --continue
```
如果命令已因编辑器挂起，先确认当前进程和 rebase 状态，再结束卡住的编辑器进程；不要中止 rebase 或重复执行会改写状态的命令。
如需中止 rebase：
```
git rebase --abort
```

4. 推送更新

git push origin <当前分支> --force-with-lease

注意：必须使用 --force-with-lease 安全地强制推送

常见问题

冲突解决原则

版本号冲突： 通常保留较新的版本
API 变更： 根据具体情况分析，询问用户意图
配置变更： 评估变更影响，选择合适的版本

安全建议

rebase 前确保有备份或已推送的分支
不要对公共分支（如 master）执行 rebase
使用 --force-with-lease 而非 --force 推送
如有不确定，先询问用户选择

完整示例

# 1. 检查状态
git branch -v
git status

# 2. 获取最新代码
git fetch origin master

# 3. 执行 rebase
git rebase origin/master

# 4. 解决冲突（如需要）
# - 查看冲突: git status
# - 保留 ours/theirs 或手动编辑
# - git add <文件>
# - git rebase --continue

# 5. 推送
git push origin feature-branch --force-with-lease