Agent审查
- 作者仓库星标 3,406
- 作者更新于 实时读取
- 作者仓库 claude-octopus
- 领域
- 工程开发
- 兼容 Agent
-
- Claude Code
- Cursor
- Cline
- Codex
- Windsurf
- Gemini CLI
- +20
- 信任分
- 88 / 100 · 社区维护
- 作者 / 版本 / 许可
- @nyldn · 未声明 license
- Token 消耗评级
- 低消耗
- 接入复杂程度
- 需简单配置
- 是否需要外部 API Key
- 不需要
- 兼容的系统
- macOS · Linux · Windows
- 底层运行要求
- 无特殊要求
- 文件与系统权限
-
- 只读
- 允许写入 / 修改
- Shell 执行
- 网络行为
- 仅限本地
- 安装命令数
- 26 条
档案由构建时根据 SKILL.md 与安装命令自动衍生,可能与作者实际意图存在差异。
需要注意: 未限定 allowed-tools,默认拥有全部工具权限。
---
name: skill-finish-branch
description: Wrap up a branch — run tests, create PR, merge or discard — use when implementation is done This…
category: 工程开发
runtime: 无特殊运行时
---
# skill-finish-branch 输出预览
## PART A: 任务判断
- 适用问题:代码实现、重构、调试或代码审查。
- 输入要求:目标材料、限制条件、期望输出和验收方式。
- 证据边界:围绕“Execution Contract (MANDATORY - CANNOT SKIP) / Overview / The Process”读取原文规则,不把推断写成作者承诺。
## PART B: 执行结果
- **01** 任务判断:确认你的需求是否属于代码实现、重构、调试或代码审查,并标出输入、限制和预期结果。
- **02** 执行计划:优先按“Execution Contract (MANDATORY - CANNOT SKIP) / Overview / The Process”拆成步骤,说明每一步会读取什么、修改什么、产出什么。
- **03** 交付结果:给出可复制的命令、文件改动、检查清单或内容草稿,并说明如何继续迭代。
- **04** 风险边界:结合 读取文件、写入/修改文件、执行终端命令、主要在本地完成、通常不需要额外 API Key 给出执行前确认项。
## Running Rules
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先小样例验证,再放大到真实任务。
- 交付时同时给结果、检查口径和下一步迭代建议。 原文出现了 `/octo` 这类斜杠命令;如果你的 Agent 支持命令触发,优先用命令开场,再补充目标和边界。
告诉 Agent 目标文件或材料、期望结果、不可改范围、是否允许联网或执行命令。本 Skill 的权限画像是:读取文件、写入/修改文件、执行终端命令。
先用一个小任务确认它会围绕“Execution Contract (MANDATORY - CANNOT SKIP) / Overview / The Process”工作;涉及文件或命令时,先看 diff、日志、预览或测试结果。
检查最终产物是否包含明确结果、必要证据和下一步动作;如果输出泛泛而谈,就补充输入、边界和验收标准后重跑。
---
name: skill-finish-branch
description: Wrap up a branch — run tests, create PR, merge or discard — use when implementation is done This…
category: 工程开发
source: nyldn/claude-octopus
---
# skill-finish-branch
## 什么时候使用
- 用于审阅代码、文档或方案并给出可执行反馈 适合处理工程开发场景下的代码实现、调试、重构、测试或代码审查,核心价值是把输入、判断、执行、验证和交付边界固定下来,避免 Agent 泛泛回答。 把任务拆成可执行、可检查、可继续迭代的步骤;通常…
- 面向代码实现、重构、调试或代码审查,优先处理能明确输入、步骤和验收标准的工作。
## 需要提供什么
- 目标材料、目录范围、期望结果和不可改动内容。
- 是否允许联网、执行命令、读写文件或调用外部服务。
## 执行规则
- 围绕「Execution Contract (MANDATORY - CANNOT SKIP) / Overview / The Process」组织步骤,不把推断写成作者事实。
- 读取文件、写入/修改文件、执行终端命令;主要在本地完成;通常不需要额外 API Key。
- 先跑小样例,确认结果可检查后再扩大任务范围。
## 输出要求
- 给出最终产物、关键证据、验证方式和下一步动作。
- 信息不足时标记 unknown,不编造命令、平台或依赖。 作者原文负责流程事实;仓库文件负责来源和命令;流狐只补充适用场景、限制和质量判断。
skill "skill-finish-branch" {
输入层 -> 用户目标 + 目标文件 + 禁止范围 + 验收标准
上下文层 -> Execution Contract (MANDATORY - CANNOT SKIP) / Overview / The Process
规则层 -> SKILL.md 触发条件 / 执行顺序 / 输出格式
运行层 -> 无特殊运行时 | 读取文件、写入/修改文件、执行终端命令 | 主要在本地完成
安全层 -> 通常不需要额外 API Key + 小任务验证 + diff / 日志复核
输出层 -> 可复制结果 + 检查清单 + 下一步迭代
} Host: Codex CLI — This skill was designed for Claude Code and adapted for Codex. Cross-reference commands use installed skill names in Codex rather than
/octo:*slash commands. Use the active Codex shell and subagent tools. Do not claim a provider, model, or host subagent is available until the current session exposes it. For host tool equivalents, seeskills/blocks/codex-host-adapter.md.
Execution Contract (MANDATORY - CANNOT SKIP)
This generated Codex skill preserves an enforced workflow contract from the source skill.
PROHIBITED:
- Do not summarize, simulate, or skip the referenced workflow command when this skill requires execution.
- Do not claim provider output or validation artifacts exist without checking the actual files or command output.
- Do not continue silently when a required provider, command, or host capability is unavailable; report the unavailable dependency and use a supported fallback.
Finishing a Development Branch
Your first output line MUST be: 🐙 **CLAUDE OCTOPUS ACTIVATED** - Branch Completion
Overview
Full ship pipeline: tests → multi-provider review → version bump → changelog → commit → push → PR.
Core principle: Verify tests → Review diff → Bump version → Update changelog → Present options → Execute choice → Clean up.
The Process
Step 1: Verify Tests Pass
Before anything else, verify tests pass:
# Detect and run project's test suite
if [[ -f "package.json" ]]; then npm test
elif [[ -f "pytest.ini" ]] || [[ -f "pyproject.toml" ]]; then pytest
elif [[ -f "Cargo.toml" ]]; then cargo test
elif [[ -f "go.mod" ]]; then go test ./...
elif [[ -f "Makefile" ]] && grep -q '^test:' Makefile; then make test
fi
If tests fail: STOP. Show failures. Do not proceed.
If tests pass: Continue to Step 2.
Step 2: Multi-Provider Diff Review
Run a quick multi-provider review of the changes before shipping. This catches issues before they reach PR reviewers.
# Get the diff summary
DIFF_STAT=$(git diff --stat $(git merge-base HEAD main)..HEAD)
DIFF_FILES=$(git diff --name-only $(git merge-base HEAD main)..HEAD)
Always run a quick review — this is automatic, not optional:
# Quick review via orchestrate.sh (uses available providers)
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh spawn reviewer "Review this diff for bugs, security issues, and code quality problems. Be concise — only flag real issues, not style preferences.
$(git diff $(git merge-base HEAD main)..HEAD | head -500)"
If critical issues found: Present them and ask whether to fix or ship anyway.
If clean: Continue to Step 3. Show a brief ✓ Review clean — no issues found.
Step 3: Determine Base Branch & Version
# Identify the base branch
BASE_BRANCH=$(git remote show origin 2>/dev/null | grep 'HEAD branch' | awk '{print $NF}')
[[ -z "$BASE_BRANCH" ]] && BASE_BRANCH="main"
# Check for VERSION file
VERSION_FILE=""
for f in VERSION version.txt package.json; do
[[ -f "$f" ]] && VERSION_FILE="$f" && break
done
Step 4: Version Bump & Changelog (Optional)
If a VERSION file or package.json exists, offer to bump:
AskUserQuestion({
questions: [{
question: "Version bump?",
header: "Version",
multiSelect: false,
options: [
{label: "Patch (Recommended)", description: "Bug fixes, minor changes (1.2.3 → 1.2.4)"},
{label: "Minor", description: "New features, backward compatible (1.2.3 → 1.3.0)"},
{label: "Major", description: "Breaking changes (1.2.3 → 2.0.0)"},
{label: "Skip", description: "Don't bump version"}
]
}]
})
If bumping: Update the version file and prepend a changelog entry summarizing the diff:
# Generate changelog entry from commits
COMMITS=$(git log --oneline $(git merge-base HEAD $BASE_BRANCH)..HEAD)
# Prepend to CHANGELOG.md if it exists
Step 5: Present Options
Present exactly these 4 options:
✅ Ship ready. Tests passing. Review clean. What would you like to do?
1. **Create PR** (Recommended) - Push and create a Pull Request for review
2. **Merge locally** - Merge back to <base-branch> on this machine
3. **Keep as-is** - Leave the branch, I'll handle it later
4. **Discard** - Delete this work permanently
Which option? (1-4)
Keep options concise. Don't add explanations unless asked.
Step 4: Execute Choice
Option 1: Merge Locally
# Get current branch name
FEATURE_BRANCH=$(git branch --show-current)
BASE_BRANCH="main" # or detected base
# Switch to base branch
git checkout $BASE_BRANCH
# Pull latest
git pull origin $BASE_BRANCH
# Merge feature branch
git merge $FEATURE_BRANCH
# Verify tests on merged result
npm test # or appropriate test command
# If tests pass, delete feature branch
git branch -d $FEATURE_BRANCH
Report:
✅ Merged $FEATURE_BRANCH into $BASE_BRANCH
✅ Tests pass on merged result
✅ Feature branch deleted
Ready to push when you want: git push origin $BASE_BRANCH
Option 2: Create PR
# Get branch info
FEATURE_BRANCH=$(git branch --show-current)
# Push branch
git push -u origin $FEATURE_BRANCH
# Create PR with description
gh pr create \
--title "feat: [description]" \
--body "$(cat <<'EOF'
## Summary
- [What changed]
- [Why it changed]
## Test Plan
- [x] Unit tests pass
- [x] Manual verification done
- [ ] Code review needed
EOF
)"
Report:
✅ Branch pushed to origin/$FEATURE_BRANCH
✅ PR created: https://github.com/owner/repo/pull/123
Branch preserved for review process.
Option 3: Keep As-Is
✅ Keeping branch $FEATURE_BRANCH as-is.
Current state:
- Branch: $FEATURE_BRANCH
- Commits ahead of $BASE_BRANCH: N
- Tests: Passing
When ready, you can:
- Merge: git checkout main && git merge $FEATURE_BRANCH
- PR: git push -u origin $FEATURE_BRANCH && gh pr create
- Discard: git branch -D $FEATURE_BRANCH
Do NOT clean up anything.
Option 4: Discard
Confirm first (REQUIRED):
⚠️ This will PERMANENTLY delete:
- Branch: $FEATURE_BRANCH
- All commits:
- abc1234 feat: add user validation
- def5678 fix: handle edge case
- ghi9012 test: add integration tests
Type 'discard' to confirm, or anything else to cancel.
Wait for exact confirmation: discard
If confirmed:
# Switch to base branch first
git checkout $BASE_BRANCH
# Force delete the feature branch
git branch -D $FEATURE_BRANCH
# If remote exists, delete it too (with confirmation)
git push origin --delete $FEATURE_BRANCH 2>/dev/null || true
Report:
✅ Branch $FEATURE_BRANCH deleted locally
✅ Remote branch deleted (if existed)
Work has been permanently discarded.
Step 5: Cleanup (If Using Worktrees)
For Options 1, 2, 4: Check if in a worktree and clean up:
# Check if current directory is a worktree
if git worktree list | grep -q "$(pwd)"; then
# Get worktree path
WORKTREE_PATH=$(pwd)
# Switch to main worktree
cd $(git worktree list | head -1 | awk '{print $1}')
# Remove the worktree
git worktree remove "$WORKTREE_PATH"
echo "✅ Worktree cleaned up"
fi
For Option 3: Keep worktree intact.
Quick Reference
| Option | Merge | Push | Keep Branch | Cleanup |
|---|---|---|---|---|
| 1. Merge locally | ✓ | - | Delete | ✓ |
| 2. Create PR | - | ✓ | Keep | - |
| 3. Keep as-is | - | - | Keep | - |
| 4. Discard | - | - | Delete | ✓ |
Integration with Claude Octopus
After completing octopus workflows, use this skill:
# After tangle (develop) phase completes successfully
# After ink (deliver) phase validates the work
# User says: "I'm done, create a PR"
# → Invoke finishing-branch skill
# → Verify tests
# → Present options
# → Execute Option 2 (Create PR)
With Octopus Validation
# Run octopus validation before finishing
${HOME}/.claude-octopus/plugin/scripts/orchestrate.sh ink "Validate before merge"
# If validation passes, proceed with finishing-branch
Red Flags - Never Do
| Action | Why It's Dangerous |
|---|---|
| Merge without testing | Ships broken code |
| Skip confirmation for discard | Loses work permanently |
| Force-push without asking | Destroys history |
| Delete remote branch silently | Affects collaborators |
| Proceed when tests fail | Corrupts main branch |
Common Mistakes
| Mistake | Fix |
|---|---|
| Offering options before testing | Always verify tests FIRST |
| Auto-merging without asking | Present 4 options, let user choose |
| Deleting without confirmation | Require typed "discard" |
| Cleaning up worktree on "keep" | Only cleanup for options 1, 2, 4 |
The Bottom Line
Finishing branch → Tests verified AND user chose option
Otherwise → Not complete
Verify tests. Present options. Execute safely. Clean up appropriately.
先判断是否适合
作者设计意图
作者的方法与取舍
边界和复核