agentleFS
Leodorareluctant259Leodorareluctant259/superpowers-zh/skills/finishing-a-development-branch/SKILL.md

finishing-a-development-branch

Skill5 starsChanged 8 months agoMITView on GitHub

当实现完成、所有测试通过、需要决定如何集成工作时使用——通过提供合并、PR 或清理等结构化选项来引导开发工作的收尾

  • Commits and pushes

187 other projects use a version of this, 2 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use diagnosing-superpowers, condition-based-waiting and 5 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • obraSkill

    diagnosing-superpowers

    Use when a superpowers session went wrong and your human partner wants to know why — repeated work, ignored plans, stumbles, poor results, a skill that didn't fire, "it took too long", "why is it so expensive", "what is it doing" — or wants to build a bug report for the superpowers maintainers, for the current session or a past one identified by id or path, on any harness.

    Also in 20 projects that use this

  • kntismSkill

    condition-based-waiting

    Use when tests have race conditions, timing dependencies, or inconsistent pass/fail behavior - replaces arbitrary timeouts with condition polling to wait for actual state changes, eliminating flaky tests from timing guesses

    Also in 3 projects that use this

  • MicrosoftSkill

    testing-anti-patterns

    Use when writing or changing tests, adding mocks, or tempted to add test-only methods to production code - prevents testing mock behavior, production pollution with test-only methods, and mocking without understanding dependencies

    Also in 4 projects that use this

  • MicrosoftSkill

    root-cause-tracing

    Use when errors occur deep in execution and you need to trace back to find the original trigger - systematically traces bugs backward through call stack, adding instrumentation when needed, to identify source of invalid data or incorrect behavior

    Also in 5 projects that use this

  • frankxaiSkill

    defense-in-depth

    Use when invalid data causes failures deep in execution, requiring validation at multiple system layers - validates at every layer data passes through to make bugs structurally impossible

    Also in 3 projects that use this

  • nek1987Skill

    cto-advisor

    Technical leadership guidance for engineering teams, architecture decisions, and technology strategy. Includes tech debt analyzer, team scaling calculator, engineering metrics frameworks, technology evaluation tools, and ADR templates. Use when assessing technical debt, scaling engineering teams, evaluating technologies, making architecture decisions, establishing engineering metrics, or when user mentions CTO, tech debt, technical debt, team scaling, architecture decisions, technology evaluation, engineering metrics, DORA metrics, or technology strategy.

    Also in 3 projects that use this

The file

Files
SKILL.md

完成开发分支

概述

通过提供清晰的选项并执行所选工作流来引导开发工作的收尾。

核心原则: 验证测试 → 展示选项 → 执行选择 → 清理。

开始时宣布: "我正在使用 finishing-a-development-branch 技能来完成这项工作。"

流程

步骤 1:验证测试

在展示选项之前,验证测试通过:

# 运行项目的测试套件
npm test / cargo test / pytest / go test ./...

如果测试失败:

测试失败(<N> 个失败)。必须先修复才能继续:

[显示失败信息]

在测试通过之前无法进行合并/PR。

停止。不要继续到步骤 2。

如果测试通过: 继续步骤 2。

步骤 2:确定基础分支

# 尝试常见的基础分支
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null

或者询问:"这个分支是从 main 分出来的——对吗?"

步骤 3:展示选项

展示以下 4 个选项:

实现已完成。你想怎么做?

1. 在本地合并回 <base-branch>
2. 推送并创建 Pull Request
3. 保持分支现状(我稍后处理)
4. 丢弃这项工作

选哪个?

不要添加解释 - 保持选项简洁。

步骤 4:执行选择

选项 1:本地合并

# 切换到基础分支
git checkout <base-branch>

# 拉取最新代码
git pull

# 合并功能分支
git merge <feature-branch>

# 在合并结果上验证测试
<test command>

# 如果测试通过
git branch -d <feature-branch>

然后:清理工作树(步骤 5)

选项 2:推送并创建 PR

# 推送分支
git push -u origin <feature-branch>

# 创建 PR
gh pr create --title "<title>" --body "$(cat <<'EOF'
## 摘要
<2-3 条变更要点>

## 测试计划
- [ ] <验证步骤>
EOF
)"

然后:清理工作树(步骤 5)

选项 3:保持现状

报告:"保留分支 <name>。工作树保留在 <path>。"

不要清理工作树。

选项 4:丢弃

先确认:

这将永久删除:
- 分支 <name>
- 所有提交:<commit-list>
- 工作树 <path>

输入 'discard' 确认。

等待精确的确认。

确认后:

git checkout <base-branch>
git branch -D <feature-branch>

然后:清理工作树(步骤 5)

步骤 5:清理工作树

对于选项 1、2、4:

检查是否在工作树中:

git worktree list | grep $(git branch --show-current)

如果是:

git worktree remove <worktree-path>

对于选项 3: 保留工作树。

快速参考

选项合并推送保留工作树清理分支
1. 本地合并✓--✓
2. 创建 PR-✓✓-
3. 保持现状--✓-
4. 丢弃---✓(强制)

常见错误

跳过测试验证

  • 问题: 合并损坏的代码、创建失败的 PR
  • 修复: 在提供选项前始终验证测试

开放式问题

  • 问题: "接下来该做什么?" → 含糊不清
  • 修复: 准确展示 4 个结构化选项

自动清理工作树

  • 问题: 在可能还需要工作树时就删除了(选项 2、3)
  • 修复: 只在选项 1 和 4 时清理

丢弃时不确认

  • 问题: 意外删除工作成果
  • 修复: 要求输入 "discard" 确认

红线

绝不:

  • 在测试失败时继续
  • 合并前不验证测试结果
  • 不确认就删除工作成果
  • 未经明确请求就强制推送

始终:

  • 在提供选项前验证测试
  • 准确展示 4 个选项
  • 选项 4 要求输入确认
  • 只在选项 1 和 4 时清理工作树

集成

被以下技能调用:

  • subagent-driven-development(步骤 7)- 所有任务完成后
  • executing-plans(步骤 5)- 所有批次完成后

配合使用:

  • using-git-worktrees - 清理由该技能创建的工作树

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.