菜单
Structured integration protocol that enforces a test-verification gate and presents branch disposition options (merge, PR, keep, or discard). Use when implementation is complete, all tests pass, and an integration decision for the development branch is pending.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
Cut a Superpipelines version release (vX.Y.Z) — verify the 5 version targets agree, draft CHANGELOG + RELEASE-NOTES entries, land them via PR (main is branch-protected), then create the GitHub release + tag and verify. Use when the user asks to cut/ship/publish a release, tag a version, do release work, or write release notes for Superpipelines.
Resolves agent `model_tier:` declarations into concrete platform-specific model strings and effort values via a 5-layer precedence chain, returning a serializable `resolved` object for dispatch. Use when `running-a-pipeline` Phase 0.45 needs to determine the concrete model + effort for each pipeline step on the active platform before dispatch.
Resolves the active runtime tier and provides the canonical DISPATCH contract for all pipeline step execution. Use when an orchestrator skill needs to dispatch pipeline steps — performs tier detection, loads the platform profile, and executes the Tier 2 inline loop when no subagent primitive is available.
Cut a Superpipelines version release (vX.Y.Z) — verify the 5 version targets agree, draft CHANGELOG + RELEASE-NOTES entries, land them via PR (main is branch-protected), then create the GitHub release + tag and verify. Use when the user asks to cut/ship/publish a release, tag a version, do release work, or write release notes for Superpipelines.
Run, resume, or list installed Superpipelines workflows from the registry.
Provides canonical engineering standards for authoring agents, skills, hooks, and pipeline orchestration in Claude Code. Use when authoring or modifying agents, skills, hooks, or pipeline-orchestration artifacts — covers model-tier selection, prompt-cache discipline, frontmatter schemas, and progressive-disclosure rules.
| name | finishing-a-development-branch |
| description | Structured integration protocol that enforces a test-verification gate and presents branch disposition options (merge, PR, keep, or discard). Use when implementation is complete, all tests pass, and an integration decision for the development branch is pending. |
Finishing a Development Branch ensures that work is integrated or preserved according to the user's explicit choice. It enforces a mandatory test verification gate before any options are presented, preventing the promotion of broken or unverified code to the base branch. The target for integration, typically `main` or `master`. An isolated directory for development; must be cleaned after integration. Option 2, which involves pushing the branch and creating a Pull Request via `gh pr create`.Ensures work is integrated or preserved according to explicit user choice. A mandatory test verification gate is enforced before any options are presented, preventing promotion of broken or unverified code to the base branch.
git merge-base HEAD main).gh CLI.<rationalization_table>
| Excuse | Reality |
|---|---|
| "PR handles testing anyway." | Local verification prevents broken builds and reduces CI overhead. |
| "It's just a one-line change." | One-line changes are the leading cause of "it worked in my head" regressions. |
| "Discarding is faster than cleanup." | Unconfirmed discards cause irreversible data loss. |
| </rationalization_table> |
sk-worktree-safety/SKILL.md — Worktree management.verification-before-completion/SKILL.md — Final evidence gate.running-a-pipeline/SKILL.md — Integration point for pipeline completion.